«

In article <>, Dik T. Winter <> wrote:
>Moreover, there are systems where it is *not* implementable as such and
>would be just an alias for malloc (now, who cares about a memory leak).

It could perfectly well be implemented as malloc() with free() on return
or longjmp().

-- Richard
--
:wq

In article <fqk1tl$oco$> Andrey Tarasevich <> writes:
> Eric Sosman wrote:
....
> > It's not obvious to me, but I've used fewer than fifty
> > C implementations and my experience may not be as broad as
> > yours. How many implementations did you study before
> > reaching your conclusion?
>
> I don't exactly understand why you seem to assume that my conclusion is
> supposed to be based specifically on "studying implementations". I already
> explained that my conclusion is based solely on the fact of the existence
> of VLAs. I already commented the differences between VLAs and 'alloca'.
> Exhaustively, in my opinion.

There are differences that make VLAs more easy to implement on some systems.
Consider a system where the stack is used only to contain stuff used for
function entry (and is actually a stack, because the size used for entry
is the same for *every* function). Local variables are allocated in some
way from the heap. The function *knows* how much to deallocate when the
function exits, it is also able to find out how much to deallocate for
VLAs.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

Dik T. Winter wrote:
> >
> > I don't exactly understand why you seem to assume that my conclusion is
> > supposed to be based specifically on "studying implementations". I already
> > explained that my conclusion is based solely on the fact of the existence
> > of VLAs. I already commented the differences between VLAs and 'alloca'.
> > Exhaustively, in my opinion.
>
> There are differences that make VLAs more easy to implement on some systems.
> Consider a system where the stack is used only to contain stuff used for
> function entry (and is actually a stack, because the size used for entry
> is the same for *every* function). Local variables are allocated in some
> way from the heap. The function *knows* how much to deallocate when the
> function exits, it is also able to find out how much to deallocate for
> VLAs.

And the 'alloca' does not fit into that picture how exactly?

--
Best regards,
Andrey Tarasevich

(Richard Tobin) writes:
> In article <>, Dik T. Winter <> wrote:
>>Moreover, there are systems where it is *not* implementable as such and
>>would be just an alias for malloc (now, who cares about a memory leak).
>
> It could perfectly well be implemented as malloc() with free() on return
> or longjmp().

Yes, it could, but it wouldn't be entirely trivial. Consider an
alloca() call in a loop. Consider the result of alloca() being
assigned to an object that goes out of scope before the end of the
function.

The code generated by the compiler would have to maintain a list (with
nodes allocated by malloc()) of pointers to alloca()-allocated blocks,
and traverse that list before leaving the function.

That's a lot of overhead for something that's supposed to be *simpler*
than malloc().

--
Keith Thompson (The_Other_Keith) <kst->
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Chris Torek <> wrote:
>
> Yes: the Standard says that setjmp is a macro, not a function.
> Incidentally, this makes a number of implementations non-conforming
> simply because they happen to use a function instead of a macro.

No, that's covered by 7.13p3:

It is unspecified whether setjmp is a macro or an identifier
declared with external linkage. If a macro definition is
suppressed in order to access an actual function, or a program
defines an external identifier with the name setjmp, the
behavior is undefined.

-Larry Jones

Let's pretend I already feel terrible about it, and that you
don't need to rub it in any more. -- Calvin

user923005 wrote:
> ...
> No, but I made my own version that does (it relies on non-portable
> stuff).
>
>
> void *alloca(size_t size)
> {
> void *p;
> __try
> {
> p = _alloca(size);
> }
> __except(GetExceptionCode() == STATUS_STACK_OVERFLOW) {
> int result = _resetstkoflw();
> return NULL;
> }
> return p;
> }
> ...

This implementation makes no sense. You can't wrap 'alloca' (or
'_alloca') calls into another function. The memory you allocated gets
automatically freed as you exit the wrapper. As a result, two
consecutive calls to your 'alloca' wrapper will most likely "allocate"
the same memory with obviously disastrous consequences.

If you want to produce your own version of 'alloca' by "wrapping" the
original, the only option you have is to wrap it into a macro.

--
Best regards,
Andrey Tarasevich

In article <fqmocl$q6f$>,
Andrey Tarasevich <> wrote:

>If you want to produce your own version of 'alloca' by "wrapping" the
>original, the only option you have is to wrap it into a macro.

If you are sufficiently confident of your implementation (and this
code was certainly implementation-dependent), an inline function may
work.

-- Richard
--
:wq

In article <>,
Keith Thompson <kst-> wrote:

>> It could perfectly well be implemented as malloc() with free() on return
>> or longjmp().

