Array memory allocation

[Pallav singh]

Hi

if i declare globally its get store id BSS / Data
segment .................with size a.out we can verify
where does array is allocated memory when its declared inside a
function ......... i only see a change a little bit in Text ( Code )
Segment Size only

Thanks
Pallav Singh


#include<stdio.h>

char p[40];
static double d;

int i = 10;
static long l = 20;

int main()
{

int arr[1000] = {0};
int array[1000] = {0};

int i =3 , j ,*ip;
ip=(int *)malloc(sizeof(i));

p[5] = i;
d = 2.0 * 20;
return 0;

}

 

[Joel Yliluoma]

where does array is allocated memory when its declared
inside a function

The stack.

 

[Rahul]

The stack.

Only when the actual function is called...

 

[Jack Klein]

What stack? Can you cite a reference from the C++ language standard
that requires or guarantees the existence of such a stack?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Jack Klein]

Hi

if i declare globally its get store id BSS / Data
segment .................with size a.out we can verify

The '.' key on your keyboard seems to be broken. In English, there
are places where a single '.' character is used, after an abbreviation
or at the end of a sentence. And there are places where an ellipsis
is used, which is exactly three '.' characters, like this: ...

There is no place in the English language where two or four or
seventeen continuous '.' characters has any meaning at all.

As for your assertion, maybe your particular C++ compiler has things
called "BSS" or "Data" segments. The C++ language has no such things,
leaving the details up to the compiler.

where does array is allocated memory when its declared inside a
function ......... i only see a change a little bit in Text ( Code )
Segment Size only

Automatic objects allocated inside a function go wherever the compiler
implementer decided to put them. The C++ language does not specify.

If you want to know how your particular compiler does these things,
ask in a group that discusses your specific compiler.

Thanks
Pallav Singh

If your compiler accepts the code below, either it is completely
broken, or perhaps it is a C compiler. The code is ill-formed for
C++.

#include<stdio.h>

char p[40];
static double d;

int i = 10;
static long l = 20;

int main()
{

int arr[1000] = {0};
int array[1000] = {0};

int i =3 , j ,*ip;
ip=(int *)malloc(sizeof(i));

There is no declaration in scope for malloc(), because you have not
included <cstdlib> or even <stdlib.h>. A conforming C++ compiler will
not accept a call to a function without a proper declaration in scope.

The cast will allow older C compilers, prior to the 1999 version of
the C standard, to accept the code without a diagnostic. For versions
of the C standard from 1999 later, calling a function without a
declaration is a constraint violation.

In all versions of C and C++, this code is just plain wrong, and
produces undefined behavior.

p[5] = i;
d = 2.0 * 20;
return 0;

}

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[James Kanze]

What stack? Can you cite a reference from the C++ language
standard that requires or guarantees the existence of such a
stack?

§3.7.2 seems clear enough to me; §5.2.2/9 makes it even more
explicit. You can't implement C++ without a stack. (It's true
that in the special case of main, an implementation is not
required to allocate local variables on the stack.)

 

[James Kanze]

On Mon, 17 Dec 2007 00:35:18 -0800 (PST), Pallav singh

The '.' key on your keyboard seems to be broken. In English,
there are places where a single '.' character is used, after
an abbreviation or at the end of a sentence. And there are
places where an ellipsis is used, which is exactly three '.'
characters, like this: ...

There is no place in the English language where two or four or
seventeen continuous '.' characters has any meaning at all.

Sure there are. When lining up data in tables and such, for
example. LaTeX has constructions for generating it, for example
(and it's fairly easy to do in C++, by setting fill to '.' in
the output stream).

Of course, that may not be what the poster is trying to do here.

As for your assertion, maybe your particular C++ compiler has
things called "BSS" or "Data" segments. The C++ language has
no such things, leaving the details up to the compiler.

They never the less seem to be pretty commonly used terms for
the memory holding initialized and uninitialized (or zero
initialized) objects with static lifetimes.

Automatic objects allocated inside a function go wherever the
compiler implementer decided to put them. The C++ language
does not specify.

The semantics of the language do require some sort of a stack,
however (except for the special cas of main). What's
implementation defined is how the compiler implements this
stack.

If you want to know how your particular compiler does these
things, ask in a group that discusses your specific compiler.

