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

Discussion in 'C Programming' started by Nitin Bhardwaj, Jul 15, 2004.

  1. Hi all,

    I want to know what is wrong with alloca() ?

    Is it hard to implement in a platform-independent way?
    OR there is no need for it?

    AFAIK alloca() /*(used to)*/ allocate memory at run-time from the
    function stack, so that the programmer need not call free() to
    de-allocate it.Since it automatically got freed when the function
    returns, Right?

    So what is wrong with implementing such a function..why doesn't the
    Standard provide this function?

    Thanks.
     
    Nitin Bhardwaj, Jul 15, 2004
    #1
    1. Advertising

  2. Nitin Bhardwaj

    Richard Bos Guest

    (Nitin Bhardwaj) wrote:

    > Is it hard to implement in a platform-independent way?
    > OR there is no need for it?


    Both. RTFAQ: <http://www.eskimo.com/~scs/C-faq/q7.32.html>.

    Richard
     
    Richard Bos, Jul 15, 2004
    #2
    1. Advertising

  3. Nitin Bhardwaj

    Dan Pop Guest

    In <> (Nitin Bhardwaj) writes:

    >I want to know what is wrong with alloca() ?
    >
    >Is it hard to implement in a platform-independent way?
    >OR there is no need for it?
    >
    >AFAIK alloca() /*(used to)*/ allocate memory at run-time from the
    >function stack, so that the programmer need not call free() to
    >de-allocate it.Since it automatically got freed when the function
    >returns, Right?
    >
    >So what is wrong with implementing such a function..why doesn't the
    >Standard provide this function?


    Whenever you have such questions, look up the (freely available) C
    standard rationale document, first. ONLY if you find nothing there
    ask here.

    Some implementations provide a function (often called alloca) which
    allocates the requested object from automatic storage; the object is
    automatically freed when the calling function exits. Such a function
    is not efficiently implementable in a variety of environments, so it
    was not adopted in the Standard.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 15, 2004
    #3
  4. Nitin Bhardwaj

    Walter Guest

    "Richard Bos" <> wrote in message
    news:...
    > (Nitin Bhardwaj) wrote:
    >
    > > Is it hard to implement in a platform-independent way?
    > > OR there is no need for it?

    >
    > Both. RTFAQ: <http://www.eskimo.com/~scs/C-faq/q7.32.html>.


    alloca can be tricky to implement correctly, as the FAQ points out. The
    compilers I've used that did implement it all did implement it correctly,
    even if there were already things on the stack like partial function
    arguments. alloca is pretty handy for fast allocation of temporary buffers -
    it's thread safe, exception safe, and the automatic cleanup is nice when a
    function has complex logic with multiple exits.

    I've had to port some code that used alloca to a system that couldn't
    support it. The result usually was an uglification of the code, as a bunch
    of code needed to be added to keep track of all the allocated bits so they
    could be properly cleaned up.

    Fortunately, I don't have to use that miserable system any more <g>, and I
    regularly use alloca. It's portable to all the compilers I need to use. I
    like alloca, and put it in the D programming language as well.

    Sure, alloca is not in the C standard. But that standard specifies a minimum
    standard, the realities of the compiler business are that alloca will be
    supported if it is reasonably feasible to get it to work on the system.

    -Walter
    www.digitalmars.com free C/C++/D compilers
     
    Walter, Jul 15, 2004
    #4
  5. Nitin Bhardwaj

    Dan Pop Guest

    In <KBCJc.81990$JR4.74655@attbi_s54> "Walter" <> writes:


    >"Richard Bos" <> wrote in message
    >news:...
    >> (Nitin Bhardwaj) wrote:
    >>
    >> > Is it hard to implement in a platform-independent way?
    >> > OR there is no need for it?

    >>
    >> Both. RTFAQ: <http://www.eskimo.com/~scs/C-faq/q7.32.html>.

    >
    >alloca can be tricky to implement correctly, as the FAQ points out. The
    >compilers I've used that did implement it all did implement it correctly,
    >even if there were already things on the stack like partial function
    >arguments. alloca is pretty handy for fast allocation of temporary buffers -
    >it's thread safe, exception safe, and the automatic cleanup is nice when a
    >function has complex logic with multiple exits.
    >
    >I've had to port some code that used alloca to a system that couldn't
    >support it. The result usually was an uglification of the code, as a bunch
    >of code needed to be added to keep track of all the allocated bits so they
    >could be properly cleaned up.
    >
    >Fortunately, I don't have to use that miserable system any more <g>, and I
    >regularly use alloca. It's portable to all the compilers I need to use. I
    >like alloca, and put it in the D programming language as well.
    >
    >Sure, alloca is not in the C standard. But that standard specifies a minimum
    >standard, the realities of the compiler business are that alloca will be
    >supported if it is reasonably feasible to get it to work on the system.


    And, as you learned yourself, code relying on it will not be portable to
    systems where alloca is not reasonably feasible. If none of the
    implementors in the C committee had any problems supporting alloca, I am
    reasonably convinced that it would have been part of the standard C
    library. There was plenty of existing practice for alloca, at the time
    C89 was drafted.

    Likewise, the rather strange and arbitrary conditions imposed by the
    standard to the usage of the setjmp macro (even H&S got them wrong,
    in their example code) are the result of requests made by implementors,
    who needed them in order to get this macro to work on their supported
    platforms.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 16, 2004
    #5
  6. Nitin Bhardwaj

    LibraryUser Guest

    Nitin Bhardwaj wrote:
    >
    > I want to know what is wrong with alloca() ?
    >
    > Is it hard to implement in a platform-independent way?
    > OR there is no need for it?


    In addition to the other answers, it is effectively implemented
    in C99, by the use of 'adjustable arrays'.

    --
    Replies should be to the newsgroup
    Replace this line to publish your e-mail address.
     
    LibraryUser, Jul 16, 2004
    #6
  7. LibraryUser <> writes:
    > Nitin Bhardwaj wrote:
    > >
    > > I want to know what is wrong with alloca() ?
    > >
    > > Is it hard to implement in a platform-independent way?
    > > OR there is no need for it?

    >
    > In addition to the other answers, it is effectively implemented
    > in C99, by the use of 'adjustable arrays'.


    I think you mean variable length arrays (VLAs). The term 'adjustable
    arrays' would imply that the length can be changed after the object is
    created, a feature that VLAs don't support.

    There are some differences. A VLA can only be created in a
    declaration; alloca() can be called in the middle of an expression
    (which can cause problems in function calls). Also, the number of
    VLAs created in a given scope is fixed, whereas alloca() can be called
    an arbitrary number of times. For example, a function using could
    create a linked list of N alloca()-allocated nodes, where N is a
    parameter; that can't be done with VLAs. (Well, maybe with some ugly
    tricks involving recursion, but I'm not going to figure out how to do
    it).

    --
    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 17, 2004
    #7
    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. Chris Mantoulidis

    ISO/ANSI C++ Standard copy

    Chris Mantoulidis, Dec 11, 2003, in forum: C++
    Replies:
    3
    Views:
    2,792
    Andrew Koenig
    Dec 13, 2003
  2. skoco
    Replies:
    20
    Views:
    771
    Albert van der Horst
    Feb 25, 2004
  3. Stephen Tyndall
    Replies:
    5
    Views:
    485
  4. Replies:
    2
    Views:
    599
    Ioannis Vranos
    Dec 18, 2004
  5. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,072
    Smokey Grindel
    Dec 2, 2006
Loading...

Share This Page