alloca

Discussion in 'C Programming' started by Morris Dovey, Mar 3, 2008.

  1. Morris Dovey

    Morris Dovey Guest

    Re: alloca [OT]

    jacob navia wrote:

    > Since this is not comp.std.c I really do
    > not care, and I think that new users should be aware of its existence,
    > and the possible advantages and problems with its usage.


    Hmm. I won't raise hell, but I'll point out that it's as topical
    here as GETMAIN or shmget().

    --
    Morris Dovey
    DeSoto Solar
    DeSoto, Iowa USA
    http://www.iedu.com/DeSoto
    Morris Dovey, Mar 3, 2008
    #1
    1. Advertising

  2. Morris Dovey

    jacob navia Guest

    This function is not mentioned very often in this newsgroup but it
    is a VERY useful function, implemented in most compilers.

    I think it is useful to point to it since many people that read this
    newsgroup are newcomers, and they could benefit by using it.

    This function is an allocation function, i.e. it is similar in
    functionality to the malloc() function, but it has the advantage of
    allocating from the stack instead of allocating from the heap.

    This means that the storage obtained can only be used within the scope
    where this function was called, and can't be returned as the result of a
    function call.

    The syntax is:

    void *alloca(size_t);

    It is not a function mentioned in the C standard, but it is
    present under unix, windows and Mac, (all compilers) and
    in most C implementations actually.

    What makes this function interesting is that
    o It is very efficient. Since it allocates from the stack,
    a few assembler instructions are needed, much quicker
    than most "malloc" implementations.
    o The storage is freed automatically when the function where
    it is called exits. No need to call free().

    Caveats:

    o As I said above, the storage can't be returned from the current
    function.
    o There is the risk of stack overflow if you allocate too much memory
    with it. If it fails it returns NULL, but do not count on it.

    Some people in this newsgroup will raise hell because it is a function
    not mentioned in the standard. Since this is not comp.std.c I really do
    not care, and I think that new users should be aware of its existence,
    and the possible advantages and problems with its usage.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Mar 3, 2008
    #2
    1. Advertising

  3. jacob navia wrote:
    >
    > This function is not mentioned very often in this newsgroup but it
    > is a VERY useful function, implemented in most compilers.


    [Referring to "alloca" in the subject, but not the body.]

    > I think it is useful to point to it since many people that read this
    > newsgroup are newcomers, and they could benefit by using it.

    [...]
    > Some people in this newsgroup will raise hell because it is a function
    > not mentioned in the standard. Since this is not comp.std.c I really do
    > not care, and I think that new users should be aware of its existence,
    > and the possible advantages and problems with its usage.


    Well, I find open(), select(), and socket() quite useful as well, and
    they're available on every platform I use, but that doesn't make them
    relevent to clc.

    And, to your mention as to how wide-spread it's availablility is, here
    is what happens on my Windows system, with MSVC:

    ==========
    C:\temp>type usenet.c
    #include <stdio.h>
    #include <stdlib.h>

    int main()
    {
    char *foo = alloca(100);
    }

    C:\temp>cl usenet.c
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
    Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

    usenet.c
    usenet.c(6) : warning C4047: 'initializing' : 'char *' differs in levels of indi
    rection from 'int '
    Microsoft (R) Incremental Linker Version 6.00.8447
    Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

    /out:usenet.exe
    usenet.obj
    usenet.obj : error LNK2001: unresolved external symbol _alloca
    usenet.exe : fatal error LNK1120: 1 unresolved externals

    C:\temp>
    ==========

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Mar 3, 2008
    #3
  4. In article <fqhoa9$a68$>, jacob navia <> wrote:
    >This function is not mentioned very often in this newsgroup but it
    >is a VERY useful function, implemented in most compilers.


    >I think it is useful to point to it since many people that read this
    >newsgroup are newcomers, and they could benefit by using it.


    I would say the opposite: that newcomers need to learn first
    proper C, and only when they become well acquainted with proper C
    should they being learning about non-standard implementation-dependant
    functions.


    >This function is an allocation function, i.e. it is similar in
    >functionality to the malloc() function, but it has the advantage of
    >allocating from the stack instead of allocating from the heap.


    What stack?


    >It is not a function mentioned in the C standard, but it is
    >present under unix, windows and Mac, (all compilers) and
    >in most C implementations actually.


    If it is present in Unix, then you can point to the appropriate
    opengroup.org man page?

    The Linux system I have close at hand says,

    CONFORMING TO
    There is evidence that the alloca function appeared in 32v, pwb,
    pwb.2, 3bsd, and 4bsd. There is a man page for it in BSD 4.3. Linux
    uses the GNU version. This function is not in POSIX or SUSv3.

    --
    "Pray do not take the pains / To set me right. /
    In vain my faults ye quote; / I wrote as others wrote /
    On Sunium's hight." -- Walter Savage Landor
    Walter Roberson, Mar 3, 2008
    #4
  5. Morris Dovey

    Michael Mair Guest

    jacob navia wrote:
    > This function is not mentioned very often in this newsgroup but it
    > is a VERY useful function, implemented in most compilers.
    >
    > I think it is useful to point to it since many people that read this
    > newsgroup are newcomers, and they could benefit by using it.
    >
    > This function is an allocation function, i.e. it is similar in
    > functionality to the malloc() function, but it has the advantage of
    > allocating from the stack instead of allocating from the heap.
    >
    > This means that the storage obtained can only be used within the scope
    > where this function was called, and can't be returned as the result of a
    > function call.
    >
    > The syntax is:
    >
    > void *alloca(size_t);
    >
    > It is not a function mentioned in the C standard, but it is
    > present under unix, windows and Mac, (all compilers) and
    > in most C implementations actually.
    >
    > What makes this function interesting is that
    > o It is very efficient. Since it allocates from the stack,
    > a few assembler instructions are needed, much quicker
    > than most "malloc" implementations.
    > o The storage is freed automatically when the function where
    > it is called exits. No need to call free().
    >
    > Caveats:
    >
    > o As I said above, the storage can't be returned from the current
    > function.
    > o There is the risk of stack overflow if you allocate too much memory
    > with it. If it fails it returns NULL, but do not count on it.


    - the memory allocated with alloca() usually cannot be deallocated.
    - the memory allocated with alloca() lives "till the end of the
    function" -- always; see <> for a
    very recent explanation why this can be bad.

    > Some people in this newsgroup will raise hell because it is a function
    > not mentioned in the standard.


    Nope, but I would raise hell if I found someone using it frivolously,
    i.e. for convenience only, in production code. alloca() usually
    bypasses application memory management and thus can produce funny
    effects and memory sinks. If there is a good reason, e.g. "using
    alloca() leads to significant speedup in foo() and consequently
    the whole application while automatic storage duration memory
    consumption can be at most X bytes / is small / has a fixed ratio
    relative to Y", then using alloca() is okay, of course.
    And no, "I use it always because it is fast as hell" does not cut it.

    > Since this is not comp.std.c I really do
    > not care, and I think that new users should be aware of its existence,
    > and the possible advantages and problems with its usage.


    .... you forgot the problem that, when they come to clc with problems,
    they always get the "not in the Standard" treatment ;-)

    Apart from that, knowing that there _is_ an alloca() (almost everywhere)
    certainly is useful but knowing when (not) to use it is almost more
    important.


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
    Michael Mair, Mar 3, 2008
    #5
  6. Morris Dovey

    user923005 Guest

    On Mar 3, 12:50 pm, jacob navia <> wrote:
    > This function is not mentioned very often in this newsgroup but it
    > is a VERY useful function, implemented in most compilers.
    >
    > I think it is useful to point to it since many people that read this
    > newsgroup are newcomers, and they could benefit by using it.
    >
    > This function is an allocation function, i.e. it is similar in
    > functionality to the malloc() function, but it has the advantage of
    > allocating from the stack instead of allocating from the heap.
    >
    > This means that the storage obtained can only be used within the scope
    > where this function was called, and can't be returned as the result of a
    > function call.
    >
    > The syntax is:
    >
    > void *alloca(size_t);
    >
    > It is not a function mentioned in the C standard, but it is
    > present under unix, windows and Mac, (all compilers) and
    > in most C implementations actually.
    >
    > What makes this function interesting is that
    > o It is very efficient. Since it allocates from the stack,
    >    a few assembler instructions are needed, much quicker
    >    than most "malloc" implementations.
    > o The storage is freed automatically when the function where
    >    it is called exits. No need to call free().
    >
    > Caveats:
    >
    > o As I said above, the storage can't be returned from the current
    >    function.
    > o There is the risk of stack overflow if you allocate too much memory
    >    with it.  If it fails it returns NULL, but do not count on it.
    >
    > Some people in this newsgroup will raise hell because it is a function
    > not mentioned in the standard. Since this is not comp.std.c I really do
    > not care, and I think that new users should be aware of its existence,
    > and the possible advantages and problems with its usage.


    There is no function called alloca() using Microsoft Visual C++,
    although there is one called _alloca():
    http://msdn2.microsoft.com/en-us/library/wb1s57t5(VS.71).aspx

    Note that it throws {non-standard} exceptions rather than returning a
    null pointer.
    I guess that other versions of stack allocation functions behave
    differently.
    user923005, Mar 3, 2008
    #6
  7. In article <>,
    Kenneth Brody <> wrote:

    >Well, I find open(), select(), and socket() quite useful as well, and
    >they're available on every platform I use, but that doesn't make them
    >relevent to clc.


    I disagree. I think alloca() is far more on-topic than those other
    functions. They have a standard that specifies them, and newsgroups
    related to that standard. alloca() on the other is just something
    that's existed in most versions of C. If comp.lang.c is not the
    newsgroup for it, what is?

    -- Richard
    --
    :wq
    Richard Tobin, Mar 3, 2008
    #7
  8. "jacob navia" <> wrote in message
    news:fqhoa9$a68$...
    > Some people in this newsgroup will raise hell because it is a function
    > not mentioned in the standard. Since this is not comp.std.c I really do
    > not care, and I think that new users should be aware of its existence,
    > and the possible advantages and problems with its usage.
    >
    >

    Oddly enough alloca is on topic in comp.std.c, because that's the place to
    discuss proposed changes to the C standard.
    However topicality should not be so tightly drawn that functions like
    alloca() cannot be mentioned here at all. However it should be discussed as
    it arises naturally in response to topical thread, not as a subject in its
    own right.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Mar 3, 2008
    #8
  9. Morris Dovey

    Eric Sosman Guest

    jacob navia wrote:
    > This function is not mentioned very often in this newsgroup but it
    > is a VERY useful function, implemented in most compilers.
    >
    > I think it is useful to point to it since many people that read this
    > newsgroup are newcomers, and they could benefit by using it.
    >
    > This function is an allocation function, i.e. it is similar in
    > functionality to the malloc() function, but it has the advantage of
    > allocating from the stack instead of allocating from the heap.
    >
    > This means that the storage obtained can only be used within the scope
    > where this function was called, and can't be returned as the result of a
    > function call.
    >
    > The syntax is:
    >
    > void *alloca(size_t);
    >
    > It is not a function mentioned in the C standard, but it is
    > present under unix, windows and Mac, (all compilers) and
    > in most C implementations actually.
    >
    > What makes this function interesting is that
    > o It is very efficient. Since it allocates from the stack,
    > a few assembler instructions are needed, much quicker
    > than most "malloc" implementations.


    That's odd: The Rationale says "Such a function is not
    efficiently implementable in a variety of environments, so
    it was not adopted in the Standard." What do you know that
    the couple hundred contributors to the Standard didn't?

    > o The storage is freed automatically when the function where
    > it is called exits. No need to call free().
    >
    > Caveats:
    >
    > o As I said above, the storage can't be returned from the current
    > function.
    > o There is the risk of stack overflow if you allocate too much memory
    > with it. If it fails it returns NULL, but do not count on it.


    You forgot

    o Even on systems where alloca() is available, it may fail
    catastrophically in some contexts, for example

    ptr = fgets(alloca(SIZE), SIZE, stdin);

    > Some people in this newsgroup will raise hell because it is a function
    > not mentioned in the standard. Since this is not comp.std.c I really do
    > not care, and I think that new users should be aware of its existence,
    > and the possible advantages and problems with its usage.


    My reason for raising hell is quite different: It is that
    you are trying to fool "newcomers" with a supposedly-advantageous
    function having only minor drawbacks. In actual fact, alloca()
    offers *no* benefit over the mechanisms provided by the Standard.
    Those mechanisms are also unsafe, but they are *less* so than
    is alloca(). In short, alloca() just makes a dangerous situation
    more dangerous without providing any compensatory benefit.

    --
    Eric Sosman, Mar 3, 2008
    #9
  10. In article <fqhr0p$1l4t$>,
    Richard Tobin <> wrote:
    >In article <>,
    >Kenneth Brody <> wrote:


    >>Well, I find open(), select(), and socket() quite useful as well, and
    >>they're available on every platform I use, but that doesn't make them
    >>relevent to clc.


    >I disagree. I think alloca() is far more on-topic than those other
    >functions. They have a standard that specifies them, and newsgroups
    >related to that standard. alloca() on the other is just something
    >that's existed in most versions of C. If comp.lang.c is not the
    >newsgroup for it, what is?


    It is not possible to write a general alloca() that exists
    outside of the intimate details of the ABI in use. It therefore
    must not be thought of as belonging to C: it belongs to the
    system extensions that C compiler provides for that operating
    environment. That makes it topical in the newsgroups that discuss
    those operating environment specifics, not topical in comp.lang.c .

    For example I would expect alloc() on SGI IRIX to be discussed
    in comp.sys.sgi.misc .
    --
    So you found your solution
    What will be your last contribution?
    -- Supertramp (Fool's Overture)
    Walter Roberson, Mar 3, 2008
    #10
  11. Morris Dovey

    Michael Mair Guest

    [OT] Re: alloca

    Walter Roberson wrote:
    > --
    > So you found your solution
    > What will be your last contribution?
    > -- Supertramp (Fool's Overture)


    Out of Walter sayings?

    -Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
    Michael Mair, Mar 3, 2008
    #11
  12. Morris Dovey

    Guest

    jacob navia <> wrote:
    >
    > This function is not mentioned very often in this newsgroup but it
    > is a VERY useful function, implemented in most compilers.
    >
    > I think it is useful to point to it since many people that read this
    > newsgroup are newcomers, and they could benefit by using it.


    It is a horrible hack that should generally be avoided, particularly by
    novices. Many implementations are buggy and nearly all implementations
    have restrictions on the contexts in which it can be used that are
    documented poorly, if at all. It was left out of the C standard quite
    intentionally. The variable length array feature of C99 was intended to
    be a well-defined and well-behaved replacement for it.

    -Larry Jones

    No one can prove I did that!! -- Calvin
    , Mar 3, 2008
    #12
  13. Morris Dovey

    user923005 Guest

    On Mar 3, 1:36 pm, (Richard Tobin) wrote:
    > In article <>,
    > Kenneth Brody  <> wrote:
    >
    > >Well, I find open(), select(), and socket() quite useful as well, and
    > >they're available on every platform I use, but that doesn't make them
    > >relevent to clc.

    >
    > I disagree.  I think alloca() is far more on-topic than those other
    > functions.  They have a standard that specifies them, and newsgroups
    > related to that standard.  alloca() on the other is just something
    > that's existed in most versions of C.  If comp.lang.c is not the
    > newsgroup for it, what is?


    I think if alloca() could be made to behave exactly like malloc(),
    which is to say it should return a pointer to the memory if it
    succeeds and a null pointer if it fails, then it would be quite a
    useful addition. If this is not possible, then I think it has very
    limited usefulness {who wants a standard function that behaves
    differently every time you try to use it on a different platform or
    with a different compiler?}. I suppose that the discussion would be
    more sensible on news:comp.std.c than news:comp.lang.c since we are
    proposing adding something to the language, based on popular usage.
    Follow-up set to news:comp.std.c

    IMO-YMMV.
    user923005, Mar 3, 2008
    #13
  14. Re: [OT] Re: alloca

    In article <>,
    Michael Mair <> wrote:
    >Walter Roberson wrote:
    >> --
    >> So you found your solution
    >> What will be your last contribution?
    >> -- Supertramp (Fool's Overture)


    >Out of Walter sayings?


    That's been in my random signatures file since at least Oct 27, 2002.

    The random Walter sayings are only a few weeks ago. I thought I'd put
    in plenty of those, but it seems I'm posting more frequently than I
    thought. I may have to dig out some more.
    --
    "Any sufficiently advanced bug is indistinguishable from a feature."
    -- Rich Kulawiec
    Walter Roberson, Mar 3, 2008
    #14
  15. On Mar 3, 3:50 pm, jacob navia <> wrote:
    > This function is not mentioned very often in this newsgroup but it
    > is a VERY useful function, implemented in most compilers.
    >
    > I think it is useful to point to it since many people that read this
    > newsgroup are newcomers, and they could benefit by using it.
    >
    > This function is an allocation function, i.e. it is similar in
    > functionality to the malloc() function, but it has the advantage of
    > allocating from the stack instead of allocating from the heap.
    >
    > This means that the storage obtained can only be used within the scope
    > where this function was called, and can't be returned as the result of a
    > function call.
    >
    > The syntax is:
    >
    > void *alloca(size_t);
    >
    > It is not a function mentioned in the C standard, but it is
    > present under unix, windows and Mac, (all compilers) and
    > in most C implementations actually.
    >
    > What makes this function interesting is that
    > o It is very efficient. Since it allocates from the stack,
    > a few assembler instructions are needed, much quicker
    > than most "malloc" implementations.
    > o The storage is freed automatically when the function where
    > it is called exits. No need to call free().
    >
    > Caveats:
    >
    > o As I said above, the storage can't be returned from the current
    > function.
    > o There is the risk of stack overflow if you allocate too much memory
    > with it. If it fails it returns NULL, but do not count on it.
    >
    > Some people in this newsgroup will raise hell because it is a function
    > not mentioned in the standard. Since this is not comp.std.c I really do
    > not care, and I think that new users should be aware of its existence,
    > and the possible advantages and problems with its usage.
    >
    > --
    > jacob navia
    > jacob at jacob point remcomp point fr
    > logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32


    I'm amazed that you post this drivel. I guess you just like
    attention, and don't mind publicly attaching your name to really bad
    advice. Regardless of one's opinions on topicality or lack thereof of
    alloca, encouraging beginners (or experienced developers for that
    matter) to make a habit of using alloca is a foolish. The advantages
    you give are trivial ones compared to the risks -- efficiency can be
    achieved by other means such as custom memory allocation strategies,
    and calling free isn't really that hard. And the disadvantages are
    impossible to guard against. I'll let the man page on my system have
    the last word (perhaps you'd say it was written by one of the
    "clique").

    *****************
    The inlined code often consists of a single instruction
    adjusting the stack pointer, and does not check for stack overflow.
    Thus, there is no NULL error return.

    BUGS
    The alloca function is machine and compiler dependent. On many
    systems its implementation is buggy. Its use is discouraged.

    On many systems alloca cannot be used inside the list of
    arguments of a function call, because the stack space reserved by
    alloca would appear on the stack in the middle of the space for the
    function arguments.
    **********************

    -David
    David Resnick, Mar 3, 2008
    #15
  16. >>>>> "WR" == Walter Roberson <-cnrc.gc.ca> writes:

    WR> It is not possible to write a general alloca() that exists
    WR> outside of the intimate details of the ABI in use. It
    WR> therefore must not be thought of as belonging to C: it belongs
    WR> to the system extensions that C compiler provides for that
    WR> operating environment.

    While I concur that alloca() ought to be discussed in
    compiler-specific newsgroups, I think your reasoning is suspect. It
    is likewise impossible to write a general malloc() that exists outside
    of the intimate details of the ABI in use, and yet that belongs to C,
    and is frequently discussed here.

    alloca() is about as standard as gotoxy() or getch(); different
    compilers and libraries implement it differently or not at all, and so
    it doesn't belong in comp.lang.c, but in the newsgroup or other forum
    for the compiler in question.

    Charlton


    --
    Charlton Wilbur
    Charlton Wilbur, Mar 3, 2008
    #16
  17. Morris Dovey

    jacob navia Guest

    Kenneth Brody wrote:
    > jacob navia wrote:
    >> This function is not mentioned very often in this newsgroup but it
    >> is a VERY useful function, implemented in most compilers.

    >
    > [Referring to "alloca" in the subject, but not the body.]
    >
    >> I think it is useful to point to it since many people that read this
    >> newsgroup are newcomers, and they could benefit by using it.

    > [...]
    >> Some people in this newsgroup will raise hell because it is a function
    >> not mentioned in the standard. Since this is not comp.std.c I really do
    >> not care, and I think that new users should be aware of its existence,
    >> and the possible advantages and problems with its usage.

    >
    > Well, I find open(), select(), and socket() quite useful as well, and
    > they're available on every platform I use, but that doesn't make them
    > relevent to clc.
    >
    > And, to your mention as to how wide-spread it's availablility is, here
    > is what happens on my Windows system, with MSVC:
    >
    > ==========
    > C:\temp>type usenet.c
    > #include <stdio.h>
    > #include <stdlib.h>
    >
    > int main()
    > {
    > char *foo = alloca(100);
    > }
    >
    > C:\temp>cl usenet.c
    > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
    > Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
    >
    > usenet.c
    > usenet.c(6) : warning C4047: 'initializing' : 'char *' differs in levels of indi
    > rection from 'int '
    > Microsoft (R) Incremental Linker Version 6.00.8447
    > Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
    >
    > /out:usenet.exe
    > usenet.obj
    > usenet.obj : error LNK2001: unresolved external symbol _alloca
    > usenet.exe : fatal error LNK1120: 1 unresolved externals
    >
    > C:\temp>
    > ==========
    >


    Hi Kenneth
    1) Microsoft calls this function _alloca and NOT alloca.
    It is declared in malloc.h (or in my 64 bit version)
    in intrin.h

    2) This is since at least 10 years.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Mar 3, 2008
    #17
  18. In article <fqhtrv$t65$>, jacob navia <> wrote:
    >1) Microsoft calls this function _alloca and NOT alloca.


    Mmmm, but still

    >>> The syntax is:


    >>> void *alloca(size_t);


    ??

    That is, even though microsoft calls the function _alloca
    the microsoft user would still call alloca (no underscore)?
    If that is not the case, if the user has to call (e.g.,) _alloca
    then your "The syntax is" is not accurate. But that would
    appear to contradict your assertions of how widespread and
    portable it is.

    Sorry but my head is starting to hurt, trying to come up with
    ways that you could -somehow- be correct -and- not have
    contradicted yourself...
    --
    "Let me live in my house by the side of the road --
    It's here the race of men go by.
    They are good, they are bad, they are weak, they are strong
    Wise, foolish -- so am I;" -- Sam Walter Foss
    Walter Roberson, Mar 3, 2008
    #18
  19. Morris Dovey

    Bartc Guest

    "Eric Sosman" <> wrote in message
    news:1204580335.833631@news1nwk...
    > jacob navia wrote:
    >> This function [alloca] is not mentioned very often in this newsgroup but
    >> it
    >> is a VERY useful function, implemented in most compilers.
    >>
    >> I think it is useful to point to it since many people that read this
    >> newsgroup are newcomers, and they could benefit by using it.


    >> o As I said above, the storage can't be returned from the current
    >> function.
    >> o There is the risk of stack overflow if you allocate too much memory
    >> with it. If it fails it returns NULL, but do not count on it.

    >
    > You forgot
    >
    > o Even on systems where alloca() is available, it may fail
    > catastrophically in some contexts, for example
    >
    > ptr = fgets(alloca(SIZE), SIZE, stdin);


    Why should that failure be any more likely than:

    void fn()
    {char buffer[SIZE];
    ....
    ptr = fgets(buffer, SIZE, stdin);

    If the implementation uses a stack for alloca() and for local variables,
    then it seems stack overflow is equally likely.

    (In fact alloca() may make overflow less likely, in a chain of function
    calls, by not unconditionally allocating frame data, only as needed, and of
    the size needed.)

    --
    Bart
    Bartc, Mar 3, 2008
    #19
  20. Morris Dovey

    CBFalconer Guest

    jacob navia wrote:
    >
    > This function is not mentioned very often in this newsgroup but it
    > is a VERY useful function, implemented in most compilers.


    It is not mentioned because it does not exist in standard C, and
    programs calling it are no longer portable. It is not even
    implementable in a portable manner. If I am right about this, you
    can't even give topical code for it on this newsgroup.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.


    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Mar 3, 2008
    #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. jacob navia

    gcc and alloca

    jacob navia, Jul 14, 2004, in forum: C Programming
    Replies:
    32
    Views:
    1,967
    Keith Thompson
    Jul 16, 2004
  2. Nitin Bhardwaj

    Why didn't ANSI/ISO make alloca() standard?

    Nitin Bhardwaj, Jul 15, 2004, in forum: C Programming
    Replies:
    6
    Views:
    485
    Keith Thompson
    Jul 17, 2004
  3. Sushil
    Replies:
    20
    Views:
    592
    Dan Pop
    Jul 20, 2004
  4. Freejack

    Portable alloca() replacement?

    Freejack, Jan 18, 2005, in forum: C Programming
    Replies:
    9
    Views:
    494
    Villy Kruse
    Jan 19, 2005
Loading...

Share This Page