alloca

[user923005]

Today the above "rationale" is obviously incorrect. I'm not saying that
people who came up with this rationale were wrong. It is quite possible
that they were right at the time when they came up with it. However,
today the Variable Length Arrays (VLAs) are part of the C99 standard.
And the complexities of implementing VLAs are exactly the same (or even
more severe) than the difficulties that arise in implementation of
'alloca' function. Yet VLAs have made it into the standard.

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.

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.

 

[Richard Heathfield]

Richard Tobin said:

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. Nevertheless, you are expressing a minority view.

 

[Richard Bos]

This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

Have you not read the FAQ, or are you just too full of yourself to
understand it? <http://c-faq.com/malloc/alloca.html>.

Richard

 

[Keith Thompson]

... the function may receive a stack that looks like

[ FILE* ]
[ size_t ]
[ b ]
[ u ]
[ f ]
[ f ]
[ e ]
[ r ]
[ char* ]

... with unwelcome consequences. In order to avoid this,
the compiler needs to special-case the handling of function
arguments involving alloca(), rewriting to something like

char *_temp = alloca(SIZE);
ptr = fgets(_temp, SIZE, stdin);
...

This is, of course, a fake argument. A compiler that provides the
alloca' as a library extension has to make sure that the argument
passing mechanism works correctly. How it does that it its own
headache.

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.

And in fact that's what at least some compilers actually do. On one
system (Solaris), the man page for alloca says:

The alloca() function is machine-, compiler-, and most of all,
system-dependent. Its use is strongly discouraged.

On another (Ubuntu), it says:

The alloca() function is machine and compiler dependent. On many
sys- tems its implementation is buggy. Its use is discouraged.

On many systems alloca() cannot be used inside the list of
arguments of a function call, because the stack space reserved by
alloca() would appear on the stack in the middle of the space for
the function arguments.

And, unlike malloc, it doesn't return a null pointer to indicate
failure; if there's not enough space for the allocation, the behavior
is undefined.

 

[Richard Tobin]

Exactly: consider alloca() in a loop. As I said before, 'alloca' does
not care about C scoping/lifetime rules, while VLAs must strictly
observe there rules, which make VLAs _more_ complex to implement.

I haven't tried to implement it myself, so you may be right, but I'm
surprised. I would have though having it obey the same scoping
rules as other variables would make implementation simpler.

For example, with VLAs the compiler can know that the stack pointer is
unchanged at each iteration of a loop; with alloca() it can't. But
perhaps this makes no difference.

-- Richard

 

[Nick Keighley]

Gordon Burditt wrote:


You are trying to present invented trivial problems as something critical.
trivial?!


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?

as
something completely independent from the core language implementation. People
seem to believe somehow that the compiler might not have any idea about the
difficulties 'alloca' might present. I understand that this is probably rooted
in that archaic view of C language and its libraries specific to the early age
of UNIX-like systems. This is actually a bigger distortion of the concept of
standard C than the original poster's suggestion of using 'alloca'.

I know the standard specifies the library so the language/library
should, in an ideal world, be reagrded as indivisible. But in the
real world they *are* implemented seperatly. gcc do not always
run with a library that is supplied by gnu. Dinkum ship a library
not a compiler. So, in your world, a compiler writer has to generate
code that allows for the horrors of alloca() even if he has no
intention of implementing it! His code generation strategy is
constrained by a function that has no standardised behaviour.

This isn't just the early days of Unix this is now.

 

[Richard Tobin]

I know the standard specifies the library so the language/library
should, in an ideal world, be reagrded as indivisible. But in the
real world they *are* implemented seperatly. gcc do not always
run with a library that is supplied by gnu

However, gcc *does* implement alloca() internally. It doesn't
make do with whatever the library provides.

-- Richard

 

[santosh]

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

Presumably he means the "full" standard library that must be present in
hosted implementations, perhaps with support for optional parts like
IEC 60559 arithmetic etc.

<snip>

 

[santosh]

However, gcc *does* implement alloca() internally. It doesn't
make do with whatever the library provides.

I don't think alloca can be implemented as a library function. At the
very least, it must require some help from the compiler.

 

[Richard Tobin]

However, gcc *does* implement alloca() internally. It doesn't
make do with whatever the library provides.

[/QUOTE]

I don't think alloca can be implemented as a library function. At the
very least, it must require some help from the compiler.

In old systems it was just a function that fiddled the stack pointer.
That explains most of the warnings that are hedged around it in the
manual pages quoted.

-- Richard

 

[Antoninus Twink]

Richard Tobin said:


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.

 

[Richard]

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.

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.

 

[Kenny McCormack]

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.

 

[SM Ryan]

# 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.

 

[Noob]

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).

 

[Andrey Tarasevich]

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.

 

[Andrey Tarasevich]

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.

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

Standard library + implementation specific library extensions.

 

[Eric Sosman]

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?

 

[ymuntyan]

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?


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(8);
...
}

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

 

[Keith Thompson]

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).