«

Walter Roberson wrote:
> --
> So you found your solution
> What will be your last contribution?
> -- Supertramp (Fool's Overture)

Out of Walter sayings?

-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

jacob navia <> wrote:
>
> This function is not mentioned very often in this newsgroup but it
> is a VERY useful function, implemented in most compilers.
>
> I think it is useful to point to it since many people that read this
> newsgroup are newcomers, and they could benefit by using it.

It is a horrible hack that should generally be avoided, particularly by
novices. Many implementations are buggy and nearly all implementations
have restrictions on the contexts in which it can be used that are
documented poorly, if at all. It was left out of the C standard quite
intentionally. The variable length array feature of C99 was intended to
be a well-defined and well-behaved replacement for it.

-Larry Jones

No one can prove I did that!! -- Calvin

On Mar 3, 1:36*pm, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
> In article <47CC6A8C.128AC...@spamcop.net>,
> Kenneth Brody *<kenbr...@spamcop.net> wrote:
>
> >Well, I find open(), select(), and socket() quite useful as well, and
> >they're available on every platform I use, but that doesn't make them
> >relevent to clc.
>
> I disagree. *I think alloca() is far more on-topic than those other
> functions. *They have a standard that specifies them, and newsgroups
> related to that standard. *alloca() on the other is just something
> that's existed in most versions of C. *If comp.lang.c is not the
> newsgroup for it, what is?

I think if alloca() could be made to behave exactly like malloc(),
which is to say it should return a pointer to the memory if it
succeeds and a null pointer if it fails, then it would be quite a
useful addition. If this is not possible, then I think it has very
limited usefulness {who wants a standard function that behaves
differently every time you try to use it on a different platform or
with a different compiler?}. I suppose that the discussion would be
more sensible on news:comp.std.c than news:comp.lang.c since we are
proposing adding something to the language, based on popular usage.
Follow-up set to news:comp.std.c

IMO-YMMV.

In article <>,
Michael Mair <> wrote:
>Walter Roberson wrote:
>> --
>> So you found your solution
>> What will be your last contribution?
>> -- Supertramp (Fool's Overture)

>Out of Walter sayings?

That's been in my random signatures file since at least Oct 27, 2002.

The random Walter sayings are only a few weeks ago. I thought I'd put
in plenty of those, but it seems I'm posting more frequently than I
thought. I may have to dig out some more.
--
"Any sufficiently advanced bug is indistinguishable from a feature."
-- Rich Kulawiec

On Mar 3, 3:50 pm, jacob navia <ja...@nospam.com> wrote:
> This function is not mentioned very often in this newsgroup but it
> is a VERY useful function, implemented in most compilers.
>
> I think it is useful to point to it since many people that read this
> newsgroup are newcomers, and they could benefit by using it.
>
> This function is an allocation function, i.e. it is similar in
> functionality to the malloc() function, but it has the advantage of
> allocating from the stack instead of allocating from the heap.
>
> This means that the storage obtained can only be used within the scope
> where this function was called, and can't be returned as the result of a
> function call.
>
> The syntax is:
>
> void *alloca(size_t);
>
> It is not a function mentioned in the C standard, but it is
> present under unix, windows and Mac, (all compilers) and
> in most C implementations actually.
>
> 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.
> o The storage is freed automatically when the function where
> it is called exits. No need to call free().
>
> Caveats:
>
> o As I said above, the storage can't be returned from the current
> function.
> o There is the risk of stack overflow if you allocate too much memory
> with it. If it fails it returns NULL, but do not count on it.
>
> 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.
>
> --
> jacob navia
> jacob at jacob point remcomp point fr
> logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32

I'm amazed that you post this drivel. I guess you just like
attention, and don't mind publicly attaching your name to really bad
advice. Regardless of one's opinions on topicality or lack thereof of
alloca, encouraging beginners (or experienced developers for that
matter) to make a habit of using alloca is a foolish. The advantages
you give are trivial ones compared to the risks -- efficiency can be
achieved by other means such as custom memory allocation strategies,
and calling free isn't really that hard. And the disadvantages are
impossible to guard against. I'll let the man page on my system have
the last word (perhaps you'd say it was written by one of the
"clique").

*****************
The inlined code often consists of a single instruction
adjusting the stack pointer, and does not check for stack overflow.
Thus, there is no NULL error return.

BUGS
The alloca function is machine and compiler dependent. On many
systems 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.
**********************

-David

>>>>> "WR" == Walter Roberson <> writes:

WR> It is not possible to write a general alloca() that exists
WR> outside of the intimate details of the ABI in use. It
WR> therefore must not be thought of as belonging to C: it belongs
WR> to the system extensions that C compiler provides for that
WR> operating environment.

While I concur that alloca() ought to be discussed in
compiler-specific newsgroups, I think your reasoning is suspect. It
is likewise impossible to write a general malloc() that exists outside
of the intimate details of the ABI in use, and yet that belongs to C,
and is frequently discussed here.

alloca() is about as standard as gotoxy() or getch(); different
compilers and libraries implement it differently or not at all, and so
it doesn't belong in comp.lang.c, but in the newsgroup or other forum
for the compiler in question.

Charlton


--
Charlton Wilbur

Kenneth Brody wrote:
> jacob navia wrote:
>> This function is not mentioned very often in this newsgroup but it
>> is a VERY useful function, implemented in most compilers.
>
> [Referring to "alloca" in the subject, but not the body.]
>
>> I think it is useful to point to it since many people that read this
>> newsgroup are newcomers, and they could benefit by using it.
> [...]
>> 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.
>
> Well, I find open(), select(), and socket() quite useful as well, and
> they're available on every platform I use, but that doesn't make them
> relevent to clc.
>
> And, to your mention as to how wide-spread it's availablility is, here
> is what happens on my Windows system, with MSVC:
>
> ==========
> C:\temp>type usenet.c
> #include <stdio.h>
> #include <stdlib.h>
>
> int main()
> {
> char *foo = alloca(100);
> }
>
> C:\temp>cl usenet.c
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
> Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
>
> usenet.c
> usenet.c(6) : warning C4047: 'initializing' : 'char *' differs in levels of indi
> rection from 'int '
> Microsoft (R) Incremental Linker Version 6.00.8447
> Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
>
> /out:usenet.exe
> usenet.obj
> usenet.obj : error LNK2001: unresolved external symbol _alloca
> usenet.exe : fatal error LNK1120: 1 unresolved externals
>
> C:\temp>
> ==========
>

Hi Kenneth
1) Microsoft calls this function _alloca and NOT alloca.
It is declared in malloc.h (or in my 64 bit version)
in intrin.h

2) This is since at least 10 years.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

