Inline Assembly - Runtime Stack Allocation

[Brian Lindahl]

I'm using a temporary buffer to transfer some data and would rather
not allocate it on the heap. The problem is that the size of the
buffer is only known upon entry into the function that utilizes it and
I'd rather not waste space or dynamically allocate on the heap (since
it doesn't need to persist). Now I'm planning on utilizing inline
assembly to modify the stack pointer directly to allocate the space I
need.

Here's an example:

void doSomeStuff(unsigned size) {
char* rawData;
//INLINED (Intel p4 assembly)
//sub esp, dword ptr [size]
//mov dword ptr [rawData], esp

//do some stuff with the temporary buffer, using rawData to access
it

//INLINED (Intel p4 assembly)
//add esp, dword ptr [size]
}

As far as I know, it should work just fine, like magic - no problems
at all. BUT, is this assumption correct? Are there any odd quirks that
I should be aware of that I may not have thought of?

[Joona I Palaste]

Brian Lindahl <li******@hotmail.com> scribbled the following:

I'm using a temporary buffer to transfer some data and would rather
not allocate it on the heap. The problem is that the size of the
buffer is only known upon entry into the function that utilizes it and
I'd rather not waste space or dynamically allocate on the heap (since
it doesn't need to persist). Now I'm planning on utilizing inline
assembly to modify the stack pointer directly to allocate the space I
need.

Inline assembly is inherently implementation-specific and thus off-topic
on comp.lang.c. Please ask in a newsgroup dedicated to your own
implementation.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"A computer program does what you tell it to do, not what you want it to do."
- Anon

[Severian]

On 30 Jun 2004 23:44:19 -0700, li******@hotmail.com (Brian Lindahl)
wrote:

I'm using a temporary buffer to transfer some data and would rather
not allocate it on the heap. The problem is that the size of the
buffer is only known upon entry into the function that utilizes it and
I'd rather not waste space or dynamically allocate on the heap (since
it doesn't need to persist). Now I'm planning on utilizing inline
assembly to modify the stack pointer directly to allocate the space I
need.

Here's an example:

void doSomeStuff(unsigned size) {
char* rawData;
//INLINED (Intel p4 assembly)
//sub esp, dword ptr [size]
//mov dword ptr [rawData], esp

//do some stuff with the temporary buffer, using rawData to access
it

//INLINED (Intel p4 assembly)
//add esp, dword ptr [size]
}

As far as I know, it should work just fine, like magic - no problems
at all. BUT, is this assumption correct? Are there any odd quirks that
I should be aware of that I may not have thought of?

comp.lang.asm.x86 is right over there ----->
--
Sev

[Richard Bos]

li******@hotmail.com (Brian Lindahl) wrote:

I'm using a temporary buffer to transfer some data and would rather
not allocate it on the heap. The problem is that the size of the
buffer is only known upon entry into the function that utilizes it and
I'd rather not waste space or dynamically allocate on the heap (since
it doesn't need to persist). Now I'm planning on utilizing inline
assembly to modify the stack pointer directly to allocate the space I
need.

This is usually a very, very bad idea. What actual reasons have you for
_not_ using malloc(), which is quite nicely suited to this task? Come to
think of it, since you're using this space only as a transfer buffer,
why can't you transfer your data in fixed-size chunks?

Richard

[jacob navia]

In C you can write:

int fn(int siz,char buf[siz])
{
}

This will provoke the generation of a similar assembly to what you write.

Note that your assembly code will not work under
the windows operating system making the program crash if
the size is bigger than 4096 bytes.

If you are a windows user you can look at the assembly
generated for the above function by lcc-win32: you will see
that instead of a subtraction from esp a call to _alloca
is generated.

The _alloca function will subtract at most 4096 bytes from the stack
at each time, then TOUCH the page, then subtract more. This avoids
crashing.

http://www.cs.virginia.edu/~lcc-win32

[Richard Bos]

"jacob navia" <ja***@jacob.remcomp.fr> wrote:

In C you can write:

int fn(int siz,char buf[siz])
{
}
Only in C99, though.
This will provoke the generation of a similar assembly to what you write.

