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

Discussion in 'C Programming' started by Army1987, Mar 29, 2007.

  1. Army1987

    Army1987 Guest

    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;
    }
     
    Army1987, Mar 29, 2007
    #1
    1. Advertising

  2. Army1987

    Eric Sosman Guest

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

    --
     
    Eric Sosman, Mar 29, 2007
    #2
    1. Advertising

  3. Army1987

    user923005 Guest

    On Mar 29, 11:31 am, "Army1987" <> 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.
     
    user923005, Mar 29, 2007
    #3
  4. Army1987

    Lew Pitcher Guest

    On Mar 29, 3:11 pm, "user923005" <> wrote:
    > On Mar 29, 11:31 am, "Army1987" <> 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
     
    Lew Pitcher, Mar 29, 2007
    #4
  5. Army1987

    Army1987 Guest

    "Lew Pitcher" <> ha scritto nel messaggio
    news:...
    >> 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>
     
    Army1987, Mar 29, 2007
    #5
  6. Army1987

    Army1987 Guest

    "Eric Sosman" <> 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? ;-)
     
    Army1987, Mar 29, 2007
    #6
  7. Army1987 <> 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
     
    Beej Jorgensen, Mar 29, 2007
    #7
  8. Army1987

    user923005 Guest

    On Mar 29, 2:39 pm, Beej Jorgensen <> wrote:
    > Army1987 <> 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.
     
    user923005, Mar 29, 2007
    #8
  9. Army1987

    Eric Sosman Guest

    Beej Jorgensen wrote On 03/29/07 17:39,:
    > Army1987 <> 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?

    --
     
    Eric Sosman, Mar 29, 2007
    #9
  10. "user923005" <> writes:
    > On Mar 29, 2:39 pm, Beej Jorgensen <> wrote:
    >> Army1987 <> 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) <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"
     
    Keith Thompson, Mar 29, 2007
    #10
  11. Eric Sosman <> writes:
    > Beej Jorgensen wrote On 03/29/07 17:39,:
    >> Army1987 <> 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?


    By adding the following to C99 5.2.4.1:

    -- 127 nesting levels of function calls

    But all the limits in 5.2.4.1 are primarily translation-time limits;
    an implementation that failed to meet one of them would probably do so
    by blowing up during compilation. The closest thing to a run-time
    limit is 65535 bytes in an object, and even that is something that the
    compiler has too keep track of during compilation (except for
    dynamically allocated objects).

    A required minimum number of nested function calls, on the other hand,
    would be something that would only affect program execution, and it
    would depend on the resources available during program execution.

    Perhaps there should be a separate set of required limits for run-time
    capacity.

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Mar 30, 2007
    #11
  12. Army1987

    Eric Sosman Guest

    Keith Thompson wrote:
    > Eric Sosman <> writes:
    >> Beej Jorgensen wrote On 03/29/07 17:39,:
    >>> Army1987 <> 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?

    >
    > By adding the following to C99 5.2.4.1:
    >
    > -- 127 nesting levels of function calls


    ... which expresses a requirement for nesting levels, but
    completely ignores the "weight" or "cost" of a call.

    int f(int depth) {
    char broiled[65535] = { 0 };
    char ming[65535] = { 1 };
    char shu_ding[65535] = { 2 };
    ... about fifty MB worth of auto variables ...
    return (depth <= 126) ? 42
    : broiled[f(depth+1)%65535]
    + ming[f(depth+2)%65535]
    + shu_ding[f(depth+3)%65535]
    + ... ;
    }

    It seems to me that an implementation that guaranteed correct
    evaluation of foo(0) might be able to guarantee little else ...

    > Perhaps there should be a separate set of required limits for run-time
    > capacity.


    Perhaps. But (I repeat) see Section 1, paragraph 2, point 5.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Mar 30, 2007
    #12
  13. Army1987

    CBFalconer Guest

    Lew Pitcher wrote:
    > On Mar 29, 3:11 pm, "user923005" <> wrote:
    >> On Mar 29, 11:31 am, "Army1987" <> wrote:
    >>

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


    No forcible termination. It just ended, and due to the abysmally
    stupid failure to return a valid value from main the result is
    undefined.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Mar 30, 2007
    #13
  14. Eric Sosman <> writes:
    > Keith Thompson wrote:
    >> Eric Sosman <> writes:
    >>> Beej Jorgensen wrote On 03/29/07 17:39,:
    >>>> Army1987 <> 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?

    >> By adding the following to C99 5.2.4.1:
    >> -- 127 nesting levels of function calls

    >
    > ... which expresses a requirement for nesting levels, but
    > completely ignores the "weight" or "cost" of a call.
    >

    [snip]

    Yes, it does. I can't think of any good way to express such a
    requirement; the point would be to require the implementation to
    accept *some* program that produces 127 levels of function calls.
    (BTW, the wording could be clearer; it's intended to refer to the
    depth of the "call stack", not to something like
    f1(f2(f3(f4(...f127()...)))).)

    I think main point of the translation limits in 5.2.4.1 isn't so much
    to require those specific values (though that's part of it), but to
    discourage imposing specific limits at all. For example, a compiler
    must support (at least one program that contains) at least 127
    arguments in one function call. The easiest way to satisfy that
    requirement isn't to use a fixed-size 127-element table; it's to
    handle arguments dynamically, limiting them only by amount of memory
    available during compilation.

    A requirement to allow 127 levels of function calls, if it were added
    to the standard, would forbid an implementation that only allows 1
    level.

    > It seems to me that an implementation that guaranteed correct
    > evaluation of foo(0) might be able to guarantee little else ...
    >
    >> Perhaps there should be a separate set of required limits for run-time
    >> capacity.

    >
    > Perhaps. But (I repeat) see Section 1, paragraph 2, point 5.


    Which says:

    This International Standard does not specify
    [...]
    -- the size or complexity of a program and its data that will
    exceed the capacity of any specific data-processing system or
    the capacity of a particular processor

    And yet it requires a hosted implementation to support 65535 bytes in
    an object.

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Mar 30, 2007
    #14
  15. Army1987

    Lew Pitcher Guest

    On Mar 29, 9:50 pm, CBFalconer <> wrote:
    > Lew Pitcher wrote:
    > > On Mar 29, 3:11 pm, "user923005" <> wrote:
    > >> On Mar 29, 11:31 am, "Army1987" <> wrote:

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

    ^
    Lookee here----------------------/

    > >>> }

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

    >
    > No forcible termination. It just ended, and due to the abysmally
    > stupid failure to return a valid value from main the result is
    > undefined.


    Chuck, it appears that you didn't notice the
    return 0;
    in the OPs code for main()

    I didn't see any way for the code to avoid that statement, so it
    appears that main() /does/ return a valid value.

    --
    Lew
     
    Lew Pitcher, Mar 30, 2007
    #15
  16. Army1987

    Daniel Rudy Guest

    At about the time of 3/29/2007 11:31 AM, Army1987 stated the following:
    > 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 (;;);
    > }


    The above questions have already been answered by another poster, so
    I'll leave that part of it alone.

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


    It's probably undefined behavior which means that it's implementation
    specific. FWIW, on my system, the program ran until I got a memory
    fault and the core dropped.

    strata:/home/dr2867/c/test 1051 $$$ ->./ub003
    Memory fault (core dumped)
    strata:/home/dr2867/c/test 1052 $$$ ->ls -l
    total 69586
    -rwxr-xr-x 1 dr2867 users 7195 Mar 29 21:29 ub003
    -rw-r--r-- 1 dr2867 users 47 Mar 29 21:28 ub003.c
    -rw------- 1 dr2867 users 67309568 Mar 29 21:29 ub003.core
    strata:/home/dr2867/c/test 1052 $$$ ->

    The program that you gave:

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

    is an infinite recursive loop. It will run until the stack blows up.
    Which is what happened in my case. As to why you got a return value,
    that's implementation specific: aka undefined behavior.


    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep
     
    Daniel Rudy, Mar 30, 2007
    #16
  17. Army1987

    Daniel Rudy Guest

    At about the time of 3/29/2007 12:52 PM, Army1987 stated the following:
    > "Lew Pitcher" <> ha scritto nel messaggio
    > news:...
    >>> 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...)


    LOL

    What was the fallout from that? Considering that you weren't even root,
    did they know it was you who did it?

    Most modern operating systems that use memory protection are protected
    enough so if a program goes out of control, the OS kills it in short
    order. Even programs ran under UID 0 (root) can't really crash the
    system on their own. Now something like

    dd if=/dev/random of=dev/kmem bs=1024

    will kill the system in short order.

    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep
     
    Daniel Rudy, Mar 30, 2007
    #17
  18. Army1987

    CBFalconer Guest

    Lew Pitcher wrote:
    > On Mar 29, 9:50 pm, CBFalconer <> wrote:
    >> Lew Pitcher wrote:
    >>> On Mar 29, 3:11 pm, "user923005" <> wrote:
    >>>> On Mar 29, 11:31 am, "Army1987" <> wrote:

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

    > ^
    > Lookee here----------------------/
    >
    >>>>> }

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

    >>
    >> No forcible termination. It just ended, and due to the abysmally
    >> stupid failure to return a valid value from main the result is
    >> undefined.

    >
    > Chuck, it appears that you didn't notice the
    > return 0;
    > in the OPs code for main()
    >
    > I didn't see any way for the code to avoid that statement, so it
    > appears that main() /does/ return a valid value.


    Woops. My second mistake this year. Things are getting bad.

    That leaves something foolish in lcc-win32.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Mar 30, 2007
    #18
  19. Army1987

    Daniel Rudy Guest

    At about the time of 3/29/2007 4:20 PM, Keith Thompson stated the following:
    > Eric Sosman <> writes:
    >> 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?

    >
    > By adding the following to C99 5.2.4.1:
    >
    > -- 127 nesting levels of function calls
    >
    > But all the limits in 5.2.4.1 are primarily translation-time limits;
    > an implementation that failed to meet one of them would probably do so
    > by blowing up during compilation. The closest thing to a run-time
    > limit is 65535 bytes in an object, and even that is something that the
    > compiler has too keep track of during compilation (except for
    > dynamically allocated objects).
    >
    > A required minimum number of nested function calls, on the other hand,
    > would be something that would only affect program execution, and it
    > would depend on the resources available during program execution.


    Exactly.

    > Perhaps there should be a separate set of required limits for run-time
    > capacity.


    Um...no.

    How are you going to account for a program that runs on a super
    computer? One that uses 25GB Ram, 50 CPUs, and other resources? You
    can't. A program cannot use more resources than the system has
    available, period. Eventually, you will run out of something...disk
    space, memory, CPU utilization, Network bandwidth, etc. Even swap is
    only so big. IMO, system imposed resource limits are good way to go.

    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m

    Why geeks like computers: look chat date touch grep make unzip
    strip view finger mount fcsk more fcsk yes spray umount sleep
     
    Daniel Rudy, Mar 30, 2007
    #19
  20. Army1987

    JimS Guest

    On Thu, 29 Mar 2007 21:29:19 -0700, Daniel Rudy
    <> wrote:

    >dd if=/dev/random of=dev/kmem bs=1024


    "'dd' is not recognized as an internal or external command,
    operable program or batch file."

    Jim
     
    JimS, Mar 30, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hal Styli
    Replies:
    14
    Views:
    1,679
    Old Wolf
    Jan 20, 2004
  2. Frederick Ding

    int main() or int main(void)?

    Frederick Ding, Dec 3, 2005, in forum: C Programming
    Replies:
    10
    Views:
    662
  3. int main(void) Why void?

    , Apr 6, 2006, in forum: C Programming
    Replies:
    6
    Views:
    510
  4. Replies:
    55
    Views:
    1,491
    Lionel B
    Jan 16, 2008
  5. Tristan Wibberley

    Re: int main(void) is better than int main()

    Tristan Wibberley, Jan 4, 2008, in forum: C++
    Replies:
    1
    Views:
    348
    Lars Uffmann
    Jan 7, 2008
Loading...

Share This Page