In article <fqhtrv$t65$>, jacob navia <> wrote:
>1) Microsoft calls this function _alloca and NOT alloca.

Mmmm, but still

>>> The syntax is:

>>> void *alloca(size_t);

??

That is, even though microsoft calls the function _alloca
the microsoft user would still call alloca (no underscore)?
If that is not the case, if the user has to call (e.g.,) _alloca
then your "The syntax is" is not accurate. But that would
appear to contradict your assertions of how widespread and
portable it is.

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...
--
"Let me live in my house by the side of the road --
It's here the race of men go by.
They are good, they are bad, they are weak, they are strong
Wise, foolish -- so am I;" -- Sam Walter Foss

"Eric Sosman" <> wrote in message
news:1204580335.833631@news1nwk...
> jacob navia wrote:
>> This function [alloca] is not mentioned very often in this newsgroup but
>> it
>> is a VERY useful function, implemented in most compilers.
>>
>> I think it is useful to point to it since many people that read this
>> newsgroup are newcomers, and they could benefit by using it.

>> o As I said above, the storage can't be returned from the current
>> function.
>> o There is the risk of stack overflow if you allocate too much memory
>> with it. If it fails it returns NULL, but do not count on it.
>
> You forgot
>
> o Even on systems where alloca() is available, it may fail
> catastrophically in some contexts, for example
>
> ptr = fgets(alloca(SIZE), SIZE, stdin);

Why should that failure be any more likely than:

void fn()
{char buffer[SIZE];
....
ptr = fgets(buffer, SIZE, stdin);

If the implementation uses a stack for alloca() and for local variables,
then it seems stack overflow is equally likely.

(In fact alloca() may make overflow less likely, in a chain of function
calls, by not unconditionally allocating frame data, only as needed, and of
the size needed.)

--
Bart

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

It is not mentioned because it does not exist in standard C, and
programs calling it are no longer portable. It is not even
implementable in a portable manner. If I am right about this, you
can't even give topical code for it on this newsgroup.

--
[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