If your compiler accepts the code below, either it is
completely broken, or perhaps it is a C compiler. The code is
ill-formed for C++.

<stdio.h> is deprecated in C++ in favor of <cstdio>.

Bof. It's not going to disappear anytime soon.

Of course, since he doesn't use anything from the header, the
best solution is to drop the include completely. (Maybe he

char p[40];
static double d;
int i = 10;
static long l = 20;
int main()
{
int arr[1000] = {0};
int array[1000] = {0};
int i =3 , j ,*ip;
ip=(int *)malloc(sizeof(i));

There is no declaration in scope for malloc(), because you
have not included <cstdlib> or even <stdlib.h>. A conforming
C++ compiler will not accept a call to a function without a
proper declaration in scope.

The cast will allow older C compilers, prior to the 1999
version of the C standard, to accept the code without a
diagnostic. For versions of the C standard from 1999 later,
calling a function without a declaration is a constraint
violation.

Older C compilers will accept it, but will do the wrong thing
with it. If no definition is in scope, the compiler will assume
that malloc returns an int (not a void*). The cast will convert
this int to a pointer. On machines where int's and pointers
don't have the same size (e.g. the original 16 bit x86's, and
most modern 64 bit machines), this will definitely cause
problems, and even on machines where they are the same size,
there's no guarantee that it works.

It's precisely problems like this that causes Stroustrup to
invent function prototypes, and the C standards committee to
adopt them. Although C doesn't require them, in order to avoid
breaking existing code, I would imagine that most C compilers
would at least warn if there was no prototype in scope.

 

[bjarne]

It's precisely problems like this that causesStroustrupto
invent function prototypes, and the C standards committee to
adopt them. Although C doesn't require them, in order to avoid
breaking existing code, I would imagine that most C compilers
would at least warn if there was no prototype in scope.

I'm sorry have to accuse you of being an optimist. I tried this with
GCC 3.4.3:

// x.c:
void f(int i)
{
printf("%d\n",i);
}

// y.c:
int main()
{
f("asdfg");
return 0;
}

Neither f() nor printf() has a prototype in scope. Since printf() is
variadic, it is required to have a prototype in scope, but the
compiler doesn't *know* that printf() is variadic.

It compiled without any warnings and a.out gave the result 67432.

I guess I have to be patient. It's only 25 years since I started to
use function declarations for checking in C with Classes and only just
over 20 years since I started to enforce them across translation unit
boundaries in C++.

Maybe in another decade, we can rely on C compilers doing this by
default. Until then, we can select our C compilers and their options
with care, not make such mistakes, or use C++.

-- Bjarne Stroustrup

 

[Ian Collins]

I'm sorry have to accuse you of being an optimist. I tried this with
GCC 3.4.3:

// x.c:
void f(int i)
{
printf("%d\n",i);
}

// y.c:
int main()
{
f("asdfg");
return 0;
}

Neither f() nor printf() has a prototype in scope. Since printf() is
variadic, it is required to have a prototype in scope, but the
compiler doesn't *know* that printf() is variadic.

It compiled without any warnings and a.out gave the result 67432.

That's because you invokes it as a "gcc default C like language"
compiler, rather than a compliant C compiler!

gcc /tmp/x.c /tmp/y.c -ansi -Wall -pedantic
/tmp/x.c: In function `main':
/tmp/x.c:4: warning: implicit declaration of function `f'
/tmp/y.c: In function `f':
/tmp/y.c:3: warning: implicit declaration of function `printf'

 

[Victor Bazarov]

That's because you invokes it as a "gcc default C like language"
compiler, rather than a compliant C compiler!

gcc /tmp/x.c /tmp/y.c -ansi -Wall -pedantic
/tmp/x.c: In function `main':
/tmp/x.c:4: warning: implicit declaration of function `f'
/tmp/y.c: In function `f':
/tmp/y.c:3: warning: implicit declaration of function `printf'

C does not require a function prototype to exist. What you have here
are _warnings_, Bjarnes code is well-formed C, AFAICS. If you have
a doubt, do ask in 'c.l.c'.

V

 

[Ian Collins]

C does not require a function prototype to exist. What you have here
are _warnings_, Bjarnes code is well-formed C, AFAICS. If you have
a doubt, do ask in 'c.l.c'.

I don't, it isn't well formed. Calling a variadic without a declaration
in scope invokes our old friend undefined behaviour. That's why the
compiler is required to issue a diagnostic in conforming mode.

I wasn't commenting on the code, I was pointing out that by default gcc
(like most other C compilers) isn't a conforming C compiler, you have to
tell it to use a conforming mode.

The fact that C only requires a diagnostic and the compiler is free to
carry on and produce an executable is one of the many reasons I prefer
C++ to C!

 

[James Kanze]

Victor Bazarov wrote:

I thought someone said they were required in C99. However, the
discussion was about warnings---I simply assumed that any C++
compiler worth its salt would *warn* about implicit function
declarations, since it is such an obvious source of error.
Apparently, as Bjarne pointed out, I was being overly
optimistic.

I don't, it isn't well formed. Calling a variadic without a
declaration in scope invokes our old friend undefined
behaviour. That's why the compiler is required to issue a
diagnostic in conforming mode.

CAlling a variadic function without a declaration in scope
invokes undefined behavior. Which means that anything the
compiler does is fine. No diagnostic required. (FWIW: I did
use a C compiler once which generated bad code in such
cases---it used different calling conventions for variadic
functions than for normal functions. Of course, it was for
embedded systems in a free standing environment, with almost no
standard library, so previously existing code wasn't an issue.)

I wasn't commenting on the code, I was pointing out that by
default gcc (like most other C compilers) isn't a conforming C
compiler, you have to tell it to use a conforming mode.

IMHO, this is one warning that should be on by default. It's
been how many years now that function prototypes exist?

The fact that C only requires a diagnostic and the compiler is
free to carry on and produce an executable is one of the many
reasons I prefer C++ to C!

There's actually no difference between C and C++ in this regard.
In the case of undefined behavior, anything goes. In cases
where a diagnostic is required, anything the implementation
documents is a diagostic (and gcc/g++ documents that all
messages issued by the compiler can be considered diagnostics in
the sense of the standard), and once the diagnositic is issued,
what happens next is undefined. As in undefined behavior: most
compilers will try to give a more or less readable message, and
not generate an object file, in the case of an error. But most
will also consider at least some warnings as "diagnostics", and
generate code despite what the standard says is an error, and a
compiler which just output a "?" and reformatted your hard disk
would be fully conforming (but probably not a large success
commercially).

(Note too that a compiler is allowed to issue a diagnostic even
when no error is present. So a compiler which always output a
"?", and always generated an object file with something in it,
would also be fully conforming, as long as the contents of the
object file were correct when there was no error.)

 

[Default User]

Ian Collins wrote:

C does not require a function prototype to exist.

Depends on what you mean. Use of a variadic function like printf()
without a prototype in scope is undefined behavior. It doesn't require
a diagnostic.





Brian

 

[Default User]

Victor Bazarov wrote:
I don't, it isn't well formed. Calling a variadic without a
declaration in scope invokes our old friend undefined behaviour.

No, more strictive, it requires a prototype. C still allows function
declarations like:

int printf();

That's why the compiler is required to issue a diagnostic in
conforming mode.

I don't think that's true. Now, for a C99 compiler, use of any function
without a declaration requires a diagnostic. Implicit declarations went
away.





Brian

 

[Default User]

I thought someone said they were required in C99.

No, declarations are required, but not prototypes. However, "old style"
is obsolescent.

However, the
discussion was about warnings---I simply assumed that any C++
compiler worth its salt would warn about implicit function
declarations, since it is such an obvious source of error.

I assume you mean C compiler. For C++ that's a required diagnostic (and
for C99 as well).

Apparently, as Bjarne pointed out, I was being overly
optimistic.

In fact, it did warn when in conforming mode, right?





Brian

 

[James Kanze]

No, more strictive, it requires a prototype. C still allows function
declarations like:

int printf();

Not in this case. Even C90 requires a function prototype to be
in scope when a variadic function is called. Something like the
above would result in undefined behavior if you used printf in
the code.

For non-variadic functions, of course, C90 didn't even require a
declaration if the function, at least if it returned int. And
most C compilers seem to use the C90 rules by default.