Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > alloca

Reply
Thread Tools

alloca

 
 
Antoninus Twink
Guest
Posts: n/a
 
      03-04-2008
On 4 Mar 2008 at 7:30, Richard Heathfield wrote:
> Richard Tobin said:
>
>> In article <(E-Mail Removed)>,
>> Malcolm McLean <(E-Mail Removed)> wrote:
>>
>>>Oddly enough alloca is on topic in comp.std.c, because that's the place
>>>to discuss proposed changes to the C standard.

>>
>> Just because something isn't in the C standard doesn't mean that its
>> only interest to C programmers is as a proposed addition. alloca() is
>> used in existing C implementations, in code not intended for a single
>> system. Discussions of such subjects as how portable it is, and when
>> it's a good idea to use it, belong here.

>
> I sense a disturbance in the Force - and not an unwelcome one, from my
> perspective.


Yeah, right - here we go with St Richard the Moderate again.

> Nevertheless, you are expressing a minority view.


So you say. He might be expressing the view of a silent and deeply
frustrated majority.

It's interesting how the movement is all in one direction - people
eventually tire of the idiocy of The Clique and either get ostracized as
trolls (Richard R, Chris Hills, now it seems Richard T is going down
that path), or else just completely abandon clc - presumably finding the
futility of it all too much.

 
Reply With Quote
 
 
 
 
Richard
Guest
Posts: n/a
 
      03-04-2008
Antoninus Twink <(E-Mail Removed)> writes:

> On 4 Mar 2008 at 7:30, Richard Heathfield wrote:
>> Richard Tobin said:
>>
>>> In article <(E-Mail Removed)>,
>>> Malcolm McLean <(E-Mail Removed)> wrote:
>>>
>>>>Oddly enough alloca is on topic in comp.std.c, because that's the place
>>>>to discuss proposed changes to the C standard.
>>>
>>> Just because something isn't in the C standard doesn't mean that its
>>> only interest to C programmers is as a proposed addition. alloca() is
>>> used in existing C implementations, in code not intended for a single
>>> system. Discussions of such subjects as how portable it is, and when
>>> it's a good idea to use it, belong here.

>>
>> I sense a disturbance in the Force - and not an unwelcome one, from my
>> perspective.

>
> Yeah, right - here we go with St Richard the Moderate again.


LOL. Yeah. Always throwing this "moderate thing" in before locking down
the hatches again when no one is looking.

>
>> Nevertheless, you are expressing a minority view.

>
> So you say. He might be expressing the view of a silent and deeply
> frustrated majority.


Yup.

>
> It's interesting how the movement is all in one direction - people
> eventually tire of the idiocy of The Clique and either get ostracized as
> trolls (Richard R, Chris Hills, now it seems Richard T is going down
> that path), or else just completely abandon clc - presumably finding the
> futility of it all too much.


Just pick a sample of posts from "Chuck" for a start. And yet he is
accepted. He even boasts that he "hasn't taken a holiday"! The mind
boggles as to the self importance and inflexibility of some of this
folk. They KNOW that people think in terms of a stack when using C. But
oh no! Any post (not from the Clique) that mentions it is immediately
binned with a sharp telling off.

And then we have the FAQ defence. The same bozos reply to the same stuff
day in day out UNLESS someone ruffles their feathers and then we have
"Have you not lurked for 3 months? Did you not read the FAQ?".

"Indeed". This group has gone to the dogs.
 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      03-04-2008
In article <fqjg2k$4no$(E-Mail Removed)>,
Richard <(E-Mail Removed)> wrote:
....
>Just pick a sample of posts from "Chuck" for a start. And yet he is
>accepted. He even boasts that he "hasn't taken a holiday"! The mind
>boggles as to the self importance and inflexibility of some of this
>folk. They KNOW that people think in terms of a stack when using C. But
>oh no! Any post (not from the Clique) that mentions it is immediately
>binned with a sharp telling off.
>
>And then we have the FAQ defence. The same bozos reply to the same stuff
>day in day out UNLESS someone ruffles their feathers and then we have
>"Have you not lurked for 3 months? Did you not read the FAQ?".
>
>"Indeed". This group has gone to the dogs.


Yes, but we keep coming back to it. Good to know it still has
entertainment value.

But, putting on my "Therapist" hat, I still gotta wonder (as I have been
wondering for years now), why the regs (particularly Androids like KT)
bother with this NG. What psychic needs of theirs are being met?

The topic is interesting, though a little disgusting to contemplate.

 
Reply With Quote
 
SM Ryan
Guest
Posts: n/a
 
      03-04-2008
jacob navia <(E-Mail Removed)> wrote:

# void *alloca(size_t);

