From: Mark McIntyre Newsgroups: comp.os.msdos.djgpp,comp.lang.c++,comp.lang.c Subject: Re: DJGPP reserves wrong int size Date: Tue, 26 Jun 2001 23:05:45 +0100 Message-ID: References: <9dde68b7 DOT 0106241053 DOT 2a385311 AT posting DOT google DOT com> <3b37e7cc DOT 288391695 AT news DOT primus DOT ca> NNTP-Posting-Host: garthorn.demon.co.uk X-NNTP-Posting-Host: garthorn.demon.co.uk:158.152.83.188 X-Trace: news.demon.co.uk 993593151 nnrp-14:3333 NO-IDENT garthorn.demon.co.uk:158.152.83.188 X-Complaints-To: abuse AT demon DOT net X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 43 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Tue, 26 Jun 2001 01:42:23 GMT, invalid AT erehwon DOT invalid (Graaagh the Mighty) wrote: >>Note that you are asking questions about compiler implementation internals that >>are off topic in comp.lang.c. > >I fail to see how that is relevant in comp.os.msdos.djgpp. because this was crossposted to many groups. So he gets an answer relevant to that group. Its always worth reading the group list. >>You don't have any ``results''; results arise when you run the program. If a >>correct program executes correctly, then you have good results. > >Semantic quibbling. Object code is a "result" of compiling. There are >additional "results" from running the compiled code. He was clearly >referring to the first of these. The result of the COMPILATION is some translated text which may be an object module, or may be a hippo. ISO doesn't define that. The result of your PROGRAM is the output. As a C programmer you should care about the latter, not the former. (In CLC, the result of a program is pretty much defined by ISO as being the output. Who cares what the compiler produces ? thats implementation specific stuff.) >>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. > >It's discarding an unused value in this case, it seems. And it looks >like the frame pointer is indeed buried in those extra 20 bytes >somewhere. Could be, but ANSI/ISO don't care and nor should the OP. -- Mark McIntyre CLC FAQ