gcc and alloca

Discussion in 'C Programming' started by jacob navia, Jul 14, 2004.

  1. jacob navia

    jacob navia Guest

    Some people here have started saying that "alloca"
    is off topic, and they used the argument that the gcc
    compiler doesn't recognize it.

    They compile their code using the -ansi option, and
    (off course) the aptly named "pedantic" option.

    I am not related in anyway to the developers of the gcc
    compiler but seeing the facts of their implementation
    I can't imagine that they would take the effort of making
    a BUILT-IN (__builtin) function if they did not want
    people to use it.

    The gcc compiler in its *default* setting supports alloca
    even better than lcc-win32 since they made it a builtin.

    And this since ages!

    P.S.
    Under windows, you have to make a small assembler loop
    to touch the allocated pages as you walk down the stack.
    This would lead to a slight code bloat and I prefered
    the function call method.
     
    jacob navia, Jul 14, 2004
    #1
    1. Advertising

  2. jacob navia

    Ben Pfaff Guest

    "jacob navia" <> writes:

    > Some people here have started saying that "alloca"
    > is off topic, and they used the argument that the gcc
    > compiler doesn't recognize it.
    >
    > They compile their code using the -ansi option, and
    > (off course) the aptly named "pedantic" option.


    alloca() is not in the Standard. Therefore it is off-topic.
    --
    "When in doubt, treat ``feature'' as a pejorative.
    (Think of a hundred-bladed Swiss army knife.)"
    --Kernighan and Plauger, _Software Tools_
     
    Ben Pfaff, Jul 14, 2004
    #2
    1. Advertising

  3. jacob navia wrote:

    > Some people here have started saying that
    > "alloca" is off topic, and they used the argument that
    > the gcc compiler doesn't recognize it.
    >
    > They compile their code using the -ansi option
    > and (of course) the aptly named "pedantic" option.
    >
    > I am not related in anyway to the developers of the gcc
    > compiler but seeing the facts of their implementation
    > I can't imagine that they would take the effort
    > of making a BUILT-IN (__builtin) function
    > if they did not want people to use it.
    >
    > The gcc compiler in its *default* setting supports alloca
    > even better than lcc-win32 since they made it a builtin.
    >
    > And this since ages!
    >
    > P.S.
    > Under windows, you have to make a small assembler loop
    > to touch the allocated pages as you walk down the stack.
    > This would lead to a slight code bloat and I prefered
    > the function call method.


    Don't use alloca. It is obsolete.
    Use "variable length arrays" and the -std=c99 option.
     
    E. Robert Tisdale, Jul 14, 2004
    #3
  4. "E. Robert Tisdale" <> writes:
    [...]
    > Don't use alloca. It is obsolete.
    > Use "variable length arrays" and the -std=c99 option.


    ERT is correct. (For reasons I won't go into, this is worth pointing
    out.)

    --
    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.
     
    Keith Thompson, Jul 14, 2004
    #4
  5. >Some people here have started saying that "alloca"
    >is off topic, and they used the argument that the gcc
    >compiler doesn't recognize it.
    >
    >They compile their code using the -ansi option, and
    >(off course) the aptly named "pedantic" option.
    >
    >I am not related in anyway to the developers of the gcc
    >compiler but seeing the facts of their implementation
    >I can't imagine that they would take the effort of making
    >a BUILT-IN (__builtin) function if they did not want
    >people to use it.


    I believe that alloca() is impossible to implement correctly without
    making it a built-in and very difficult to either make work
    unrestricted or describe the limits of where you can use it and
    where you cannot even if it is a builtin. Early (e.g. a decade or
    two ago) versions of GCC that had it as a builtin got it wrong.
    Current versions may or may not handle it properly.

    A particular problem is that if alloca() is used as a function
    argument, arranging NOT to have the space end up somewhere in
    the middle of the arguments of the called function.

    Look at the generated code for this:

    foo(
    alloca(10),
    alloca(20),
    alloca(30),
    alloca(40),
    alloca(50),
    alloca(60),
    alloca(70),
    alloca(80),
    alloca(90),
    alloca(100),
    alloca(110),
    alloca(120),
    alloca(130),
    alloca(140),
    alloca(150),
    alloca(160),
    alloca(170),
    alloca(180),
    alloca(190)
    );

    and see if the arguments passed are 19 pointers and no part of an
    uninitialized memory area. If it calls alloca(), pushes the result,
    and repeats 19 times, it's going to get it wrong.

    Gordon L. Burditt
     
    Gordon Burditt, Jul 14, 2004
    #5
  6. jacob navia

    Richard Bos Guest

    "jacob navia" <> wrote:

    > Some people here have started saying that "alloca"
    > is off topic, and they used the argument that the gcc
    > compiler doesn't recognize it.


    Bullshit, and you know it, navia. alloca() is off-topic here because the
    Standard doesn't recognise it. gcc is as immaterial as your own little
    toy.

    Richard
     
    Richard Bos, Jul 14, 2004
    #6
  7. jacob navia

    jacob navia Guest

    The code generated by gcc under linux seems to me 100%
    correct. For the example you give, it will always save
    the result of alloca and do all the pushes later on, pushing
    the saved values.

    If your only argument is that this builtin may have had a bug
    around 10 years ago... well, I do not know what to say of such
    an argumentation other than:

    "There is no blinder man than the one that doesn't want to see"
     
    jacob navia, Jul 14, 2004
    #7
  8. jacob navia wrote:

    > I am not related in anyway to the developers of the gcc
    > compiler but seeing the facts of their implementation
    > I can't imagine that they would take the effort of making
    > a BUILT-IN (__builtin) function if they did not want
    > people to use it.


    "The alloca function is machine and compiler dependent. On many systems
    its implementation is buggy. Its use is dis­couraged."
    (from the alloca() man page on my SuSE sytem)

    Doesn't sound all that encouraging, does it?


    Christian
     
    Christian Kandeler, Jul 14, 2004
    #8
  9. jacob navia

    Dan Pop Guest

    In <> Keith Thompson <> writes:

    >"E. Robert Tisdale" <> writes:
    >[...]
    >> Don't use alloca. It is obsolete.
    >> Use "variable length arrays" and the -std=c99 option.

    >
    >ERT is correct. (For reasons I won't go into, this is worth pointing
    >out.)


    OTOH, alloca is *far* more portable than VLAs... Fortunately, it can
    be replaced by malloc and friends in most cases (the only excuse for using
    alloca is when malloc and friends render the code too slow for its
    intended purpose on its intended platform).

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 14, 2004
    #9
  10. jacob navia

    Dan Pop Guest

    In <cd2f1f$> (Gordon Burditt) writes:

    >A particular problem is that if alloca() is used as a function
    >argument, arranging NOT to have the space end up somewhere in
    >the middle of the arguments of the called function.
    >
    >Look at the generated code for this:
    >
    > foo(
    > alloca(10),
    > alloca(20),
    > alloca(30),
    > alloca(40),
    > alloca(50),
    > alloca(60),
    > alloca(70),
    > alloca(80),
    > alloca(90),
    > alloca(100),
    > alloca(110),
    > alloca(120),
    > alloca(130),
    > alloca(140),
    > alloca(150),
    > alloca(160),
    > alloca(170),
    > alloca(180),
    > alloca(190)
    > );
    >
    >and see if the arguments passed are 19 pointers and no part of an
    >uninitialized memory area. If it calls alloca(), pushes the result,
    >and repeats 19 times, it's going to get it wrong.


    OTOH, how often have you felt the need to use alloca this way?

    Although I'm far from being an alloca advocate, I find this example
    highly artificial and irrelevant for the typical use of alloca. Even if
    the sizes are not constant, as in your trivial example.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 14, 2004
    #10
  11. In article <cd3c5g$9g6$>, Dan Pop <> wrote:
    >(the only excuse for using
    >alloca is when malloc and friends render the code too slow for its
    >intended purpose on its intended platform).


    Or too complicated: stack-allocated space has the advantage of being
    automatically freed when the function returns, even if it "returns"
    as the result of a longjmp.

    -- Richard
     
    Richard Tobin, Jul 14, 2004
    #11
  12. jacob navia

    Villy Kruse Guest

    On 14 Jul 2004 05:06:55 GMT,
    Gordon Burditt <> wrote:


    >
    > I believe that alloca() is impossible to implement correctly without
    > making it a built-in and very difficult to either make work
    > unrestricted or describe the limits of where you can use it and
    > where you cannot even if it is a builtin. Early (e.g. a decade or
    > two ago) versions of GCC that had it as a builtin got it wrong.
    > Current versions may or may not handle it properly.
    >


    The gcc compiler itself uses or used to use alloca so it would be
    hard to compile the gcc compiler without a working alloca. For the
    bootstrap process there is a pseudo-alloca function including with
    the gcc source so you can use alloca even when the native compiler
    doesn't support it. I noticed this about a decade ago, so this may
    no longer be true.

    The various System V release 2 or 3 also had an alloca function hidden
    somewhere in an obscure library. It was neither documented, nor working
    properly on all platforms.

    Villy
     
    Villy Kruse, Jul 14, 2004
    #12
  13. jacob navia

    Alan Balmer Guest

    On Wed, 14 Jul 2004 01:51:21 +0200, "jacob navia"
    <> wrote:

    >Some people here have started saying that "alloca"
    >is off topic, and they used the argument that the gcc
    >compiler doesn't recognize it.


    No, they used the argument that "alloca" is not part of standard C.
    Give it up, Jacob. Even most of our newbies eventually realize that
    they are not going to change the declared topicality of this
    newsgroup. You've been here long enough that it's getting really
    annoying. You have a newsgroup of your own. Take this stuff over
    there.

    --
    Al Balmer
    Balmer Consulting
     
    Alan Balmer, Jul 14, 2004
    #13
  14. jacob navia

    Rob Thorpe Guest

    "jacob navia" <> wrote in message news:<cd2l56$q9v$>...
    > The code generated by gcc under linux seems to me 100%
    > correct. For the example you give, it will always save
    > the result of alloca and do all the pushes later on, pushing
    > the saved values.
    >
    > If your only argument is that this builtin may have had a bug
    > around 10 years ago... well, I do not know what to say of such
    > an argumentation other than:
    >
    > "There is no blinder man than the one that doesn't want to see"


    There are still outstanding problems with alloca in gcc, in particular
    how its implementation interacts with variable length arrays.

    I use it anyway.
     
    Rob Thorpe, Jul 14, 2004
    #14
  15. In 'comp.lang.c', "jacob navia" <> wrote:

    > Some people here have started saying that "alloca"
    > is off topic, and they used the argument that the gcc
    > compiler doesn't recognize it.


    Lousy argument. The truth is that, according to international standards, it
    doesn't belong to the definition of the C-language.

    BTW, on many platform where it was implemented (according what standard, who
    knows...) its usage is disencouraged (ranked obsolete or worst).

    http://www.hmug.org/man/3/alloca.html
    http://www.rt.com/man/alloca.3.html
    http://www.neosoft.com/neosoft/man/alloca.3.html
    etc.

    Topicality is another debatable question.

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jul 14, 2004
    #15
  16. jacob navia

    Dan Pop Guest

    In <cd3dkh$gbu$> (Richard Tobin) writes:

    >In article <cd3c5g$9g6$>, Dan Pop <> wrote:
    >>(the only excuse for using
    >>alloca is when malloc and friends render the code too slow for its
    >>intended purpose on its intended platform).

    >
    >Or too complicated: stack-allocated space has the advantage of being
    >automatically freed when the function returns, even if it "returns"
    >as the result of a longjmp.


    There is nothing preventing you from doing the cleanup *before* calling
    longjmp. And if the code is carefully designed, the cleanup is always
    trivial (just take care that each involved pointer is either null or
    allocated and call free() on all of them).

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 14, 2004
    #16
  17. In article <cd1shp$u94$>,
    jacob navia <> wrote:
    >Some people here have started saying that "alloca"
    >is off topic, and they used the argument that the gcc
    >compiler doesn't recognize it.
    >
    >They compile their code using the -ansi option, and
    >(off course) the aptly named "pedantic" option.


    This looks to me a whole lot like:
    "When you ask gcc to act like a C compiler, it doesn't recognize alloca.
    Therefore, alloca should be considered topical in a newsgroup that
    discusses C."

    I think one of us has serious comprehension problems today. I'll refrain
    from sharing my opinion about which one.


    dave

    --
    Dave Vandervies
    Of course, you're more likely to get bizarre answers, helpful compiler
    diagnostics, or, in the worst of all worlds, the answer you expected.
    --Chris Dollin in comp.lang.c
     
    Dave Vandervies, Jul 14, 2004
    #17
  18. In article <cd3sbt$odl$>, Dan Pop <> wrote:
    >In <cd3dkh$gbu$>
    >(Richard Tobin) writes:


    >>Or too complicated: stack-allocated space has the advantage of being
    >>automatically freed when the function returns, even if it "returns"
    >>as the result of a longjmp.

    >
    >There is nothing preventing you from doing the cleanup *before* calling
    >longjmp.


    That only works if you're calling longjmp directly from that function,
    and not from something that it calls.


    dave

    --
    Dave Vandervies
    Of course, you're more likely to get bizarre answers, helpful compiler
    diagnostics, or, in the worst of all worlds, the answer you expected.
    --Chris Dollin in comp.lang.c
     
    Dave Vandervies, Jul 14, 2004
    #18
  19. Alan Balmer <> writes:
    > On Wed, 14 Jul 2004 01:51:21 +0200, "jacob navia"
    > <> wrote:
    > >Some people here have started saying that "alloca"
    > >is off topic, and they used the argument that the gcc
    > >compiler doesn't recognize it.

    >
    > No, they used the argument that "alloca" is not part of standard C.
    > Give it up, Jacob. Even most of our newbies eventually realize that
    > they are not going to change the declared topicality of this
    > newsgroup. You've been here long enough that it's getting really
    > annoying. You have a newsgroup of your own. Take this stuff over
    > there.


    Actually, he doesn't. comp.compilers.lcc is about the lcc compiler
    <http://www.cs.princeton.edu/software/lcc/>, not just about lcc-win32
    <http://www.cs.virginia.edu/~lcc-win32/>.

    --
    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.
     
    Keith Thompson, Jul 14, 2004
    #19
  20. jacob navia

    Alan Balmer Guest

    On Wed, 14 Jul 2004 18:57:08 GMT, Keith Thompson <>
    wrote:

    >Alan Balmer <> writes:
    >> On Wed, 14 Jul 2004 01:51:21 +0200, "jacob navia"
    >> <> wrote:
    >> >Some people here have started saying that "alloca"
    >> >is off topic, and they used the argument that the gcc
    >> >compiler doesn't recognize it.

    >>
    >> No, they used the argument that "alloca" is not part of standard C.
    >> Give it up, Jacob. Even most of our newbies eventually realize that
    >> they are not going to change the declared topicality of this
    >> newsgroup. You've been here long enough that it's getting really
    >> annoying. You have a newsgroup of your own. Take this stuff over
    >> there.

    >
    >Actually, he doesn't. comp.compilers.lcc is about the lcc compiler
    ><http://www.cs.princeton.edu/software/lcc/>, not just about lcc-win32
    ><http://www.cs.virginia.edu/~lcc-win32/>.


    Well, yeah, he doesn't own it ;-) I haven't monitored it, but if he
    mentions his version as often there as he does here, it's probably
    mostly his <G>.

    --
    Al Balmer
    Balmer Consulting
     
    Alan Balmer, Jul 14, 2004
    #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. Replies:
    8
    Views:
    463
  2. Nitin Bhardwaj

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

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

    Portable alloca() replacement?

    Freejack, Jan 18, 2005, in forum: C Programming
    Replies:
    9
    Views:
    521
    Villy Kruse
    Jan 19, 2005
  5. Morris Dovey

    alloca

    Morris Dovey, Mar 3, 2008, in forum: C Programming
    Replies:
    96
    Views:
    3,280
    Dik T. Winter
    Mar 7, 2008
Loading...

Share This Page