Array memory allocation

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

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

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.

§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.)

On Dec 18, 5:39 am, Jack Klein <> wrote:
> On Mon, 17 Dec 2007 00:35:18 -0800 (PST), Pallav singh
> <> wrote in comp.lang.c++:
> > 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.

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.
> > 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.

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++.
> > #include<stdio.h>
> <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
miscopied, and his actual code included <stdlib.h> instead.)
> > 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.

On Dec 18, 2:56 am, James Kanze <> wrote:
>
> 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 wrote:
> On Dec 18, 2:56 am, James Kanze <> wrote:
>
>> 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.
>
That's because you invokes it as a "gcc default C like language"
compiler, rather than a compliant C compiler!

Victor Bazarov wrote:
> Ian Collins wrote:
>> bjarne wrote:
>>> On Dec 18, 2:56 am, James Kanze <> wrote:
>>>
>>>> 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.
>>>
>> 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'.
>
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!

On Dec 19, 11:24 pm, Ian Collins <> wrote:
> Victor Bazarov wrote:
> > 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 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.)

Ian Collins wrote:
> Victor Bazarov wrote:
> > 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.

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

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.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!