Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)

Reply
Thread Tools

Re: OT: Seed7 on OS X - WAS: Re: Seeking computer-programming job (Sunnyvale, CA)

 
 
Nate Eldredge
Guest
Posts: n/a
 
      06-14-2009
Richard Heathfield <(E-Mail Removed)> writes:

> Beej Jorgensen said:


>> it can, occasionally, simplify memory management to know your VLA
>> will deallocate when it falls out of scope. There are a lot of
>> weird scoping rules with VLAs (esp involving goto), but they all
>> seem to make some kind of sense.

>
> What doesn't make sense, however, is that there is no failure mode.
> If you don't have the RAM, the behaviour appears to be undefined
> (which I surmise on the basis that I can't find anything in the
> spec to say otherwise). This is /such/ a bad idea.


I agree it's unfortunate, but also probably unavoidable. And this
situation is not unique to VLAs, either. What happens to a C program
that recursively calls a function too many times, or even with a single
fixed-size auto array that happens to be too large?

> With *alloc (and
> at least one variant of alloca but probably most/all of them), if
> the allocation can't be done, you get a null response, for which
> you can test.


All the alloca implementations I've encountered don't return NULL on
failure, but instead return a pointer to a block which may extend beyond
the end of the stack, and causes the program to crash (usually segfault,
sometimes misbehave in some other way) if accessed. This is the case on
FreeBSD, Linux, and Solaris 8 at least. On these, alloca just subtracts
the appropriate value from the stack pointer, so it is very efficient
(which is one of the major advantage of alloca). Determining whether
the allocation "succeeded" would require determining the address of the
bottom of the stack, which on these systems would require a system call
at the least, and cause alloca to become quite slow.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      06-15-2009
Richard Heathfield <(E-Mail Removed)> writes:
> Nate Eldredge said:

[...]
>> All the alloca implementations I've encountered don't return NULL
>> on failure, but instead return a pointer to a block which may
>> extend beyond the end of the stack, and causes the program to
>> crash (usually segfault, sometimes misbehave in some other way)
>> if accessed. This is the case on
>> FreeBSD, Linux, and Solaris 8 at least.

>
> Well, I did check the manpage ("The alloca function returns a
> pointer to the beginning of the allocated space. If the allocation
> failed, a NULL pointer is returned.") before posting. Perhaps it's
> lying.
>
> <snip>


Presumably it's correct for your system, but in general:

Ubuntu, Red Hat (both using glibc):

The alloca() function returns a pointer to the beginning of the
allo- cated space. If the allocation causes stack overflow,
program behavior is undefined.

Solaris:

The alloca() function allocates size bytes of space in the stack
frame of the caller, and returns a pointer to the allocated
block. This temporary space is automatically freed when the caller
returns. If the allocated block is beyond the current stack limit,
the resulting behavior is unde- fined.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      06-15-2009
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:
>Richard Heathfield <(E-Mail Removed)> writes:
>> Nate Eldredge said:

>[...]
>>> All the alloca implementations I've encountered don't return NULL
>>> on failure, but instead return a pointer to a block which may
>>> extend beyond the end of the stack, and causes the program to
>>> crash (usually segfault, sometimes misbehave in some other way)
>>> if accessed. This is the case on
>>> FreeBSD, Linux, and Solaris 8 at least.


Given that the function in question is "non-standard", I don't see a)
why we are dicussing it here or b) How anything can be said about it
conclusively (with the sort of generality that we usually require here
in CLC).

More to the point, all that is needed to prove something - that is, to
be able to say "at least one implementation does X" or "All the
implementations that I've familiar with do X" is to write one yourself
that does X.

I've often done exactly that, in order to score points here on CLC.

 
Reply With Quote
 
gwowen
Guest
Posts: n/a
 
      06-15-2009
On Jun 15, 6:41*am, (E-Mail Removed) (Kenny McCormack)
wrote:
> Given that the function in question is "non-standard", I don't see a)
> why we are dicussing it here or b) How anything can be said about it
> conclusively (with the sort of generality that we usually require here
> in CLC).


Cut it out, Han.
 
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
Good news to all those who are seeking for job in dotnet(Only those who are leaving in Hyderabad -India) BinnuChowdary ASP .Net 1 05-02-2006 06:42 AM
Good news to all those who are seeking for job in dotnet(Only those who are leaving in Hyderabad -India) BinnuChowdary ASP .Net 0 05-02-2006 04:13 AM
Good news to all those who are seeking for job in dotnet(Only those who are leaving in Hyderabad -India) BinnuChowdary ASP .Net 1 05-01-2006 01:03 PM
[Job - Part Time - Local] Seeking Python Coder in South Alabama area. John F. Python 0 03-04-2005 06:37 PM
Senior Developer looking for your asst in employmt issue (not job seeking!) Xavier Jefferson ASP .Net 14 05-12-2004 02:49 AM



Advertisments