The latest version of C includes auto dynamically sized arrays
(a brand new idea first introduced in 48 years ago in Algol)
which for nearly all programs is the same functionality.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
GERBILS
GERBILS
GERBILS
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      03-04-2008
Walter Roberson wrote:

> Sorry but my head is starting to hurt, trying to come up with
> ways that you could -somehow- be correct -and- not have
> contradicted yourself...


That's because he's a troll. (A rather good one, one must concede).
 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      03-04-2008
Keith Thompson wrote:
>> ....
>> For example, a compiler can decide to _always_ perform the calls to
>> argument-forming functions before starting to form the next stack
>> frame. (no need to single out the 'alloca').

>
> No, a compiler that provides alloca() *doesn't* have to make sure that
> the argument passing mechanism works correctly. Since no standard
> defines the behavior of alloca(), a compiler is free to leave its
> behavior undefined in any circumstances where making it work would be
> inconvenient.
> ...


That's just another way to circumvent the potential problem with using 'alloca'
in an argument list. Just say that behavior is undefined in this case. A quality
implementation might perform a run-time stack integrity check in debug
configuration and trigger a run-time diagnostic.

Although I don't direct connection to the 'alloca' being standard or not. There
are perfectly _standard_ features that produce undefined behavior in
circumstances "where making it work would be inconvenient". Like, for example,
the range of 'ptrdiff_t' is not required to be sufficient for any [otherwise
legal] pointer subtraction operation, and trying to subtract pointers which are
too far apart produces UB.

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      03-04-2008
Nick Keighley wrote:
>> You are trying to present invented trivial problems as something critical.

>
> trivial?!


Yes, trivial, in a sense that there's no actual requirement for a solution you
seem to imply. The implementation can simply _ignore_ the problem by stating
that using the function in certian contexts is not allowed, i.e. it's UB.

>
>> It is
>> the implementation that is supposed to care about the correctness of the code in
>> this case. How it does that is entirely not my business. It might evaluate all
>> arguments before starting to form the argument list. It might use some kind of
>> "compiler magic".
>>
>> BTW, I read the messages here and some of them seem to demonstrate that weird
>> and distorted perception of the standard library (maybe in its extended form)

>
> what on earth is the "extended form" of the standard library?


Standard library + implementation specific library extensions.

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      03-04-2008
Andrey Tarasevich wrote:
> Eric Sosman wrote:
>> ...
>> 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?
>> ...

>
> Today the above "rationale" is obviously incorrect.


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?

> Actually the real reason why we don't need to care about 'alloca'
> anymore is the simple fact that its benefits are already provided by a
> more C-like feature - VLAs.


Exactly: C has a portable and safer (though still not
entirely safe) feature that offers all the advertised benefits
of alloca(). Why reject it in favor of something that is
less portable and more dangerous?

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
ymuntyan@gmail.com
Guest
Posts: n/a
 
      03-04-2008
On Mar 4, 9:59 am, Eric Sosman <(E-Mail Removed)> wrote:
> Andrey Tarasevich wrote:
> > Eric Sosman wrote:
> >> ...
> >> 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?
> >> ...

>
> > Today the above "rationale" is obviously incorrect.

>
> 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?
>
> > Actually the real reason why we don't need to care about 'alloca'
> > anymore is the simple fact that its benefits are already provided by a
> > more C-like feature - VLAs.

>
> Exactly: C has a portable and safer (though still not
> entirely safe) feature that offers all the advertised benefits
> of alloca().


void func (void)
{
char *foo = NULL;
if (something())
foo = alloca(;
...
}

VLA's won't do that because of the object lifetime rules.

> Why reject it in favor of something that is
> less portable and more dangerous?


Why reject? VLA is one thing, alloca() is another thing.
And in some sense alloca() is more portable, e.g. you
can use it with C compilers produced by one big company
which ignores C99. You know, "C99" and "portable" are
not exactly the same

Yevgen
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-04-2008
"Malcolm McLean" <(E-Mail Removed)> writes:
> "jacob navia" <(E-Mail Removed)> wrote in message
> news:fqhoa9$a68$(E-Mail Removed)...
>> 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, and I think that new users should be aware of its existence,
>> and the possible advantages and problems with its usage.
>>

> Oddly enough alloca is on topic in comp.std.c, because that's the
> place to discuss proposed changes to the C standard.
> However topicality should not be so tightly drawn that functions like
> alloca() cannot be mentioned here at all. However it should be
> discussed as it arises naturally in response to topical thread, not as
> a subject in its own right.


A discussion of whether to add alloca() to the C standard would
certainly be topical in comp.std.c. But I don't think anyone in this
thread has actually advocated adding it to the standard. In
particular, jacob's post that started this thread merely talked about
it as a non-standard function (and mostly ignored the problems that
make it non-portable in the real world).

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
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