Like Tree9Likes

How bad is it to use alloca()?

This is a discussion on How bad is it to use alloca()? within the C++ Programming forums, part of the General Programming Boards category; It's a shame it looks like it's not going to be in the C++14 standard. That's lame. I guess alloca() ...

  1. #16
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,188
    It's a shame it looks like it's not going to be in the C++14 standard. That's lame. I guess alloca() will have to do for now but man, having iterators for that'd be awesome too
    O_o

    So, give your `alloca' array iterators.

    You only need an object to hold a reference to the address with a destructor (Well, you do if you are using elements that need to be processed.) to delete elements and a few one line methods.

    Seriously, that should take ten minutes tops.

    Soma
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  2. #17
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,012
    That is true but it'd also be nice if the STL creators would incorporate it into the standard as well.

  3. #18
    Registered User
    Join Date
    Apr 2013
    Posts
    1,263
    I don't understand the reluctance to use alloca() if it's the best solution to the problem in this case, and it's not deprecated in C++.

  4. #19
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,457
    Quote Originally Posted by rcgldr
    I don't understand the reluctance to use alloca() if it's the best solution to the problem in this case, and it's not deprecated in C++.
    It is not deprecated because it is non-standard to begin with.
    Hodor likes this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #20
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,188
    I don't understand the reluctance to use alloca() if it's the best solution to the problem in this case, and it's not deprecated in C++.
    O_o

    Well, laserlight already hit the major part of the issue; (Seriously, are you a cyborg?) still, I'd just like to point out that does not have well-defined semantics across compilers. (Example: You may actually be able to check for `NULL' on some platforms, but other platforms simply crash and burn allowing no method of recovery.) That alone would make most programmers reluctant.

    Soma
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  6. #21
    Registered User Hodor's Avatar
    Join Date
    Nov 2013
    Posts
    650
    Quote Originally Posted by laserlight View Post
    It is not deprecated because it is non-standard to begin with.
    Heck, it's not even POSIX. The (GNU) man page looks like a mystery investigation trying to determine its origin.

  7. #22
    Registered User Hodor's Avatar
    Join Date
    Nov 2013
    Posts
    650
    Quote Originally Posted by phantomotap View Post
    O_o

    Well, laserlight already hit the major part of the issue; (Seriously, are you a cyborg?) still, I'd just like to point out that does not have well-defined semantics across compilers. (Example: You may actually be able to check for `NULL' on some platforms, but other platforms simply crash and burn allowing no method of recovery.) That alone would make most programmers reluctant.
    To be fair, any auto object that's too large for the "stack" is going to simply crash and burn anyway. It seems, to me, that alloca() offers very few advantages (perhaps pre c99 it was a kind of substitute for VLAs?) and none compelling enough for me to actually use it. *shrug*

  8. #23
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,188
    To be fair, any auto object that's too large for the "stack" is going to simply crash and burn anyway.
    O_o

    That is true, but I fear you went the wrong direction. The comparison wasn't made over stack objects but over reliability and recovery. The use of `malloc' and friends have well-defined semantics across a massive number of platforms, and with those functions, you do have an option to, at least, crash and burn gracefully.

    Soma
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  9. #24
    Registered User Hodor's Avatar
    Join Date
    Nov 2013
    Posts
    650
    Quote Originally Posted by phantomotap View Post
    O_o

    That is true, but I fear you went the wrong direction. The comparison wasn't made over stack objects but over reliability and recovery. The use of `malloc' and friends have well-defined semantics across a massive number of platforms, and with those functions, you do have an option to, at least, crash and burn gracefully.
    I don't think I went the wrong direction at all... neither:

    Code:
    // alloc some memory on the stack
    char *mem = alloca(909204922490);
    nor

    Code:
    // alloc some memory on the stack
    char mem[909204922490];
    are going to fail gracefully, and neither allow recovery either.

    I would use malloc(). I'm not arguing against that (I can't think of a reason why I'd use alloca())

  10. #25
    Registered User
    Join Date
    Jun 2005
    Posts
    6,208
    alloca() is non-standard. To me, that is sufficient grounds not to use it. If it enters a standard, which I doubt, I would reconsider that position.


    If it is standardised in its current form, I would never use alloca() in production code. From a couple of descriptions available about its return value "The alloca() function returns a pointer to the beginning of the allocated space. If the allocation causes stack overflow, program behavior is undefined." That means, if the function fails in any way, there is no way to detect that. Since alloca() allocates from the stack, where "stack" has a significance related to ensuring ALL function call/return mechanisms in a program (including of alloca() itself), that means it has potential to screw up the basic working of a running program, with no means of detection, let alone recovery. That is a pretty significant deficiency.



    Historically, BTW, alloca() originated in PWB (Programmers Work Bench) which was a software suite used to support computer centres using very early versions of AT&T unix. The fact it is not in any modern standard (all implementations are vendor specific, for "legacy support") is a pretty fair hint of its limitations and dangers.
    stahta01 likes this.
    Right 98% of the time, and don't care about the other 3%.

  11. #26
    Registered User Hodor's Avatar
    Join Date
    Nov 2013
    Posts
    650
    Quote Originally Posted by grumpy View Post
    Historically, BTW, alloca() originated in PWB (Programmers Work Bench) which was a software suite used to support computer centres using very early versions of AT&T unix. The fact it is not in any modern standard (all implementations are vendor specific, for "legacy support") is a pretty fair hint of its limitations and dangers.
    That's twice today you've given a historical reason (thanks). Perhaps you need to change your signature to include "C Museum Curator"
    laserlight likes this.

  12. #27
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,012
    It's a variable length array that's pedantic and is faster than new(). That's why I use it. It seems to work fine if you use it wisely. As for it being portable, heck if I know. I don't care if Windows can't do something Linux can because I hate Windows.

  13. #28
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,455
    Then you're missing about 90% of the market.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #29
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,457
    Quote Originally Posted by MutantJohn
    It's a variable length array that's pedantic and is faster than new(). That's why I use it. It seems to work fine if you use it wisely.
    Generally, being pedantic means that you're a stickler for the rules, and the rules in play here are that of C++11, which state that alloca is not part of the game, by omission. So, if you want to be pedantic, you will not use alloca, even if you don't get a warning with the -pedantic flag when compiling with g++ since, to be pedantic, the -pedantic flag does not enable a strict check for C++ standard conformance.

    Anyway, have you compared this to actually using a variable length array?
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #30
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,188
    That's why I use it. It seems to work fine if you use it wisely. As for it being portable, heck if I know. I don't care if Windows can't do something Linux can because I hate Windows.
    O_o

    The things you hear when you don't have an elephant gun, a sack of lime, and deep hole.

    *shrug*

    Anyway, `alloca' support has nothing to do with the operating system; the function is or is not a feature of a compiler.

    Look at the example from Hodor:

    Code:
    char *mem = alloca(909204922490);
    With many implementations of `alloca', you have no way of knowing if the allocation was successful, and without that information "use it wisely" is off the table. Unlike simple over-allocation or "VLA", the problem here isn't born simply of overflowing the stack; the unreliability of the implementations (The return value being undefined with problematic allocation is only one problem area.) is unsuitable for stable code even when overflow doesn't occur.

    [Edit]
    By the by Hodor, this is where you went in the wrong direction. The over-allocation as with "VLA" or other automatic variable has nothing to do with my comments. The poorly defined and respected semantics make `alloca' a big potential for crash and burn whether the stack overflows or not.
    [/Edit]

    Code:
    DoSomething(alloca(1), alloca(1));
    Even though this sample code is extremely unlikely to overflow the stack under normal circumstances, this sample has an extreme potential for incredibly difficult to debug problems.

    Code:
    void * s = alloca(1);
    DoSomething(s, alloca(1));
    This simple code has the same problem.

    Code:
    void * s1 = alloca(1);
    DoSomething(s, 0);
    void * s2 = alloca(1);
    This simple example may also fail for similar reasons.

    Of course, just because reality can be a pain, these simple examples all work differently with different implementations though when faulty they all crash and burn. With some compilers, the second and third may work fine, but with other compilers only the first and second work, and in all of those cases, the client code has no way of inspecting for such faults.

    [Edit]
    Naturally, anyone may use whatever they wish; Yog Sothoth knows I use an awful, filthy sort of hack in my libraries, but MutantJohn, you shouldn't use it without considerable effort in understanding exactly where and how support for `alloca' works.

    That last bit was unnecessarily condescending, and though I in no way intended that I still do apologize. I'm sorry for that.

    Let me instead put it this way: `alloca' is more difficult to implement correctly than one might think and even that is before the optimizer gets involved, so before you continue to use it, spend some time familiarizing yourself with the sins of the particular implementation you use.
    [/Edit]

    Soma
    Last edited by phantomotap; 01-23-2014 at 01:53 AM.
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

Page 2 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. portable alloca
    By wiglaf in forum C Programming
    Replies: 4
    Last Post: 02-16-2011, 11:34 PM
  2. alloca() function
    By budala in forum C Programming
    Replies: 8
    Last Post: 04-28-2010, 10:09 AM
  3. alloca.h
    By kryptkat in forum C Programming
    Replies: 4
    Last Post: 11-15-2009, 11:34 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21