Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)

Discussion in 'C Programming' started by Nate Eldredge, Jun 14, 2009.

  1. Richard Heathfield <> writes:

    > Beej Jorgensen said:


    >> it can, occasionally, simplify memory management to know your VLA
    >> will deallocate when it falls out of scope. There are a lot of
    >> weird scoping rules with VLAs (esp involving goto), but they all
    >> seem to make some kind of sense.

    >
    > What doesn't make sense, however, is that there is no failure mode.
    > If you don't have the RAM, the behaviour appears to be undefined
    > (which I surmise on the basis that I can't find anything in the
    > spec to say otherwise). This is /such/ a bad idea.


    I agree it's unfortunate, but also probably unavoidable. And this
    situation is not unique to VLAs, either. What happens to a C program
    that recursively calls a function too many times, or even with a single
    fixed-size auto array that happens to be too large?

    > With *alloc (and
    > at least one variant of alloca but probably most/all of them), if
    > the allocation can't be done, you get a null response, for which
    > you can test.


    All the alloca implementations I've encountered don't return NULL on
    failure, but instead return a pointer to a block which may extend beyond
    the end of the stack, and causes the program to crash (usually segfault,
    sometimes misbehave in some other way) if accessed. This is the case on
    FreeBSD, Linux, and Solaris 8 at least. On these, alloca just subtracts
    the appropriate value from the stack pointer, so it is very efficient
    (which is one of the major advantage of alloca). Determining whether
    the allocation "succeeded" would require determining the address of the
    bottom of the stack, which on these systems would require a system call
    at the least, and cause alloca to become quite slow.
    Nate Eldredge, Jun 14, 2009
    #1
    1. Advertising

  2. Richard Heathfield <> writes:
    > Nate Eldredge said:

    [...]
    >> All the alloca implementations I've encountered don't return NULL
    >> on failure, but instead return a pointer to a block which may
    >> extend beyond the end of the stack, and causes the program to
    >> crash (usually segfault, sometimes misbehave in some other way)
    >> if accessed. This is the case on
    >> FreeBSD, Linux, and Solaris 8 at least.

    >
    > Well, I did check the manpage ("The alloca function returns a
    > pointer to the beginning of the allocated space. If the allocation
    > failed, a NULL pointer is returned.") before posting. Perhaps it's
    > lying. :)
    >
    > <snip>


    Presumably it's correct for your system, but in general:

    Ubuntu, Red Hat (both using glibc):

    The alloca() function returns a pointer to the beginning of the
    allo- cated space. If the allocation causes stack overflow,
    program behavior is undefined.

    Solaris:

    The alloca() function allocates size bytes of space in the stack
    frame of the caller, and returns a pointer to the allocated
    block. This temporary space is automatically freed when the caller
    returns. If the allocated block is beyond the current stack limit,
    the resulting behavior is unde- fined.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 15, 2009
    #2
    1. Advertising

  3. In article <>,
    Keith Thompson <> wrote:
    >Richard Heathfield <> writes:
    >> Nate Eldredge said:

    >[...]
    >>> All the alloca implementations I've encountered don't return NULL
    >>> on failure, but instead return a pointer to a block which may
    >>> extend beyond the end of the stack, and causes the program to
    >>> crash (usually segfault, sometimes misbehave in some other way)
    >>> if accessed. This is the case on
    >>> FreeBSD, Linux, and Solaris 8 at least.


    Given that the function in question is "non-standard", I don't see a)
    why we are dicussing it here or b) How anything can be said about it
    conclusively (with the sort of generality that we usually require here
    in CLC).

    More to the point, all that is needed to prove something - that is, to
    be able to say "at least one implementation does X" or "All the
    implementations that I've familiar with do X" is to write one yourself
    that does X.

    I've often done exactly that, in order to score points here on CLC.
    Kenny McCormack, Jun 15, 2009
    #3
  4. Nate Eldredge

    gwowen Guest

    Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job(Sunnyvale, CA)

    On Jun 15, 6:41 am, (Kenny McCormack)
    wrote:
    > Given that the function in question is "non-standard", I don't see a)
    > why we are dicussing it here or b) How anything can be said about it
    > conclusively (with the sort of generality that we usually require here
    > in CLC).


    Cut it out, Han.
    gwowen, Jun 15, 2009
    #4
    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. Xavier Jefferson
    Replies:
    14
    Views:
    507
    AlexS
    May 12, 2004
  2. Replies:
    1,418
    Views:
    15,881
    Series Expansion
    Jul 13, 2009
  3. Mariano Montone
    Replies:
    14
    Views:
    588
    blue indigo
    Feb 8, 2009
  4. prachi
    Replies:
    0
    Views:
    346
    prachi
    Apr 6, 2009
  5. Rich Morin
    Replies:
    1
    Views:
    78
    Daniel Schierbeck
    Nov 10, 2005
Loading...

Share This Page