This is by no means guaranteed. What it will do is provide similar
_semantics_; the assembly code used to put these into effect are
off-topic on this newsgroup.

Richard

[Old Wolf]

rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<40****************@news.individual.net>...

"jacob navia" <ja***@jacob.remcomp.fr> wrote:

In C you can write:

int fn(int siz,char buf[siz])
{
}

Only in C99, though.

This code is valid in both C90 and C99, and is the same as:

int fn(int size, char *buf) {}

This will provoke the generation of a similar assembly to what you write.

This is by no means guaranteed. What it will do is provide similar
_semantics_; the assembly code used to put these into effect are
off-topic on this newsgroup.

You might be thinking of:

int fn(int siz)
{
char buf[siz];
}

[Chris Torek]

[some vertical-compression editing]

"jacob navia" <ja***@jacob.remcomp.fr> wrote:

In C you can write:
int fn(int siz,char buf[siz]) { ... }

rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message
news:<40****************@news.individual.net>.. .

Only in C99, though.

In article <news:84**************************@posting.google. com>
Old Wolf <ol*****@inspire.net.nz> writes:This code is valid in both C90 and C99 ...
No, it is only valid in C99 -- the size parameter in C89 / C90 may
be omitted entirely, or may be a constant-expression (which is
subsequently discarded), but it may not be an identifier (unless
that identifier is in turn a constant, e.g., an enum member).
... and is the same as:
int fn(int size, char *buf) {}
Yes.

Not sure who the pronoun "you" refers to here -- Jacob Navia, Richard
Bos, the USENET reader, some combination of these? -- but to continue:
You might be thinking of:
int fn(int siz)
{
char buf[siz];
}

This is indeed the "right way" to achieve what the original poster
wanted to do. (Whether doing so is a good idea is another matter
entirely.) In C89/C90, the most likely option is the nonstandard
"alloca" function, which typically interferes with a C compiler's
attempts to use a stack pointer for its own purposes. As a result,
calls to alloca() are, if allowed at all, often quite restricted
-- kind of like setjmp(), in other words.

(For instance, given "char *p", a sequence like:

p = strcpy(alloca(len), somestr);

may "blow up" at runtime by destroying the current stack frame,
while:

p = alloca(len);
strcpy(p, somestr);

may work correctly. A great deal depends on the CPU architecture
and C compiler, though. The semantics of C99's VLAs are not entirely
isomorphic to those of alloca(), but do avoid this problem.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Brian Lindahl]

From what I gather from the groups, is that my solution was unsafe for
more complicated operating systems that have some sort of protection
or paging dynamics. I did some research and found a solution that most
C compilers support (pretty much 99% of all compilers in current use
today).

void *alloca(size_t size) - allocates a block of <size> bytes on the
stack from and returns a pointer to the start of the block, the block
is automatically freed upon return from the function it was called in
(in most implementations)

Here's a slightly informative documentation of one compiler's
implementation:
http://www.datafocus.com/docs/man3/alloca.3.asp

Note that anyone using this should investigate how their compiler
implements alloca(), as it can get sticky when using it within loops
and if statements (due to scoping). Some compilers will release the
memory upon leaving scope (loop-safe), while others will release the
memory upon leaving the function it is called in (can cause stack
bloating when used within loops).

Hope this is helpful for all those who may want to do the same thing.
This function was what I was exactly looking for - rather than
complaining about this being off topic, infer based upon what I was
trying to do that I was looking for C solution to stack allocation and
was going towards the inline assembly route.

From the poor ability of inference in here, it seems the majority of
you would be better suited for the legal profession rather than
engineering profession - I've seen similar attitudes in many posts
here, whats the deal with trying to be as useless as possible?

[Jack Klein]

On 1 Jul 2004 17:23:35 -0700, li******@hotmail.com (Brian Lindahl)
wrote in comp.lang.c:

From what I gather from the groups, is that my solution was unsafe for
more complicated operating systems that have some sort of protection
or paging dynamics. I did some research and found a solution that most
C compilers support (pretty much 99% of all compilers in current use
today).
Makes no difference, there is no such thing as alloca() in standard C,
so it's completely off-topic here.
void *alloca(size_t size) - allocates a block of <size> bytes on the
As I said, it's off-topic here.
stack from and returns a pointer to the start of the block, the block
is automatically freed upon return from the function it was called in
(in most implementations)
Non-standard extensions which are different from one implementation to
the next are specifically off-topic here.
Here's a slightly informative documentation of one compiler's
implementation:
http://www.datafocus.com/docs/man3/alloca.3.asp

Note that anyone using this should investigate how their compiler
implements alloca(), as it can get sticky when using it within loops
No, they shouldn't. This group discusses the C language, which is
defined by an ANSI/ISO International Standard. That standard does not
contain alloca(), so it is not C but just another non-standard
extension. That makes it off-topic here.

If you want to discuss non-standard extensions to one compiler or
another, take it to compiler-specific newsgroups. It's off-topic
here.
and if statements (due to scoping). Some compilers will release the
memory upon leaving scope (loop-safe), while others will release the
memory upon leaving the function it is called in (can cause stack
bloating when used within loops).
Yes, that's the problem with non-standard extensions. Even if the an
extension with the same name exists on another compiler, it may very
well not work the same way. Or even be close. That's what the
"non-standard" part of non-standard extension means.
Hope this is helpful for all those who may want to do the same thing.
No, it's not helpful here, it's off-topic wasted bandwidth.
This function was what I was exactly looking for - rather than
complaining about this being off topic, infer based upon what I was
trying to do that I was looking for C solution to stack allocation and
was going towards the inline assembly route.
There is no such thing as either "stack allocation" or "inline
assembly" in C.
From the poor ability of inference in here, it seems the majority of
It has nothing to do with inference. This newsgroup has a topic,
quite well expressed by its name, comp.lang.c. That is, it discusses
the C computer programming language. Now there is absolutely no doubt
at all about what constitutes the C computer programming language. It
is defined by ISO/ANSI/IEC (and a host of other international
standards bodies) standard 9899.

There is no "alloca", "stack allocation", or "inline assembly" in that
standard, so there are no such things in the C programming language,
the topic of this group.
you would be better suited for the legal profession rather than
engineering profession - I've seen similar attitudes in many posts
here, whats the deal with trying to be as useless as possible?

The deal is trying to gently educate klewless newbies that many
newsgroups have topics and those topics should be adhered to.
Unfortunately some are terminally klewless and feel they have the
right to be thanked, worshiped, and adored for barging in with their
off-topic rubbish and persisting after they have been informed that is
it off-topic.

BTW, have I told you that you're off-topic?

*plonk*

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Richard Tobin]

In article <co********************************@4ax.com>,
Jack Klein <ja*******@spamcop.net> wrote:

Makes no difference, there is no such thing as alloca() in standard C,
so it's completely off-topic here.

I've encountered some idiots in my time, but I never thought I'd hear
anyone complain about discussing alloca() in comp.lang.c. Do you
behave like this in real life?

-- Richard

[Default User]

Richard Tobin wrote:

In article <co********************************@4ax.com>,
Jack Klein <ja*******@spamcop.net> wrote:

Makes no difference, there is no such thing as alloca() in standard C,
so it's completely off-topic here.

I've encountered some idiots in my time, but I never thought I'd hear
anyone complain about discussing alloca() in comp.lang.c. Do you
behave like this in real life?

Then you're going to meet many more idiots. Try to find out what the
topic of a newsgroup is before posting. And when you make a mistake,
accept the correction humbly, not in a bitchy manner like this.

There wasn't a single thing wrong with what Jack said or how he said it.

Brian Rodenborn

[Mark McIntyre]

On 2 Jul 2004 22:24:26 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:

In article <co********************************@4ax.com>,
Jack Klein <ja*******@spamcop.net> wrote:

Makes no difference, there is no such thing as alloca() in standard C,
so it's completely off-topic here.
I've encountered some idiots in my time, but I never thought I'd hear
anyone complain about discussing alloca() in comp.lang.c.

