Microsoft abandons the C language

[Öö Tiib]

Le 05/09/12 00:13, Ian Collins a écrit :


int fn(void)
{
int i;
}

You do not test for "int i;"

We should ban then all stack allocation?

What are you saying actually? I do not understand what you want.

The VLA is actually non-standard alloca() standardized behind array
declaration syntax. Using alloca() for up to few hundred bytes was
generally fine and improved performance. Nothing revolutionary there.

Bad usage of alloca() resulted with some legendary stories about
most memorable stack overflow fun. Similar things will happen with
those VLAs.

So Ian is worried. Jacob maybe uses it nicely. Next noob in team
however breaks it and then it is harder to track down than alloca().
VLA is not that easy to find with text search unlike alloca().

 

[Ben Bacarisse]

VLAs are a vulnerability waiting to happen. Not as bad as gets, but
dodgy none the less.

I don't understand this. I need more information. My guess is that you
are referring to environments that don't check stack accesses, but
that's not really the fault of the language feature.

There's a point I've been meaning to make, and I might as well inject
here since it is at least tangentially related to the above. On systems
that check stack access I don't see anything logically different between
using a VLA and doing the very common

if ((p = malloc(size)) == NULL) {
fprintf(stderr, "Eek! Out or memory.\n");
exit(EXIT_FAILURE):
}

Sure, you might have less stack available, and the error message you get
from a stack overflow might be more cryptic, but VLAs are criticised on
other grounds entirely.

<snip>

 

[Ben Bacarisse]

On 09/ 6/12 02:57 AM, Malcolm McLean wrote:

It may provides better documentation, but it precludes static analysis
of stack usage.

Sorry, I'm repeating myself! How does a VLA preclude static analysis of
stack usage?

 

[Kaz Kylheku]

The VLA is actually non-standard alloca() standardized behind array
declaration syntax. Using alloca() for up to few hundred bytes was
generally fine and improved performance. Nothing revolutionary there.

Bad usage of alloca() resulted with some legendary stories about
most memorable stack overflow fun. Similar things will happen with
those VLAs.

Last I looked, the dynamic linker in glibc (i.e. on most Linux installations)
uses alloca for allocating tables. The allocation is proportional to the number
of symbols to be resolved or something like that. Found this the hard way when
I was trying to reduce the thread stack sizes in a large application with many
threads. The main thread wanted more than a megabyte, and crashed even before
main was invoked.

 

[ImpalerCore]

I don't understand this.  I need more information.  My guess is that you
are referring to environments that don't check stack accesses, but
that's not really the fault of the language feature.

There's a point I've been meaning to make, and I might as well inject
here since it is at least tangentially related to the above.  On systems
that check stack access I don't see anything logically different between
using a VLA and doing the very common

  if ((p = malloc(size)) == NULL) {
       fprintf(stderr, "Eek!  Out or memory.\n");
       exit(EXIT_FAILURE):
  }

Sure, you might have less stack available, and the error message you get
from a stack overflow might be more cryptic, but VLAs are criticised on
other grounds entirely.

This is probably before my time, but why wasn't a NULL returning
'alloca' equivalent included in the standard?

 

[Ben Bacarisse]

This is probably before my time, but why wasn't a NULL returning
'alloca' equivalent included in the standard?

From "Rationale for International Standard - Programming Languages - C"
(Revision 5.10, April-2003):

"Some implementations provide a function, often called alloca, which
allocates the requested object from automatic storage; and the object
is automatically freed when the calling function exits. Such a
function is not efficiently implementable in a variety of
environments, so it was not adopted in the Standard."

 

[Ian Collins]

Sorry, I'm repeating myself! How does a VLA preclude static analysis of
stack usage?

Because you don't know until run time how long it will be. If you did,
you wouldn't need a variable length.

 

[Ian Collins]

I don't understand this. I need more information. My guess is that you
are referring to environments that don't check stack accesses, but
that's not really the fault of the language feature.

In the smaller embedded world (without protected memory), whose are the
norm.

 

[Ben Bacarisse]

In the smaller embedded world (without protected memory), whose are
the norm.

You mean VLAs larger than typical stack allocations are not safe in some
environments? That's very different to "VLAs are a vulnerability
waiting to happen".

 

[Ben Bacarisse]

Because you don't know until run time how long it will be. If you
did, you wouldn't need a variable length.

I'm still lost. Static analysis can be done when some aspects of what's
being analysed depends on input, can't it? When I prove termination of
a loop, that's static analysis is it not? The proof can be often done
even when the loop conditions and execution depend on input. It would
be rather pointless otherwise.

 

[Malcolm McLean]

בת×ריך ×™×•× ×—×ž×™×©×™, 6 בספטמבר 2012 21:25:43 UTC+1, מ×ת Ben Bacarisse:

Ian Collins <[email protected]> writes:

I'm still lost. Static analysis can be done when some aspects of what's
being analysed depends on input, can't it? When I prove termination of
a loop, that's static analysis is it not? The proof can be often done
even when the loop conditions and execution depend on input. It would
be rather pointless otherwise.

It depends.

Consider this

FILE *fp;
long long N;
long long i;

N = get64(fp);
for(i=0;i<N;i++)
printf("%d\n", i);

that loop obvioulsy must terminate. However on a typical system, that observation isn't particularly useful.

 

[Ben Bacarisse]

