Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > int main(void) { return main(); }

Reply
Thread Tools

int main(void) { return main(); }

 
 
Army1987
Guest
Posts: n/a
 
      03-29-2007
Is that in the object line a conforming program?
If so, why?
If not, why?
I'd expect it to be much like
int main(void)
{
for (;;
}

But if I compile it with lcc-win32 and run it in its rundos.exe, it says the
program exits with a return value of -1073741819 (i.e. -2^30 + 5) after
0.032 seconds or so. Why?

--
#include <stdio.h>
#include <stdlib.h>
int main(void) /* Don't try this at home */ {
const size_t dim = 256; int i;
for (i=0; malloc(dim); i++) /*nothing*/ ;
printf("You're done! %zu\n", i*dim);
puts("\n\n--Army1987"); return 0;
}


 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      03-29-2007
Army1987 wrote On 03/29/07 14:31,:
> Is that in the object line a conforming program?


You mean "subject" line, and it's a bad place for
questions.

> If so, why?


Because it satisfies the definition of "conforming
program" in Section 4, paragraph 7.

> If not, why?


See above.

> I'd expect it to be much like
> int main(void)
> {
> for (;;
> }
>
> But if I compile it with lcc-win32 and run it in its rundos.exe, it says the
> program exits with a return value of -1073741819 (i.e. -2^30 + 5) after
> 0.032 seconds or so. Why?


Probably because the program exceeded an implementation
limit. Which limit? The Standard doesn't say, but the lists
in Section 5.2.4 do not claim to be exhaustive. (See also
Section 1, paragraph 2, point 5).

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
user923005
Guest
Posts: n/a
 
      03-29-2007
On Mar 29, 11:31 am, "Army1987" <(E-Mail Removed)> wrote:
> Is that in the object line a conforming program?
> If so, why?
> If not, why?
> I'd expect it to be much like
> int main(void)
> {
> for (;;
>
> }
>
> But if I compile it with lcc-win32 and run it in its rundos.exe, it says the
> program exits with a return value of -1073741819 (i.e. -2^30 + 5) after
> 0.032 seconds or so. Why?
>
> --
> #include <stdio.h>
> #include <stdlib.h>
> int main(void) /* Don't try this at home */ {
> const size_t dim = 256; int i;
> for (i=0; malloc(dim); i++) /*nothing*/ ;
> printf("You're done! %zu\n", i*dim);
> puts("\n\n--Army1987"); return 0;
>
>
>
> }


Eric answered your question, and I have a guess about the why part.
Probably, since each call has to store the return address, you ran out
of automatic storage.

 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      03-29-2007
On Mar 29, 3:11 pm, "user923005" <(E-Mail Removed)> wrote:
> On Mar 29, 11:31 am, "Army1987" <(E-Mail Removed)> wrote:
>
>
>
> > Is that in the object line a conforming program?
> > If so, why?
> > If not, why?
> > I'd expect it to be much like
> > int main(void)
> > {
> > for (;;

>
> > }

>
> > But if I compile it with lcc-win32 and run it in its rundos.exe, it says the
> > program exits with a return value of -1073741819 (i.e. -2^30 + 5) after
> > 0.032 seconds or so. Why?

>
> > --
> > #include <stdio.h>
> > #include <stdlib.h>
> > int main(void) /* Don't try this at home */ {
> > const size_t dim = 256; int i;
> > for (i=0; malloc(dim); i++) /*nothing*/ ;
> > printf("You're done! %zu\n", i*dim);
> > puts("\n\n--Army1987"); return 0;

>
> > }

>
> Eric answered your question, and I have a guess about the why part.
> Probably, since each call has to store the return address, you ran out
> of automatic storage.


It is more likely that the loop
for (i=0; malloc(dim); i++) /*nothing*/ ;
exhausted available 'heap' memory, and the system (what-ever that is
wrt CLC <wink>) forcibly terminated the program.

To the OP: My bet is that, if you dig deep enough, you will find some
documentation on returncodes that tells you how to determine what a
"return value of -1073741819" actually means, and that documentation
will lead you to a "memory exhausted" error termination.

HTH
--
Lew


 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      03-29-2007

"Lew Pitcher" <(E-Mail Removed)> ha scritto nel messaggio
news:(E-Mail Removed) ups.com...
>> Eric answered your question, and I have a guess about the why part.
>> Probably, since each call has to store the return address, you ran out
>> of automatic storage.

>
> It is more likely that the loop
> for (i=0; malloc(dim); i++) /*nothing*/ ;
> exhausted available 'heap' memory, and the system (what-ever that is
> wrt CLC <wink>) forcibly terminated the program.


I guess he was referring to the program in the object line, not to that in
the signature.

<ot>
BTW, I tried something very similar to that (signature) on a terminal logged
on a workstation (running on CentOS) at university, and in a short time it
raised an exception such as "Panic in 5 seconds" or something like that,
crashing the server and receiving curses from the other users who were
logged. A professor was sent to reboot the server as nobody else knew where
it was physically located. (Actually, I didn't expect that the OS *actually*
permitted me to do so rather than killing the process or making the malloc
return NULL. Taking into account that I didn't even have root privileges...)
On my PC, on Linux, if dim is small (i.e. below 2^15 or so) it makes the
system slow down more and more, and on a system monitor it seems that *all*
or almost RAM and swap partition are used, then the process is killed and
the memory released. Instead, if dim is large (2^16 or more), it prints an
unrealistic resullt of almost 3GB ("unrealistic" because I have 1 GB of RAM
and 1 GB of swap space) after less than a second. On Windows, a small dim
does apparently nothing different than for(;; (but maybe I wasn't patient
enough), and a large dim prints a result of almost 2 GB.
</ot>


 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      03-29-2007

"Eric Sosman" <(E-Mail Removed)> ha scritto nel messaggio
news:1175194998.166564@news1nwk...

> Probably because the program exceeded an implementation
> limit. Which limit? The Standard doesn't say, but the lists
> in Section 5.2.4 do not claim to be exhaustive. (See also
> Section 1, paragraph 2, point 5).


This means that I could write a compiler which doesn't support more than n
nested function calls, with n = 1 (that'd mean that you couldn't call any
function from within main...), and still call that a conforming
implementation?


 
Reply With Quote
 
Beej Jorgensen
Guest
Posts: n/a
 
      03-29-2007
Army1987 <(E-Mail Removed)> wrote:
>This means that I could write a compiler which doesn't support more
>than n nested function calls, with n = 1 (that'd mean that you couldn't
>call any function from within main...), and still call that a
>conforming implementation?


Even though I can't see that it's strictly against the standard, that
implementation would certainly violate the spirit of c99 6.5.2.2p11:

# Recursive function calls shall be permitted, both directly and
# indirectly through any chain of other functions.

I was a little surprised to not see a minimum limit on the function call
depth, though. Am I just missing it?

-Beej

 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      03-29-2007
On Mar 29, 2:39 pm, Beej Jorgensen <(E-Mail Removed)> wrote:
> Army1987 <(E-Mail Removed)> wrote:
> >This means that I could write a compiler which doesn't support more
> >than n nested function calls, with n = 1 (that'd mean that you couldn't
> >call any function from within main...), and still call that a
> >conforming implementation?

>
> Even though I can't see that it's strictly against the standard, that
> implementation would certainly violate the spirit of c99 6.5.2.2p11:
>
> # Recursive function calls shall be permitted, both directly and
> # indirectly through any chain of other functions.
>
> I was a little surprised to not see a minimum limit on the function call
> depth, though. Am I just missing it?
>
> -Beej


Perhaps it can be inferred from:

"5.2.4.1 Translation limits

[#1] The implementation shall be able to translate and
execute at least one program that contains at least one
instance of every one of the following limits:12)

-- 127 nesting levels of blocks"

Since each function call must necessarily enter a new block.

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      03-29-2007
Beej Jorgensen wrote On 03/29/07 17:39,:
> Army1987 <(E-Mail Removed)> wrote:
>
>>This means that I could write a compiler which doesn't support more
>>than n nested function calls, with n = 1 (that'd mean that you couldn't
>>call any function from within main...), and still call that a
>>conforming implementation?

>
>
> Even though I can't see that it's strictly against the standard, that
> implementation would certainly violate the spirit of c99 6.5.2.2p11:
>
> # Recursive function calls shall be permitted, both directly and
> # indirectly through any chain of other functions.
>
> I was a little surprised to not see a minimum limit on the function call
> depth, though. Am I just missing it?


It's not there. One difficulty, I imagine, is in coming
up with an architecture-neutral way to describe the "weight"
of a function invocation. On many implementations it is
significantly cheaper to call a void function of one simple
argument that uses two auto variables than to call a struct-
valued function of forty arguments using ninety auto variables,
several of them being three-dimensional VLAs. But how do you
express that cost in a way that leads to a prescription of how
many nesting levels are usable?

--
(E-Mail Removed)
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-29-2007
"user923005" <(E-Mail Removed)> writes:
> On Mar 29, 2:39 pm, Beej Jorgensen <(E-Mail Removed)> wrote:
>> Army1987 <(E-Mail Removed)> wrote:
>> >This means that I could write a compiler which doesn't support more
>> >than n nested function calls, with n = 1 (that'd mean that you couldn't
>> >call any function from within main...), and still call that a
>> >conforming implementation?

>>
>> Even though I can't see that it's strictly against the standard, that
>> implementation would certainly violate the spirit of c99 6.5.2.2p11:
>>
>> # Recursive function calls shall be permitted, both directly and
>> # indirectly through any chain of other functions.
>>
>> I was a little surprised to not see a minimum limit on the function call
>> depth, though. Am I just missing it?
>>
>> -Beej

>
> Perhaps it can be inferred from:
>
> "5.2.4.1 Translation limits
>
> [#1] The implementation shall be able to translate and
> execute at least one program that contains at least one
> instance of every one of the following limits:12)
>
> -- 127 nesting levels of blocks"
>
> Since each function call must necessarily enter a new block.


I don't think so. I think that refers to the number of physically
nested blocks in the source program, not to the depth during
execution.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why is int a[0] not allowed, but int* a = new int[0] is? haijin.biz@gmail.com C++ 9 04-17-2007 09:01 AM
Difference between int i, j; and int i; int j; arun C Programming 8 07-31-2006 05:11 AM
int a[10]; int* p=(int*)((&a)+1); But why p isn't equal to ((&a)+1)? aling C++ 8 10-20-2005 02:42 PM
int main(int argc, char *argv[] ) vs int main(int argc, char **argv ) Hal Styli C Programming 14 01-20-2004 10:00 PM
dirty stuff: f(int,int) cast to f(struct{int,int}) Schnoffos C Programming 2 06-27-2003 03:13 AM



Advertisments