Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
They compile their code using the -ansi option, and
(off course) the aptly named "pedantic" option.
I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort of making
a BUILT-IN (__builtin) function if they did not want
people to use it.
The gcc compiler in its *default* setting supports alloca
even better than lcc-win32 since they made it a builtin.
And this since ages!
P.S.
Under windows, you have to make a small assembler loop
to touch the allocated pages as you walk down the stack.
This would lead to a slight code bloat and I prefered
the function call method.
32  9311 
"jacob navia" <ja***@jacob.remcomp.fr> writes: Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
They compile their code using the -ansi option, and
(off course) the aptly named "pedantic" option.
alloca() is not in the Standard. Therefore it is off-topic.
--
"When in doubt, treat ``feature'' as a pejorative.
(Think of a hundred-bladed Swiss army knife.)"
--Kernighan and Plauger, _Software Tools_
jacob navia wrote: Some people here have started saying that
"alloca" is off topic, and they used the argument that
the gcc compiler doesn't recognize it.
They compile their code using the -ansi option
and (of course) the aptly named "pedantic" option.
I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort
of making a BUILT-IN (__builtin) function
if they did not want people to use it.
The gcc compiler in its *default* setting supports alloca
even better than lcc-win32 since they made it a builtin.
And this since ages!
P.S.
Under windows, you have to make a small assembler loop
to touch the allocated pages as you walk down the stack.
This would lead to a slight code bloat and I prefered
the function call method.
Don't use alloca. It is obsolete.
Use "variable length arrays" and the -std=c99 option.
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
[...] Don't use alloca. It is obsolete.
Use "variable length arrays" and the -std=c99 option.
ERT is correct. (For reasons I won't go into, this is worth pointing
out.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
>Some people here have started saying that "alloca" is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
They compile their code using the -ansi option, and
(off course) the aptly named "pedantic" option.
I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort of making
a BUILT-IN (__builtin) function if they did not want
people to use it.
I believe that alloca() is impossible to implement correctly without
making it a built-in and very difficult to either make work
unrestricted or describe the limits of where you can use it and
where you cannot even if it is a builtin. Early (e.g. a decade or
two ago) versions of GCC that had it as a builtin got it wrong.
Current versions may or may not handle it properly.
A particular problem is that if alloca() is used as a function
argument, arranging NOT to have the space end up somewhere in
the middle of the arguments of the called function.
Look at the generated code for this:
foo(
alloca(10),
alloca(20),
alloca(30),
alloca(40),
alloca(50),
alloca(60),
alloca(70),
alloca(80),
alloca(90),
alloca(100),
alloca(110),
alloca(120),
alloca(130),
alloca(140),
alloca(150),
alloca(160),
alloca(170),
alloca(180),
alloca(190)
);
and see if the arguments passed are 19 pointers and no part of an
uninitialized memory area. If it calls alloca(), pushes the result,
and repeats 19 times, it's going to get it wrong.
Gordon L. Burditt
"jacob navia" <ja***@jacob.remcomp.fr> wrote: Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
Bullshit, and you know it, navia. alloca() is off-topic here because the
Standard doesn't recognise it. gcc is as immaterial as your own little
toy.
Richard
The code generated by gcc under linux seems to me 100%
correct. For the example you give, it will always save
the result of alloca and do all the pushes later on, pushing
the saved values.
If your only argument is that this builtin may have had a bug
around 10 years ago... well, I do not know what to say of such
an argumentation other than:
"There is no blinder man than the one that doesn't want to see"
jacob navia wrote: I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort of making
a BUILT-IN (__builtin) function if they did not want
people to use it.
"The alloca function is machine and compiler dependent. On many systems
its implementation is buggy. Its use is disÂ*couraged."
(from the alloca() man page on my SuSE sytem)
Doesn't sound all that encouraging, does it?
Christian
In <cd********@library2.airnews.net> go***********@burditt.org (Gordon Burditt) writes: A particular problem is that if alloca() is used as a function
argument, arranging NOT to have the space end up somewhere in
the middle of the arguments of the called function.
Look at the generated code for this:
foo(
alloca(10),
alloca(20),
alloca(30),
alloca(40),
alloca(50),
alloca(60),
alloca(70),
alloca(80),
alloca(90),
alloca(100),
alloca(110),
alloca(120),
alloca(130),
alloca(140),
alloca(150),
alloca(160),
alloca(170),
alloca(180),
alloca(190)
);
and see if the arguments passed are 19 pointers and no part of an
uninitialized memory area. If it calls alloca(), pushes the result,
and repeats 19 times, it's going to get it wrong.
OTOH, how often have you felt the need to use alloca this way?
Although I'm far from being an alloca advocate, I find this example
highly artificial and irrelevant for the typical use of alloca. Even if
the sizes are not constant, as in your trivial example.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: "E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
[...] Don't use alloca. It is obsolete.
Use "variable length arrays" and the -std=c99 option.
ERT is correct. (For reasons I won't go into, this is worth pointing
out.)
OTOH, alloca is *far* more portable than VLAs... Fortunately, it can
be replaced by malloc and friends in most cases (the only excuse for using
alloca is when malloc and friends render the code too slow for its
intended purpose on its intended platform).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <cd**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote: (the only excuse for using
alloca is when malloc and friends render the code too slow for its
intended purpose on its intended platform).
Or too complicated: stack-allocated space has the advantage of being
automatically freed when the function returns, even if it "returns"
as the result of a longjmp.
-- Richard
On 14 Jul 2004 05:06:55 GMT,
Gordon Burditt <go***********@burditt.org> wrote:
I believe that alloca() is impossible to implement correctly without
making it a built-in and very difficult to either make work
unrestricted or describe the limits of where you can use it and
where you cannot even if it is a builtin. Early (e.g. a decade or
two ago) versions of GCC that had it as a builtin got it wrong.
Current versions may or may not handle it properly.
The gcc compiler itself uses or used to use alloca so it would be
hard to compile the gcc compiler without a working alloca. For the
bootstrap process there is a pseudo-alloca function including with
the gcc source so you can use alloca even when the native compiler
doesn't support it. I noticed this about a decade ago, so this may
no longer be true.
The various System V release 2 or 3 also had an alloca function hidden
somewhere in an obscure library. It was neither documented, nor working
properly on all platforms.
Villy
On Wed, 14 Jul 2004 01:51:21 +0200, "jacob navia"
<ja***@jacob.remcomp.fr> wrote: Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
No, they used the argument that "alloca" is not part of standard C.
Give it up, Jacob. Even most of our newbies eventually realize that
they are not going to change the declared topicality of this
newsgroup. You've been here long enough that it's getting really
annoying. You have a newsgroup of your own. Take this stuff over
there.
--
Al Balmer
Balmer Consulting re************************@att.net
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:<cd**********@news-reader3.wanadoo.fr>... The code generated by gcc under linux seems to me 100%
correct. For the example you give, it will always save
the result of alloca and do all the pushes later on, pushing
the saved values.
If your only argument is that this builtin may have had a bug
around 10 years ago... well, I do not know what to say of such
an argumentation other than:
"There is no blinder man than the one that doesn't want to see"
There are still outstanding problems with alloca in gcc, in particular
how its implementation interacts with variable length arrays.
I use it anyway.
In <cd**********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk (Richard Tobin) writes: In article <cd**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote:(the only excuse for using
alloca is when malloc and friends render the code too slow for its
intended purpose on its intended platform).
Or too complicated: stack-allocated space has the advantage of being
automatically freed when the function returns, even if it "returns"
as the result of a longjmp.
There is nothing preventing you from doing the cleanup *before* calling
longjmp. And if the code is carefully designed, the cleanup is always
trivial (just take care that each involved pointer is either null or
allocated and call free() on all of them).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <cd**********@news-reader5.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote: Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
They compile their code using the -ansi option, and
(off course) the aptly named "pedantic" option.
This looks to me a whole lot like:
"When you ask gcc to act like a C compiler, it doesn't recognize alloca.
Therefore, alloca should be considered topical in a newsgroup that
discusses C."
I think one of us has serious comprehension problems today. I'll refrain
from sharing my opinion about which one.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Of course, you're more likely to get bizarre answers, helpful compiler
diagnostics, or, in the worst of all worlds, the answer you expected.
--Chris Dollin in comp.lang.c
In article <cd**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote: In <cd**********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk
(Richard Tobin) writes: Or too complicated: stack-allocated space has the advantage of being
automatically freed when the function returns, even if it "returns"
as the result of a longjmp.
There is nothing preventing you from doing the cleanup *before* calling
longjmp.
That only works if you're calling longjmp directly from that function,
and not from something that it calls.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Of course, you're more likely to get bizarre answers, helpful compiler
diagnostics, or, in the worst of all worlds, the answer you expected.
--Chris Dollin in comp.lang.c
Alan Balmer <al******@att.net> writes: On Wed, 14 Jul 2004 01:51:21 +0200, "jacob navia"
<ja***@jacob.remcomp.fr> wrote:Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
No, they used the argument that "alloca" is not part of standard C.
Give it up, Jacob. Even most of our newbies eventually realize that
they are not going to change the declared topicality of this
newsgroup. You've been here long enough that it's getting really
annoying. You have a newsgroup of your own. Take this stuff over
there.
Actually, he doesn't. comp.compilers.lcc is about the lcc compiler
<http://www.cs.princeton.edu/software/lcc/>, not just about lcc-win32
<http://www.cs.virginia.edu/~lcc-win32/>.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
On Wed, 14 Jul 2004 18:57:08 GMT, Keith Thompson <ks***@mib.org>
wrote: Alan Balmer <al******@att.net> writes: On Wed, 14 Jul 2004 01:51:21 +0200, "jacob navia"
<ja***@jacob.remcomp.fr> wrote: >Some people here have started saying that "alloca"
>is off topic, and they used the argument that the gcc
>compiler doesn't recognize it.
No, they used the argument that "alloca" is not part of standard C.
Give it up, Jacob. Even most of our newbies eventually realize that
they are not going to change the declared topicality of this
newsgroup. You've been here long enough that it's getting really
annoying. You have a newsgroup of your own. Take this stuff over
there.
Actually, he doesn't. comp.compilers.lcc is about the lcc compiler
<http://www.cs.princeton.edu/software/lcc/>, not just about lcc-win32
<http://www.cs.virginia.edu/~lcc-win32/>.
Well, yeah, he doesn't own it ;-) I haven't monitored it, but if he
mentions his version as often there as he does here, it's probably
mostly his <G>.
--
Al Balmer
Balmer Consulting re************************@att.net Da*****@cern.ch (Dan Pop) wrote:. OTOH, alloca is *far* more portable than VLAs... Fortunately, it can
be replaced by malloc and friends in most cases (the only excuse for using
alloca is when malloc and friends render the code too slow for its
intended purpose on its intended platform).
Or if there is no free store (ie. malloc always returns 0)
>>A particular problem is that if alloca() is used as a function argument, arranging NOT to have the space end up somewhere in
the middle of the arguments of the called function.
Look at the generated code for this:
foo(
alloca(10),
alloca(20),
alloca(30),
alloca(40),
alloca(50),
alloca(60),
alloca(70),
alloca(80),
alloca(90),
alloca(100),
alloca(110),
alloca(120),
alloca(130),
alloca(140),
alloca(150),
alloca(160),
alloca(170),
alloca(180),
alloca(190)
);
and see if the arguments passed are 19 pointers and no part of an
uninitialized memory area. If it calls alloca(), pushes the result,
and repeats 19 times, it's going to get it wrong.
OTOH, how often have you felt the need to use alloca this way?
No, but I have had occasion to try to use alloca() where it was passed as
ONE argument to a function, neither first nor last, and I ended up tearing
my hair out trying to figure out why it didn't work. The problem was
that the data got allocated in THE MIDDLE of the block of arguments.
A later version did the right thing as long as it didn't run out of registers,
which is why there are so many parameters in the example. However, trying to
guess how many registers were in use required anticipating how the compiler
would do things, and depended in many ways on optimization settings and
even a few things you wouldn't normally expect to be optimization (like
the writable-strings option).
This is by no means the most complicated situation that I would expect to break.
It gets even messier if the value passed to alloca() is not constant but requires
the use of alloca() to calculate it.
Although I'm far from being an alloca advocate, I find this example
highly artificial and irrelevant for the typical use of alloca. Even if
the sizes are not constant, as in your trivial example.
You're right, the example is artificial. It's supposed to be simple to
make it easy to check if the generated code is broken.
If I'm going to use alloca() I want to know whether it will work
or not. The above example is certainly not typical but there seems
to be no way of knowing when you cross the line, and further, nobody
seems to know or care. (I also expect unsigned arithmetic to work
in more than just the "typical" cases). I note that one poster notes
that it's still broken with VLAs. I could live with that if I could
be reasonably sure that the implementations are all that good. And
especially if this limitation was actually documented.
I think there are still compilers out there that claim to implement
alloca() without treating it as a compiler builtin, or at least
generating code specially when it's being used. I don't believe
that's possible without seriously slowing down the code by assuming
that ALL functions are alloca-like.
At one time I spent a lot of time trying to port alloca() to another
architecture where it appeared to work if you used it in the context:
<variable> = alloca( <integer expression not involving use of alloca()>);
in the outer block of a function, but otherwise I could manage
without trying very hard manage to break it, in both the architecture
I was porting it to and all the architectures where it was already
implemented. The answers I got were always that I was abusing it
in some way and I shouldn't do that. That's nice, how about
documenting where I CAN use it? Or maybe an actual error message
if it can't manage to do the right thing, rather than silence until
it bombs in strange ways at runtime? Oh, yes, the restrictions
varied a lot from architecture to architecture even in the same
compiler version. One of them even managed to break:
if ((ptr = alloca(sizeof(struct foo))) != NULL) {
char name[100];
...
}
and actually documented that! The fix was:
ptr = alloca(sizeof(struct foo));
if (ptr != NULL) {
char name[100];
...
}
Gordon L. Burditt
In article <cd**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote: Or too complicated: stack-allocated space has the advantage of being
automatically freed when the function returns, even if it "returns"
as the result of a longjmp.
There is nothing preventing you from doing the cleanup *before* calling
longjmp.
That's why I said "complicated" rather than "impossible".
And if the code is carefully designed, the cleanup is always
trivial (just take care that each involved pointer is either null or
allocated and call free() on all of them).
What if the longjmp() is from a function in a library you don't
control? (In that case it probably *is* impossible.) Even in the
more common case that the function calling longjmp() is your own, you
would probably need to keep a list of the relevant pointers.
-- Richard
Gordon Burditt wrote: Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
They compile their code using the -ansi option, and
(off course) the aptly named "pedantic" option.
I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort of making
a BUILT-IN (__builtin) function if they did not want
people to use it.
I believe that alloca() is impossible to implement correctly without
making it a built-in and very difficult to either make work
unrestricted or describe the limits of where you can use it and
where you cannot even if it is a builtin. Early (e.g. a decade or
two ago) versions of GCC that had it as a builtin got it wrong.
Current versions may or may not handle it properly.
Well, 'tain't entirely so. Go & ogle "BeOS alloca" for the mostly
portable alloca() implemented in standard C; it's the first link.
A particular problem is that if alloca() is used as a function
argument, arranging NOT to have the space end up somewhere in
the middle of the arguments of the called function.
Look at the generated code for this:
foo(
alloca(10),
alloca(20),
alloca(30),
alloca(40),
alloca(50),
alloca(60),
alloca(70),
alloca(80),
alloca(90),
alloca(100),
alloca(110),
alloca(120),
alloca(130),
alloca(140),
alloca(150),
alloca(160),
alloca(170),
alloca(180),
alloca(190)
);
and see if the arguments passed are 19 pointers and no part of an
uninitialized memory area. If it calls alloca(), pushes the result,
and repeats 19 times, it's going to get it wrong.
Gordon L. Burditt
Not sure what you mean by "pushes the result" and whatnot, but for me
gcc just increments the stack pointer a bunch of times, stores pointers
to the chunks of space it gets in registers, and then jumps off to
foo(). Looks right to me.
-Peter
--
Pull out a splinter to reply.
In <cd**********@rumours.uwaterloo.ca> dj******@csclub.uwaterloo.ca (Dave Vandervies) writes: In article <cd**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote:In <cd**********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk
(Richard Tobin) writes:
Or too complicated: stack-allocated space has the advantage of being
automatically freed when the function returns, even if it "returns"
as the result of a longjmp.
There is nothing preventing you from doing the cleanup *before* calling
longjmp.
That only works if you're calling longjmp directly from that function,
and not from something that it calls.
If there are intermediate functions that need cleanup, longjmp is not an
option in the first place. Think about functions having open streams, to
remain in the realm of standard C (but real life applications can also
allocate other kinds of resources that require proper deallocation).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <84**************************@posting.google.com > ol*****@inspire.net.nz (Old Wolf) writes: Da*****@cern.ch (Dan Pop) wrote:. OTOH, alloca is *far* more portable than VLAs... Fortunately, it can
be replaced by malloc and friends in most cases (the only excuse for using
alloca is when malloc and friends render the code too slow for its
intended purpose on its intended platform).
Or if there is no free store (ie. malloc always returns 0)
Expect an alloca() call to either fail or crash your program in this
scenario.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <cd**********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk (Richard Tobin) writes: In article <cd**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote:
And if the code is carefully designed, the cleanup is always
trivial (just take care that each involved pointer is either null or
allocated and call free() on all of them).
What if the longjmp() is from a function in a library you don't
control? (In that case it probably *is* impossible.)
In that case it is the library's implementor job to do the right thing,
whatever that is, including not using longjmp.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On Wed, 14 Jul 2004 01:51:21 +0200, in comp.lang.c , "jacob navia"
<ja***@jacob.remcomp.fr> wrote: Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
No, they didn't. You eithe misunderstand or distort the truth.
The argument was that when invoked in ISO compatible mode, gcc didn't
recognise alloca(), which was to be expected since its not ISO, and since
ISO is the topic here, ergo its offtopic.
I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort of making
a BUILT-IN (__builtin) function if they did not want
people to use it.
I'm confused. Why do you think that the existence of the function, and
presumably the intention of the developers that someone could use it, has
/anything/ at all to do with topicality here? My compiler for PalmOS has
various functions to manipilate the SD card builtin. MSVC has a stack of
windows kernel functions "builtin". Are they topical here?
The gcc compiler in its *default* setting supports alloca
even better than lcc-win32 since they made it a builtin.
Whoopy do.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
"Mark McIntyre" <ma**********@spamcop.net> a écrit dans le message de
news:3f********************************@4ax.com... On Wed, 14 Jul 2004 01:51:21 +0200, in comp.lang.c , "jacob navia"
<ja***@jacob.remcomp.fr> wrote:
Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
No, they didn't. You eithe misunderstand or distort the truth.
In another thread in this group ("Target audience" where you also
participated) Mr Dave Vandervies wrote:
<QUOTE>
In article <cd**********@news-reader5.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:
All linux compilers and windows compilers supply alloca.
Really? So is it gcc or uname that's lying to me here?
--------
dave@hct-cvs:~/clc (0) $ cat foo.c
/*There's a man page that claims alloca is declared in stdlib.h, so this
is a best-guess about how to get it.
*/
#include <stdlib.h>
int main(void)
{
alloca();
return 0;
}
dave@hct-cvs:~/clc (0) $ gcc -W -Wall -ansi -pedantic -O foo.c
foo.c: In function `main':
foo.c:8: warning: implicit declaration of function `alloca'
/tmp/ccn8UpcR.o: In function `main':
/tmp/ccn8UpcR.o(.text+0x4): undefined reference to `alloca'
collect2: ld returned 1 exit status
dave@hct-cvs:~/clc (1) $ gcc --version
egcs-2.91.66
dave@hct-cvs:~/clc (0) $ uname -a
Linux hct-cvs 2.2.16 #9 Thu Mar 13 16:55:23 EST 2003 i586 unknown
dave@hct-cvs:~/clc (0) $
--------
gcc claims it doesn't have a declaration for alloca, the linker claims
it can't find it in the library, and uname claims that I'm running Linux
(which you say necessarily supports it).
I'm inclined to think that it's you, and not the programs I'm running,
that's mistaken.
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
There is no possible way that CHAR_MIN can be 255, and certainly no way
that CHAR_MIN can exceed 255.
--Ben Pfaff in comp.lang.c
<end quote>
"jacob navia" <ja***@jacob.remcomp.fr> writes: "Mark McIntyre" <ma**********@spamcop.net> a écrit dans le message de
news:3f********************************@4ax.com... On Wed, 14 Jul 2004 01:51:21 +0200, in comp.lang.c , "jacob navia"
<ja***@jacob.remcomp.fr> wrote:
Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.
No, they didn't. You eithe misunderstand or distort the truth.
In another thread in this group ("Target audience" where you also
participated) Mr Dave Vandervies wrote:
<QUOTE>
In article <cd**********@news-reader5.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:
All linux compilers and windows compilers supply alloca.
Really? So is it gcc or uname that's lying to me here?
--------
dave@hct-cvs:~/clc (0) $ cat foo.c
/*There's a man page that claims alloca is declared in stdlib.h, so this
is a best-guess about how to get it.
*/
[snip]
Yeah, Dave made a mistake. alloca(), on all the systems I've checked,
is declared in <alloca.h>, not in <stdlib.h>.
In any case, Dave said (incorrectly) that gcc doesn't recognize
alloca(); he didn't claim that alloca() is off topic *because* gcc
doesn't recognize it, nor did anyone else.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Yeah, Dave made a mistake. alloca(), on all the systems I've checked,
is declared in <alloca.h>, not in <stdlib.h>.
Check the glibc <stdlib.h>:
#if defined __USE_GNU || defined __USE_BSD || defined __USE_MISC
# include <alloca.h>
#endif /* Use GNU, BSD, or misc. */
If gcc is invoked in its default mode, <stdlib.h> is as good as <alloca.h>
as far as alloca() is concerned.
If gcc is invoked in conforming mode, <stdlib.h> is not allowed to
declare alloca() and including <alloca.h> invokes undefined behaviour.
In any case, Dave said (incorrectly) that gcc doesn't recognize
alloca();
Dave is right, if gcc is invoked as a conforming C compiler.
In GNU C mode, gcc doesn't need any header for alloca():
fangorn:~/tmp 513> cat test.c
int main()
{
alloca();
return 0;
}
fangorn:~/tmp 514> gcc test.c
test.c: In function `main':
test.c:3: error: too few arguments to function `alloca'
gcc obviously has "insider information" about alloca in GNU C mode, since
no header has been included. OTOH, it forgets everything once invoked
in conforming mode:
fangorn:~/tmp 515> gcc -ansi test.c
/tmp/ccW0emnD.o(.text+0x11): In function `main':
: undefined reference to `alloca'
collect2: ld returned 1 exit status
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote: In any case, Dave said (incorrectly) that gcc doesn't recognize
alloca();
I didn't (or at least didn't intend to) say that; what I meant to say was
that gcc-as-a-C-compiler (as opposed to, say, gcc-as-a-Java-compiler,
or gcc-as-a-GNUC-compiler, or gcc-as-a-C++-compiler) doesn't recognize
alloca. We were talking about C here, weren't we?
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
Of course, as long as the result is correct, a compiler *is* allowed to use
something like Divine Guidance to avoid any extra overhead. It just is not
very likely. --Chris Torek in comp.lang.c dj******@csclub.uwaterloo.ca (Dave Vandervies) writes: In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:In any case, Dave said (incorrectly) that gcc doesn't recognize
alloca();
I didn't (or at least didn't intend to) say that; what I meant to say was
that gcc-as-a-C-compiler (as opposed to, say, gcc-as-a-Java-compiler,
or gcc-as-a-GNUC-compiler, or gcc-as-a-C++-compiler) doesn't recognize
alloca. We were talking about C here, weren't we?
Yes.
You said that a man page said that alloca() is declared in <stdlib.h>.
All the man pages I've seen say that it's declared in <alloca.h>.
Based on that, I misunderstood the point you were making. Sorry.
I also see now that gcc, in its default (non-conforming) mode, does
allow calls to alloca() when <stdlib.h> is included.
Even in conforming mode ("gcc -ansi -pedantic -Wall -W" or
"gcc -std=c99 -pedantic -Wall -W"), gcc allows calls to alloca() when
<alloca.h> is included (which is allowed because <alloca.h> is an
implementation-defined header).
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Nitin Bhardwaj |
last post by:
Hi all,
I want to know what is wrong with alloca() ?
Is it hard to implement in a platform-independent way?
OR there is no need for it?
AFAIK alloca() /*(used to)*/ allocate memory at...
|
by: Sushil |
last post by:
Hi gurus
I was reading FAQ
"alloca cannot be written portably, and is difficult to implement on
machines without a conventional stack."
I understand that the standard does not mandate...
|
by: Freejack |
last post by:
Recently I've been spending some time googling around for ideas for an
alloca() replacement that could function in a strict ANSI C environment.
As we all know, alloca() is system/arch dependant.
...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