Hm? alloca() is not part of ISO C. If you think its idiotic to discuss it
in a group dedicated to ISO C, explain why.
Do you behave like this in real life?

This /is/ real life. I'm really here, in front of my screen.
--
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 =---
----== 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 =---

[Richard Tobin]

In article <ur********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.net> wrote:

Hm? alloca() is not part of ISO C.

Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

-- Richard

[Ben Pfaff]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

You must be new around here.
--
"This is a wonderful answer.
It's off-topic, it's incorrect, and it doesn't answer the question."
--Richard Heathfield

[jacob navia]

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> a écrit dans le message de
news:cc***********@pc-news.cogsci.ed.ac.uk...

In article <ur********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.net> wrote:

Hm? alloca() is not part of ISO C.

Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

I would say that since this newsgroup is not a moderated one,
anyone is free to post what he/she wants.

Some people will say that "the subject of this group is ISO C",
some others (like me) will say that the subject of this group
is the C language, and not some subset of it as defined
by ISO C.

alloca() belongs to this group, since it is present in almost all
implementations of the C language I know of.

I would propose that we avoid insulting each other however...

[Mark McIntyre]

On 3 Jul 2004 01:18:26 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:

In article <ur********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.net> wrote:

Hm? alloca() is not part of ISO C.

Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

Either you're a troll, or you're an idiot. Which is it?

--
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 =---
----== 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]

On Sat, 3 Jul 2004 10:16:18 +0200, in comp.lang.c , "jacob navia"
<ja***@jacob.remcomp.fr> wrote:

I would say that since this newsgroup is not a moderated one,
anyone is free to post what he/she wants.
You can certainly post whatever you want to.
Some people will say that "the subject of this group is ISO C",
some others (like me) will say that the subject of this group
is the C language, and not some subset of it as defined
by ISO C.
What you define it as is of no consequence. Nor is what I define it as. The
group's topic is well known, well defined and it is ISO/Ansi C, and at a
pinch K&R C. See the welcome message.
alloca() belongs to this group, since it is present in almost all
implementations of the C language I know of.

If you want to insist on talking about unix extensions to ISO C here, then
feel free to get some really good heatproof clothing first.
--
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 =---
----== 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 =---

[jacob navia]

"Mark McIntyre" <ma**********@spamcop.net> a écrit dans le message de
news:nt********************************@4ax.com...

On Sat, 3 Jul 2004 10:16:18 +0200, in comp.lang.c , "jacob navia"
<ja***@jacob.remcomp.fr> wrote:
If you want to insist on talking about unix extensions to ISO C here, then
feel free to get some really good heatproof clothing first.

Unix extensions?

Microsofts compilers, Borland compilers and all windows compilers
I know of have featured alloca since quite a long time.

alloca exists in the Cray OS, in the Atari OS I used some centuries ago.

Actually I have never seen a serious compiler without it.

[jacob navia]

"Mark McIntyre" <ma**********@spamcop.net> a écrit dans le message de
news:qr********************************@4ax.com...

On 3 Jul 2004 01:18:26 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:
Either you're a troll, or you're an idiot. Which is it?

Can't we speak without insults?

Thanks for your understanding.

I find the only thing *really* OFF TOPIC are insults.

[Mark McIntyre]

On Sat, 3 Jul 2004 23:17:50 +0200, in comp.lang.c , "jacob navia"
<ja***@jacob.remcomp.fr> wrote:

Microsofts compilers, Borland compilers and all windows compilers
I know of have featured alloca since quite a long time.
a) so what?
b) MSDOS and its derivants are a real small part of computing, and closely
akin to Unix.
alloca exists in the Cray OS, in the Atari OS I used some centuries ago.

Actually I have never seen a serious compiler without it.

I have. Just because your own experience is limited, don't assume it equals
the whole world.
--
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 =---
----== 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]

On Sat, 3 Jul 2004 23:19:26 +0200, in comp.lang.c , "jacob navia"
<ja***@jacob.remcomp.fr> wrote:

"Mark McIntyre" <ma**********@spamcop.net> a écrit

Either you're a troll, or you're an idiot. Which is it?
Can't we speak without insults?

I dunno. Can't people refrain from posting inflammatory remarks?
Thanks for your understanding.
And yours.
I find the only thing *really* OFF TOPIC are insults.

*shrug*.
--
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 =---
----== 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 =---

[E. Robert Tisdale]

jacob navia wrote:

Something that calls itself Mark McIntyre a écrit:

Either you're a troll, or you're an idiot. Which is it?

Can't we speak without insults?

Thanks for your understanding.

I find the only thing *really* OFF TOPIC are insults.

Mark McIntyre is a troll.
Please ignore it.

[Irrwahn Grausewitz]

"jacob navia" <ja***@jacob.remcomp.fr> wrote:

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> a écrit dans le message de
news:cc***********@pc-news.cogsci.ed.ac.uk...

In article <ur********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.net> wrote:

>Hm? alloca() is not part of ISO C.
Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

No need to, it already exists: comp.lang.c.
I would say that since this newsgroup is not a moderated one,
anyone is free to post what he/she wants.
But be prepared for undefined behaviour if the material is off-topic.
Some people
among them the vast majority of regular posters
will say that "the subject of this group is ISO C",
some others (like me)
a negligible minority of regulars, plus some newbies, plus some
trolls
will say that the subject of this group
is the C language, and not some subset of it as defined
by ISO C.

alloca() belongs to this group, since it is present in almost all
implementations of the C language I know of.
Your knowledge does not define topicality for this group.
I would propose that we avoid insulting each other however...

A good proposal, but, alas, if you don't want to get bitten, do not
tease the monkeys in the first place.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Dan Pop]

In <cc**********@news-reader3.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes:

"Mark McIntyre" <ma**********@spamcop.net> a écrit dans le message de
news:nt********************************@4ax.com.. .

On Sat, 3 Jul 2004 10:16:18 +0200, in comp.lang.c , "jacob navia"
<ja***@jacob.remcomp.fr> wrote:
If you want to insist on talking about unix extensions to ISO C here, then
feel free to get some really good heatproof clothing first.

Unix extensions?

Microsofts compilers, Borland compilers and all windows compilers
I know of have featured alloca since quite a long time.

alloca exists in the Cray OS, in the Atari OS I used some centuries ago.

Actually I have never seen a serious compiler without it.

alloca has been a mistake in the first place. See the FAQ or even
Stevens' bible about Unix programming, to find out why. It's not only
the C standard that doesn't support it, the Unix standards don't support
it, either.

It is sheer foolishness to encourage anyone to use this *legacy* function
in new C code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <cc**********@news-reader4.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes:

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> a écrit dans le message de
news:cc***********@pc-news.cogsci.ed.ac.uk...

In article <ur********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.net> wrote:

>Hm? alloca() is not part of ISO C.
Comp.lang.c has been here since before there was an ISO C. If you
want a group that can't discuss any aspect of C that isn't in the ISO
standard, feel free to create your own.

The purpose of an unmoderated newsgroup is defined by the quasi consensus
of its regulars (i.e. the people who actually provide value to the
newsgroup).
I would say that since this newsgroup is not a moderated one,
anyone is free to post what he/she wants.
And anyone posting what s/he wants should be prepared to face the
consequences of such an act: if you're free to post what you want, I am
equally free to reply to your post in whatever manner *I* want. If you're
rude by posting off-topic questions/answers, I can be equally rude when
replying to your posts: you have no monopoly on rudeness here.
Some people will say that "the subject of this group is ISO C",
some others (like me) will say that the subject of this group
is the C language, and not some subset of it as defined
by ISO C.
It's just that some people's opinion counts more than others'. The more
you contribute to this newsgroup's value, the more your opinion counts
and is respected by the other people.
alloca() belongs to this group, since it is present in almost all
implementations of the C language I know of.

Indeed: newbies should be explained that alloca is a legacy function,
flawed by design, that should NEVER be used in new code. That's all that
it's to be said about it in c.l.c.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de