>The code generated by the compiler would have to maintain a list (with
>nodes allocated by malloc()) of pointers to alloca()-allocated blocks,
>and traverse that list before leaving the function.

Yes, though the list's pointers could be in the malloc()ed blocks
themselves.

>That's a lot of overhead for something that's supposed to be *simpler*
>than malloc().

Being cheap is certainly one of the aims of alloca(), but it's also
useful merely as an allocator of memory with dynamic extent.

And remember we're talking about implementing on systems where it's
for some reason impossible to allocate on the stack: that design
choice has its consequences, and it's not C's job to conceal them.

-- Richard
--
:wq

On Mar 4, 8:56*pm, gordonb.84...@burditt.org (Gordon Burditt) wrote:
> >> >VLAs have a fatal flaw. =A0What happens if there is not enough auto
> >> >memory for the allocation?
>
> >> >alloca() could overcome that by returning NULL in that instance.
>
> >> Do you know of any implementation of alloca() that actually DOES that?
>
> Oh, yes, I should have also asked for an implementation that actually
> DOCUMENTS that alloca() returns NULL on failure, regardless of what
> the code does.
>
> >> I don't believe gcc does.
>
> >No, but I made my own version that does (it relies on non-portable
> >stuff).
>
> Ok, alloca() usually relies on unportable stuff and hooks into the compiler.
>
>
>
>
>
> >C:\tmp>cl /D__STDC__ /DUNIT_TEST alloca.c
> >Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762
> >for 80x86
> >Copyright (C) Microsoft Corporation. *All rights reserved.
>
> >alloca.c
> >Microsoft (R) Incremental Linker Version 8.00.50727.762
> >Copyright (C) Microsoft Corporation. *All rights reserved.
>
> >/out:alloca.exe
> >alloca.obj
>
> >C:\tmp>alloca
> >alloca(100) succeeded!
> >alloca(1000000000) failed.
>
> >C:\tmp>type alloca.c
>
> >/*
> >OK, so it's not really C.
> >But this shows that an implementation specific compiler can 'do the
> >right thing'.
> >IMO-YMMV
> >*/
> >#include <windows.h>
> >#include <malloc.h>
> >#include <excpt.h>
>
> >void *alloca(size_t size)
> >{
> > * *void *p;
> > * *__try
> > * *{
> > * * * *p =3D _alloca(size);
> > * *}
> > * *__except(GetExceptionCode() =3D=3D STATUS_STACK_OVERFLOW) {
> > * * * *int * * * * * * result =3D _resetstkoflw();
> > * * * *return NULL;
> > * *}
> > * *return p;
> >}
>
> Um, HOLD IT! *Doesn't, by definition, the storage allocated by
> _alloca(), which I presume is Microsoft's implementation of alloca(),
> get freed when the function calling _alloca() returns? *Doesn't
> that mean that your alloca() returns a pointer to already-freed
> storage? *That won't work very well. *alloca() doesn't like wrappers.
>
> Also, are you guaranteed to get an exception if you overflow the
> stack? *Ok, if you overflow it by a meg or less, probably. *If you
> overflow it by the address difference between the current stack
> pointer and &main, (say, a few gigabytes) maybe not. *You have
> demonstrated a halfway reasonable way of stack checking that probably
> works most of the time.
>
>
>
>
>
> >#ifdef UNIT_TEST
> >#include <stdio.h>
> >int * * * * * * main(void)
> >{
> > * *size_t *size =3D 100;
> > * *char * **p =3D alloca(size);
> > * *if (p =3D=3D NULL)
> > * * * *printf("alloca(%u) failed.\n", (unsigned) size);
> > * *else
> > * * * *printf("alloca(%u) succeeded!\n", size);
> > * *size =3D 1000000000;
> > * *p =3D alloca(size);
> > * *if (p =3D=3D NULL)
> > * * * *printf("alloca(%u) failed.\n", (unsigned) size);
> > * *else
> > * * * *printf("alloca(%u) succeeded!\n", size);
> > * *return 0;
> >}
> >#endif

Quite right. This is an example where it would have to be implemented
as a function-like macro.
Enough reason not to try it right there.

user923005 wrote:
> On Mar 3, 12:50 pm, jacob navia <ja...@nospam.com> wrote:
>>
>> Some people in this newsgroup will raise hell because it is a function
>> not mentioned in the standard. Since this is not comp.std.c I really do
>> not care,

huw unsurprising that yet again, you totally ignore topicality.

> There is no function called alloca() using Microsoft Visual C++,

And therein lies one of the problems of Jacob's stupid post.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>