From: kaz AT ashi DOT footprints DOT net (Kaz Kylheku)
Newsgroups: comp.os.msdos.djgpp,comp.lang.c++,comp.lang.c
Subject: Re: DJGPP reserves wrong int size
References: <9dde68b7 DOT 0106241053 DOT 2a385311 AT posting DOT google DOT com>
Organization: Psycho-Neurotic Institute for the Very, Very Nervous
Message-ID: <slrn9jcd8c.kb.kaz@cafe.net>
User-Agent: slrn/0.9.6.2 (Linux)
Lines: 58
Date: Sun, 24 Jun 2001 19:48:48 GMT
NNTP-Posting-Host: 24.78.252.241
X-Complaints-To: abuse AT home DOT net
X-Trace: news1.crdva1.bc.home.com 993412128 24.78.252.241 (Sun, 24 Jun 2001 12:48:48 PDT)
NNTP-Posting-Date: Sun, 24 Jun 2001 12:48:48 PDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On 24 Jun 2001 11:53:48 -0700, ZMAN <zacharyshort AT hotmail DOT com> wrote:
>Please consider the following code:
>
>int main () 
>{
>int i;
>i = 0x12345678;
>}

Note that ANSI C doesn't require type int to be capable of representing
values outside of the range -32767 to 32767. The type long can store 0x12345678
portably.

>-Yes I am aware there is no return statement even if I do have it in there 
>it still messes up.
>When I compile this code using:
>
>gcc -c test.c
>ld -o test -Ttext 0x0 -e main test.o
>objcopy -R .note -R .comment -S -O binary test test.bin
>
>and disassemble it I get the following:
>
>
>00000000 55                          push ebp
>00000001 89E5                        mov ebp,esp
>00000003 83EC04                      sub esp,byte +0x18
>00000006 C745FC78563412              mov dword [ebp-0x4],0x12345678
>0000000D C9                          leave
>0000000E C3                          ret
>
>The third line reserves 18 bytes.

No, it appears to reserves 0x18 bytes, which is 24. 

>And it should reserve 4 bytes because thats the size of an int right?

Says who? If you want to know what is required, read the C standard.
Nowhere does it say that the amount of automatic storage claimed
by a function call must be the absolute minimum possible.

Note that you are asking questions about compiler implementation internals that
are off topic in comp.lang.c. There is nothing in the C language definition
regarding how GCC generates code to set up stack frames.

>Could someone tell me what's going on?  I am loosing my mind!
>Line 4 is correct though.
>
>I am compiling this on Windows 98 and ME boxes and still get the same results.

You don't have any ``results''; results arise when you run the program.  If a
correct program executes correctly, then you have good results.

Note that you compiled without any optimization at all. When I compile
your example using -O and -fomit-frame-pointer, the function
is translated to a single ret instruction. So as you can see, it's possible
for a C implementation to reserve *less* automatic storage than what appears
to be required by the abstract semantics, as well as more.