Making alloca more safe
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Mon Nov 16 09:39:57 PST 2009
Denis Koroskin wrote:
> On Mon, 16 Nov 2009 19:27:41 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> bearophile wrote:
>>> Walter Bright:
>>>
>>>> A person using alloca is expecting stack allocation, and that it
>>>> goes away after the function exits. Switching arbitrarily to the gc
>>>> will not be detected and may hide a programming error (asking for a
>>>> gigantic piece of memory is not anticipated for alloca, and could be
>>>> caused by an overflow or logic error in calculating its size).
>>> There's another solution, that I'd like to see more often used in
>>> Phobos: you can add another function to Phobos, let's call it salloca
>>> (safe alloca) that does what Denis Koroskin asks for (it's a very
>>> simple function).
>>
>> Can't be written. Try it.
>>
>> Andrei
>
> It's tricky. It can't be written *without a compiler support*, because
> it is considered special for a compiler (it always inlines the call to
> it). It could be written otherwise.
>
> I was thinking about proposing either an inline keyword in a language
> (one that would enforce function inlining, rather than suggesting it to
> compiler), or allways inline all the functions that make use of alloca.
> Without either of them, it is impossible to create wrappers around
> alloca (for example, one that create arrays on stack type-safely and
> without casts):
>
> T[] array_alloca(T)(size_t size) { ... }
>
> or one that would return GC-allocated memory when stack allocation fails:
>
> void* salloca(size_t size) {
> void* ptr = alloca(size);
> if (ptr is null) return (new void[size]).ptr;
>
> return ptr;
> }
The problem of salloca is that alloca's memory gets released when
salloca returns.
Andrei
More information about the Digitalmars-d
mailing list