Thread: How bad is it to use alloca()?

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

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.

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

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

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.

Then you're missing about 90% of the market.

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?

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