Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > alloca

Reply
Thread Tools

alloca

 
 
Chris Torek
Guest
Posts: n/a
 
      03-04-2008
>In article <(E-Mail Removed)>,
>Gordon Burditt <(E-Mail Removed)> wrote:
>> This means that if you take the address of alloca(), put it in a function
>> pointer, and then call it indirectly, unless the compiler can figure
>> out that it might be a call to alloca(), it is likely to malfunction.


In article <fqi8l9$1p32$(E-Mail Removed)>
Richard Tobin <(E-Mail Removed)> wrote:
>No-one in their right mind would do that Incidentally, does the
>standard prohibit doing it with setjmp()?


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.
(A conforming program can discover this via #ifndef:

#include <setjmp.h>

#ifndef setjmp
# error "setjmp is not a macro"
#endif

The cure for this is to define a macro that calls the function:

#define setjmp setjmp

in <setjmp.h> will suffice.)

The "does not work through function pointer" problem (for alloca())
can thus be overcome in a future standard in the same way that it
was for setjmp(). (This does not mean I think a future standard
*should* attempt to standardize alloca(), nor that I think it should
not. There are tradeoffs here and I have not attempted to study
them sufficiently.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
 
Reply With Quote
 
 
 
 
Richard Tobin
Guest
Posts: n/a
 
      03-04-2008
In article <(E-Mail Removed)>,
Richard Heathfield <(E-Mail Removed)> wrote:

>Typical alloca implementations return NULL on failure


I think it's rather difficult to do that on many systems, and this is
equally true for any other stack-allocated memory. Unix systems for
example extend the stack as required up to a settable limit; to find
out whether the allocation will succeed you have to either (a)
determine the limit (which may change, so you need to check it each
time), or (b) try accessing the memory, which will result in a
segmentation fault if it fails, which the user may already be
catching.

-- Richard
--
:wq
 
Reply With Quote
 
 
 
 
Richard Tobin
Guest
Posts: n/a
 
      03-04-2008
In article <(E-Mail Removed)>,
Chris Torek <(E-Mail Removed)> wrote:

>>No-one in their right mind would do that Incidentally, does the
>>standard prohibit doing it with setjmp()?


>Yes: the Standard says that setjmp is a macro, not a function.


That doesn't quite answer the question. For example, if we have

> #define setjmp setjmp


then it will still "work" to assign it to a function pointer. Is the
assignment undefined behaviour?

-- Richard
--
:wq
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      03-04-2008
[Richard Tobin, I think, asked:]
>>>... does the standard prohibit [taking the address of] setjmp()?

>
>In article <(E-Mail Removed)>,
>Chris Torek <(E-Mail Removed)> wrote:
>>Yes: the Standard says that setjmp is a macro, not a function.


In article <fqk6j9$2d8n$(E-Mail Removed)>,
Richard Tobin <(E-Mail Removed)> wrote:
>That doesn't quite answer the question. For example, if we have
>
>> #define setjmp setjmp

>
>then it will still "work" to assign it to a function pointer. Is the
>assignment undefined behaviour?


Although it will "work" in terms of not producing an immediate
error, it is indeed undefined behavior. The Standard never says
anything one way or the other about computing addresses of macros
in general, so, by specifying that setjmp is a "macro", and failing
to say anything about taking the address of whatever that macro
expands to, the Standard effectively forbids the programmer from
taking the address, without requiring implementors to make their
implementation produce a diagnostic.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      03-04-2008
Richard Heathfield wrote:
>

.... snip ...
>
> I sense a disturbance in the Force - and not an unwelcome one, from
> my perspective. Nevertheless, you are expressing a minority view.


Amusing. Time after time I see a response to something by someone,
followed (in varying orders) by responses from Twink, Richard,
McCormack, all caught by my troll filter. Sometimes they go around
again.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      03-04-2008
Chris Torek wrote:
> [Richard Tobin, I think, asked:]
>
>> That doesn't quite answer the question. For example, if we have
>>
>> #define setjmp setjmp
>>
>> then it will still "work" to assign it to a function pointer.
>> Is the assignment undefined behaviour?

>
> Although it will "work" in terms of not producing an immediate
> error, it is indeed undefined behavior. The Standard never says
> anything one way or the other about computing addresses of macros
> in general, so, by specifying that setjmp is a "macro", and
> failing to say anything about taking the address of whatever that
> macro expands to, the Standard effectively forbids the programmer
> from taking the address, without requiring implementors to make
> their implementation produce a diagnostic.


But, I believe, the standard says that a macro expansion will not
recurse, so that the expansion will leave the word 'setjmp'. Now,
in a later phase, that tries to call something.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      03-05-2008
>VLAs have a fatal flaw. What 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?
I don't believe gcc does.

 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      03-05-2008
On Mar 4, 4:12*pm, (E-Mail Removed) (Gordon Burditt) wrote:
> >VLAs have a fatal flaw. *What 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?
> I don't believe gcc does.


No, but I made my own version that does (it relies on non-portable
stuff).

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 = _alloca(size);
}
__except(GetExceptionCode() == STATUS_STACK_OVERFLOW) {
int result = _resetstkoflw();
return NULL;
}
return p;
}

#ifdef UNIT_TEST
#include <stdio.h>
int main(void)
{
size_t size = 100;
char *p = alloca(size);
if (p == NULL)
printf("alloca(%u) failed.\n", (unsigned) size);
else
printf("alloca(%u) succeeded!\n", size);
size = 1000000000;
p = alloca(size);
if (p == NULL)
printf("alloca(%u) failed.\n", (unsigned) size);
else
printf("alloca(%u) succeeded!\n", size);
return 0;
}
#endif

 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      03-05-2008
>> >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
>



 
Reply With Quote
 
Dik T. Winter
Guest
Posts: n/a
 
      03-05-2008
In article <1204580335.833631@news1nwk> Eric Sosman <(E-Mail Removed)> writes:
> jacob navia wrote:

....
> > What makes this function interesting is that
> > o It is very efficient. Since it allocates from the stack,
> > a few assembler instructions are needed, much quicker
> > than most "malloc" implementations.

>
> That's odd: The Rationale says "Such a function is not
> efficiently implementable in a variety of environments, so
> it was not adopted in the Standard." What do you know that
> the couple hundred contributors to the Standard didn't?


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).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Portable alloca() replacement? Freejack C Programming 9 01-19-2005 08:18 AM
Question about alloca() and alternative to using stack in an implementation Sushil C Programming 20 07-20-2004 01:38 PM
Why didn't ANSI/ISO make alloca() standard? Nitin Bhardwaj C Programming 6 07-17-2004 05:53 PM
gcc and alloca jacob navia C Programming 32 07-16-2004 06:59 PM



Advertisments