בת×ריך ×™×•× ×—×ž×™×©×™, 6 בספטמבר 2012 21:25:43 UTC+1, מ×ת Ben Bacarisse:

It depends.

What is "it"? I don't think it corresponds to anything so far
discussed. I've no trouble with introducing a new point, but I don't
think you can call it "it" without confusion.

Consider this

FILE *fp;
long long N;
long long i;

N = get64(fp);
for(i=0;i<N;i++)
printf("%d\n", i);

that loop obvioulsy must terminate. However on a typical system, that
observation isn't particularly useful.

This seems to be saying that some analytical results are not always
useful. Obviously I agree.

 

[Keith Thompson]

There's a point I've been meaning to make, and I might as well inject
here since it is at least tangentially related to the above. On systems
that check stack access I don't see anything logically different between
using a VLA and doing the very common

if ((p = malloc(size)) == NULL) {
fprintf(stderr, "Eek! Out or memory.\n");
exit(EXIT_FAILURE):
}

Sure, you might have less stack available, and the error message you get
from a stack overflow might be more cryptic, but VLAs are criticised on
other grounds entirely.

At least as far as the language definition is concerned, there's
a big difference.

For the malloc() case, if the allocation fails, it's guaranteed that
(a) the "Eek!" message will be printed, and (b) whatever statement
follows that if statement will not be executed.

For the equivalent VLA code, there is no such guarantee; the behavior
is undefined.

If you're happy depending on guarantees made by your system, not
by the language, that stack overflows will cause your program to
terminate immediately, then of course you're free to do so, but
I think it's important to be clear about where those guarantees
come from.

(The malloc() case isn't that simple in real life; on Linux, the
malloc() call can appear to succeed, but your program or another one
can crash when you try to access the supposedly allocated memory.
It's debatable whether that behavior is conforming.)

 

[Ben Bacarisse]

At least as far as the language definition is concerned, there's
a big difference.

For the malloc() case, if the allocation fails, it's guaranteed that
(a) the "Eek!" message will be printed, and (b) whatever statement
follows that if statement will not be executed.

For the equivalent VLA code, there is no such guarantee; the behavior
is undefined.

Is that not also the case for the malloc code if the variable p can not
be allocated? Provided the "one program" condition of 5.4.2.1 is met,
I'd always assumed that one can't, from the formal point of view of the
language definition, depend on any automatic objects being successfully
created.

If that's right, almost all C code is undefined in the face of stack
allocation failures. One can make statistical arguments about what's
likely of course (quite apart from relying on extra-standard guarantees)
but you are making a formal distinction, it seems, rather than a
practical one.

If you're happy depending on guarantees made by your system, not
by the language, that stack overflows will cause your program to
terminate immediately, then of course you're free to do so, but
I think it's important to be clear about where those guarantees
come from.

Yes. I thought I had been with the "On systems that..." condition but
maybe I did not say enough. I certainly could have said more.

 

[Ian Collins]

I'm still lost. Static analysis can be done when some aspects of what's
being analysed depends on input, can't it? When I prove termination of
a loop, that's static analysis is it not? The proof can be often done
even when the loop conditions and execution depend on input. It would
be rather pointless otherwise.

I was thinking of the narrower case of the tools I have written to
analyse (embedded) code to determine the amount of stack required for
each thread.

 

[James Kuyper]

What is "it"?

When "It depends" is given in response to a question, "it" refers to the
answer to the question. An equivalent but longer statement would be "The
answer to your question depends upon the circumstances". I agree that
the connection between his response and your questions is, at best,
tenuous, but the problem is not due to ambiguity in the referent of "it".

 

[Phil Carmody]

From "Rationale for International Standard - Programming Languages - C"
(Revision 5.10, April-2003):

"Some implementations provide a function, often called alloca, which
allocates the requested object from automatic storage; and the object
is automatically freed when the calling function exits. Such a
function is not efficiently implementable in a variety of
environments, so it was not adopted in the Standard."

And how are VLA's more efficiently implementable in those environments?

Phil

 

[Ben Bacarisse]

When "It depends" is given in response to a question, "it" refers to the
answer to the question. An equivalent but longer statement would be "The
answer to your question depends upon the circumstances".

Thanks, but in fact I knew that. Given the difficulty in judging tone
on Usenet, the only safe assumption is that you are making an honest
attempt to help me out, despite what that means for your opinion of my
language skills! Anyway, thanks again.

 

[Ben Bacarisse]

And how are VLA's more efficiently implementable in those
environments?

That question occurred to me too, but since I could not even come up
with an example of one of these environments, I decided I should just
leave the quote to stand on its own.

 

[James Kuyper]

Thanks, but in fact I knew that. Given the difficulty in judging tone
on Usenet, the only safe assumption is that you are making an honest
attempt to help me out, despite what that means for your opinion of my
language skills! Anyway, thanks again.

It was an honest attempt to help you out - though I found it hard to
imagine that your English skill were that bad. However, I had to assume
that they were that bad - if they weren't, you would have had no reason
to ask what "it" was. Now that I know that you did know what "it" was,
I'm mystified by your decision to ask a question you already knew the
answer to.

To be fair, I'm also mystified by Malcolm's implied belief that his
answer (the one dated 2012-09-05 07:57:11 -0700) was responsive to your
question, but that's a much more complicated issue.