Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1521 > unrolled thread

Why are VLAs optional in C11?

Back to article view | Back to comp.std.c

Contents

  Why are VLAs optional in C11? Keith Thompson <kst-u@mib.org> - 2012-08-17 15:42 -0700
    Re: Why are VLAs optional in C11? Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-18 01:19 +0200
      Re: Why are VLAs optional in C11? Keith Thompson <kst-u@mib.org> - 2012-08-17 16:23 -0700
        Re: Why are VLAs optional in C11? Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-18 10:12 +0200
      Re: Why are VLAs optional in C11? John Nagle <nagle@animats.com> - 2012-08-17 21:04 -0700
        Re: Why are VLAs optional in C11? pacman@kosh.dhis.org (Alan Curry) - 2012-08-18 05:34 +0000
          Re: Why are VLAs optional in C11? John Nagle <nagle@animats.com> - 2012-08-17 23:07 -0700
            Re: Why are VLAs optional in C11? pacman@kosh.dhis.org (Alan Curry) - 2012-08-18 08:29 +0000
              Re: Why are VLAs optional in C11? John Nagle <nagle@animats.com> - 2012-08-18 09:37 -0700
                Re: Why are VLAs optional in C11? pa@see.signature.invalid (Pierre Asselin) - 2012-08-19 02:27 +0000
              Re: Why are VLAs optional in C11? Ike Naar <ike@sverige.freeshell.org> - 2012-08-18 17:49 +0000
        Re: Why are VLAs optional in C11? Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-18 08:32 +0200
        Re: Why are VLAs optional in C11? Keith Thompson <kst-u@mib.org> - 2012-08-18 02:50 -0700
        Re: Why are VLAs optional in C11? jacob navia <jacob@spamsink.net> - 2012-08-18 14:33 +0200
          Re: Why are VLAs optional in C11? Ike Naar <ike@sverige.freeshell.org> - 2012-08-18 13:23 +0000
          Re: Why are VLAs optional in C11? Keith Thompson <kst-u@mib.org> - 2012-08-18 13:48 -0700
            Re: Why are VLAs optional in C11? jacob navia <jacob@spamsink.net> - 2012-08-18 23:31 +0200
              Re: Why are VLAs optional in C11? Keith Thompson <kst-u@mib.org> - 2012-08-18 18:14 -0700
                Re: Why are VLAs optional in C11? jacob navia <jacob@spamsink.net> - 2012-08-19 09:38 +0200
                  Re: Why are VLAs optional in C11? Keith Thompson <kst-u@mib.org> - 2012-08-19 03:07 -0700
                    Re: Why are VLAs optional in C11? jacob navia <jacob@spamsink.net> - 2012-08-19 12:29 +0200
                      Re: Why are VLAs optional in C11? John Nagle <nagle@animats.com> - 2012-08-19 10:38 -0700
                        Re: Why are VLAs optional in C11? Keith Thompson <kst-u@mib.org> - 2012-08-19 13:14 -0700
                          Re: Why are VLAs optional in C11? Keith Thompson <kst-u@mib.org> - 2012-08-19 13:59 -0700
                        Re: Why are VLAs optional in C11? Owen Shepherd <nntp@owenshepherd.net> - 2012-08-27 22:17 +0100
                          Re: Why are VLAs optional in C11? Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 00:34 +0200
                          Re: Why are VLAs optional in C11? John Nagle <nagle@animats.com> - 2012-08-27 19:36 -0700
                            Re: Why are VLAs optional in C11? James Kuyper <jameskuyper@verizon.net> - 2012-08-27 22:54 -0400
                              Re: Why are VLAs optional in C11? John Nagle <nagle@animats.com> - 2012-08-27 22:39 -0700
          Re: Why are VLAs optional in C11? "pdx_scooter@yahoo.com" <pdx_scooter@yahoo.com> - 2022-10-01 13:15 -0700
            Re: Why are VLAs optional in C11? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-01 14:33 -0700
            Re: Why are VLAs optional in C11? Tomasz Stanislawski <stanislawski.tomasz@googlemail.com> - 2023-01-25 04:21 -0800
    Re: Why are VLAs optional in C11? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-17 20:54 -0400
    Re: Why are VLAs optional in C11? John Nagle <nagle@animats.com> - 2012-08-17 20:56 -0700

Page 2 of 2 — ← Prev page 1 [2]

#1545

Le 19/08/12 12:07, Keith Thompson a écrit :
> jacob navia <jacob@spamsink.net> writes:
>> Le 19/08/12 03:14, Keith Thompson a écrit :
>>> Incidentally, there was an lcc-win bug report in my previous article.
>>> Did you see it?  Would you like me to resubmit it through other
>>> channels?
>>
>> yes, I am missing multiplying by the size of the element of the array in
>> your example sizeof int.
>
> You're welcome, glad I could help.
>
> (Any comment on the fact that it's non-conforming?)
>
1) This is a (now) optional feature. So, I think it is better when you
call the sizeof operator to have the size of the table and not the size
of some pointer because of obscure C rules that impose the lost of
information that can be given to the user.

2) This is my personal opinion, but this proposal from Mr Nagle shows
that it would be interesting to NOT throw this info away.

[toc] | [prev] | [next] | [standalone]

#1546

On 8/19/2012 3:29 AM, jacob navia wrote:
> Le 19/08/12 12:07, Keith Thompson a écrit :
>> jacob navia <jacob@spamsink.net> writes:
>>> Le 19/08/12 03:14, Keith Thompson a écrit :
>>>> Incidentally, there was an lcc-win bug report in my previous article.
>>>> Did you see it?  Would you like me to resubmit it through other
>>>> channels?
>>>
>>> yes, I am missing multiplying by the size of the element of the array in
>>> your example sizeof int.
>>
>> You're welcome, glad I could help.
>>
>> (Any comment on the fact that it's non-conforming?)
>>
> 1) This is a (now) optional feature. So, I think it is better when you
> call the sizeof operator to have the size of the table and not the size
> of some pointer because of obscure C rules that impose the lost of
> information that can be given to the user.
> 
> 2) This is my personal opinion, but this proposal from Mr Nagle shows
> that it would be interesting to NOT throw this info away.

    The problem is the semantics of fixed-size array parameters
(but not local fixed-size arrays).  For those, too, the size of the
array is just the size of a pointer.  VLA parameters just repeat
that mess from fixed-size arrays.

    The underlying problem is that early C barely had arrays at
all, just pointers.  Square brackets were originally just
syntactic sugar for pointer arithmetic.  As C arrays acquired
somewhat stronger semantics, the new semantics were added in
ways that were backwards compatible with old code.  The
result is that C arrays are second-class objects.

    This is what led me to propose references to variable
size arrays as an addition to C.  A reference to an array
has full array semantics; it's not reduced to a pointer
without size information.  It looks like the design
in my paper

http://www.animats.com/papers/languages/safearraysforc36.pdf

would work; it's been criticized by about ten people and
the major holes have been plugged.  It's also something
that could potentially be extended to C++.

    But the existing VLA parameter mechanism is in the way.
That's why I'm interested in finding out how widespread
the use of that feature is.  So far, nobody has been able
to find a single instance of a VLA parameter in publicly
visible code, although one person says they used it
in their own code at least once.

    As I keep pointing out, this is the source of most
buffer overflows. The language doesn't know how big most
arrays are, and sometimes the programmer isn't quite sure.
A big fraction of program crashes and security holes come
from this fact.  So it's worth fixing.

				John Nagle

[toc] | [prev] | [next] | [standalone]

#1547

John Nagle <nagle@animats.com> writes:
[...]
>     The problem is the semantics of fixed-size array parameters
> (but not local fixed-size arrays).  For those, too, the size of the
> array is just the size of a pointer.  VLA parameters just repeat
> that mess from fixed-size arrays.

No, the problem with fixed-size array parameters is that *there is no
such thing*.  It's not true that "the size of the array is just the size
of the pointer".  The size of the pointer is the size of the pointer.

    void func(double arr[100]);

is nothing more than syntactic sugar (or perhaps syntactic vinegar)
for this:

    void func(double *arr);

I agree that it's a problem.  My point is that any solution needs to
account for the existing syntax and semantics.  You propose to introduce
something like array parameters, and that's fine, but I don't think
changing the semantics of any existing declarations is feasible.

I haven't read your entire proposal.  Do you propose that, given this
parameter declaration:

    double arr[N]

the *type* of arr depends on whether N is a constant expression?  If so,
I suggest that that would cause too much confusion, aside from being
incompatible with C90, C99, and C11.

[...]
>     But the existing VLA parameter mechanism is in the way.

Is it?  I haven't read your entire proposal, but aren't your new array
(or array-like) parameters implemented in terms of C++ish references?
If you can define your new features without changing the semantics of
*any* existing code, that would be a tremendous advantage.

Can you provide a concrete example of a function declaration whose
semantics you would change?  (Perhaps you've already done so, but this
is a big thread.)

[...]

And one more or less random thing: in the section on multidimensional
arrays, I don't see anything new.  The example you give is:

    size_t order = 3;
    ...
    float tab[order][order];// square array of order N.

which is a perfectly legal VLA in C99 and later.  It's restricted to
block scope; if you're proposing allowing it at file scope, you don't
mention it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1549

Keith Thompson <kst-u@mib.org> writes:
> John Nagle <nagle@animats.com> writes:
> [...]
>>     The problem is the semantics of fixed-size array parameters
>> (but not local fixed-size arrays).  For those, too, the size of the
>> array is just the size of a pointer.  VLA parameters just repeat
>> that mess from fixed-size arrays.
>
> No, the problem with fixed-size array parameters is that *there is no
> such thing*.  It's not true that "the size of the array is just the size
> of the pointer".  The size of the pointer is the size of the pointer.
>
>     void func(double arr[100]);
>
> is nothing more than syntactic sugar (or perhaps syntactic vinegar)
> for this:
>
>     void func(double *arr);
[...]

John, perhaps you're approaching this from the wrong direction.

You seem to be starting with the idea that `void func(double
arr[100])` defines `arr` as a parameter of array type (but
incidentally, C treats it as a parameter of pointer type).

Instead, I suggest starting with the idea that C does not have
parameters of pointer type (but incidentally, it permits pointer
parameters to be defined with array syntax).

That might make it easier to propose a consistent mechanism for
adding array or array-like parameters to the language.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1610

John Nagle wrote:
>      This is what led me to propose references to variable
> size arrays as an addition to C.  A reference to an array
> has full array semantics; it's not reduced to a pointer
> without size information.  It looks like the design
> in my paper
>
> http://www.animats.com/papers/languages/safearraysforc36.pdf
>
> would work; it's been criticized by about ten people and
> the major holes have been plugged.  It's also something
> that could potentially be extended to C++.

Regarding the above, is there any reason for not reusing the C++11 for 
each syntax

...
	for(auto i : obj)

considering it is reasonably clear, concise, won't conflict with any 
existing code, and would maintain orthogonality with C++?

That said, I can't see the C++ standards committee ever adopting it. 
Their position - and mine as a C++ user - is that you should use 
std::array<>. Generally, C++ doesn't add features which can be 
implemented equally well in the standard library (hence why C++11 
doesn't adopt, say, _Complex; it has std::complex<>)

[toc] | [prev] | [next] | [standalone]

#1611

Am 27.08.2012 23:17, schrieb Owen Shepherd:
> Generally, C++ doesn't add features which can be
> implemented equally well in the standard library (hence why C++11
> doesn't adopt, say, _Complex; it has std::complex<>)

which in that case is really a pity, because I think that "double
_Complex" has a bit of different semantics than "std::complex<double>".
The C type it is guaranteed not to have padding, which I think is
difficult to guarantee for any (straight) library implementation in C++,
isn't it?

(And again one of the missed oportunities of increasing overlap between
the two languages.)

Jens

[toc] | [prev] | [next] | [standalone]

#1612

On 8/27/2012 2:17 PM, Owen Shepherd wrote:
> John Nagle wrote:
>>      This is what led me to propose references to variable
>> size arrays as an addition to C.  A reference to an array
>> has full array semantics; it's not reduced to a pointer
>> without size information.  It looks like the design
>> in my paper
>>
>> http://www.animats.com/papers/languages/safearraysforc36.pdf
>>
>> would work; it's been criticized by about ten people and
>> the major holes have been plugged.  It's also something
>> that could potentially be extended to C++.
> 
> Regarding the above, is there any reason for not reusing the C++11 for
> each syntax
> 
> ...
>     for(auto i : obj)
> 
> considering it is reasonably clear, concise, won't conflict with any
> existing code, and would maintain orthogonality with C++?
> 
> That said, I can't see the C++ standards committee ever adopting it.
> Their position - and mine as a C++ user - is that you should use
> std::array<>. Generally, C++ doesn't add features which can be
> implemented equally well in the standard library (hence why C++11
> doesn't adopt, say, _Complex; it has std::complex<>)

    One problem is that many common APIs (notably Windows and Linux)
use C-type bindings.  When you have to pass an array to a system call,
a raw C pointer has to be extracted from the collection and passed
to an interface that doesn't know C++.  At that point, size information
has been lost, and the possibility of a buffer overflow appears.
C++ doesn't fix the problem, it just wallpapers over it with templates.
All too often, the mold seeps through the wallpaper.

    Another problem is that C++ collection classes don't have efficient
subscript checking.  Some implementations do offer subscript checking
of collection classes. But because the check is just a template
expansion, it has to be done where the template says to do it - on
every reference.  The compiler doesn't have the authority to haul
the check out of the loop when possible and do it once at loop
entrance.

Example:

	std::array<int,100> tab;
	for (int i=0; i<200; i++) { tab[i] = 0; }

With checking enabled, this will produce an error. But the
subscript check will be made on every iteration. It won't be
hoisted out of the loop during optimization.  The compiler
doesn't know that it would be OK to do this once at the
top of the loop.

    However, what I've been proposing in the safe array
area isn't addressed to C++.  It's addressed to C. I do
want to propose only changes that could be potentially
added to C++, because the languages should not diverge
unnecessarily.  (And because Microsoft takes the position
that they won't support features in C that can't go into
C++.  After all, today, most compilers for C are really C++
compilers with some features turned off.)

				John Nagle

[toc] | [prev] | [next] | [standalone]

#1613

On 08/27/2012 10:36 PM, John Nagle wrote:
...
>     Another problem is that C++ collection classes don't have efficient
> subscript checking.  Some implementations do offer subscript checking
> of collection classes. But because the check is just a template
> expansion, it has to be done where the template says to do it - on
> every reference.  The compiler doesn't have the authority to haul
> the check out of the loop when possible and do it once at loop
> entrance.

Sure it does - the as-if rule always applies. If the compiler can be
certain that a check will be passed, it can always eliminate that check.

> Example:
> 
> 	std::array<int,100> tab;
> 	for (int i=0; i<200; i++) { tab[i] = 0; }

Shouldn't that be tab.at(i), in order to invoke subscript checking?
Personally, I'd use std::fill_n(tab.begin(), 200, 0);
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#1614

On 8/27/2012 7:54 PM, James Kuyper wrote:
> On 08/27/2012 10:36 PM, John Nagle wrote:
> ...
>>     Another problem is that C++ collection classes don't have efficient
>> subscript checking.  Some implementations do offer subscript checking
>> of collection classes. But because the check is just a template
>> expansion, it has to be done where the template says to do it - on
>> every reference.  The compiler doesn't have the authority to haul
>> the check out of the loop when possible and do it once at loop
>> entrance.
> 
> Sure it does - the as-if rule always applies. If the compiler can be
> certain that a check will be passed, it can always eliminate that check.

   Efficient optimization requires that the problem be reported early.
It's often possible to hoist subscript checks to the top of a loop.
But then, the check will fail before the first iteration, even if
many iterations could be completed before overflow.  Potentially,
each iteration could call a function which might potentially do
a longjmp and escape the loop before a subscript error occurred.
To allow this optimization, the compiler must have permission
to report a constraint violation as soon as it becomes
inevitable.  And "inevitable" must exclude exiting the
loop via longjmp, exit, abort, or uncaught signal, which
are events that may be triggered in another translation
unit the compiler cannot currently see.  I discuss that in my
paper on safe arrays.

   Thus, a compiler must know that constraint checks get
special handling to do them efficiently.

   There are some papers on this subject. This one has a
good list of references:

	http://www.classes.cs.uchicago.edu/archive/2004/fall/32630-1/papers/p270-kolte.pdf

Most of the existing work is for FORTRAN, Pascal, or COBOL.
I'm unaware of any C implementation with optimized subscript
checking.

>> Example:
>>
>> 	std::array<int,100> tab;
>> 	for (int i=0; i<200; i++) { tab[i] = 0; }
> 
> Shouldn't that be tab.at(i), in order to invoke subscript checking?
> Personally, I'd use std::fill_n(tab.begin(), 200, 0);

   Oh, the subscript form in C++ collection classes doesn't have
subscript checking.  Right. This sort of thing is why the compiler
should optimize checking, so you can afford to check all the time.
This reinforces my point.

				John Nagle

[toc] | [prev] | [next] | [standalone]

#6446

On Saturday, August 18, 2012 at 5:33:19 AM UTC-7, jacob navia wrote:

> In my implementation [of VLA parameters] I had a REAL sizeof that will return the actual 
> size. I was told to replace it, but I think I will not.

An implementation of sizeof that returns something other than the size of the pointer when given a VLA parameter violates the fundamental rules of C pointer arithmetic.  You cannot pass an array to a function in C, except by wrapping a struct or union around it.  Confusingly, C allows you to write function parameters that -appear- to be arrays, e.g.

    int main(int argc, char *argv[])    // misleading declaration: argv is NOT an array; rather, it's merely a vector

The compiler knows that an array cannot be passed directly to a function because any time an expression of type array of X appears in expression context (e.g. the actual parameter in a function call), the compiler promotes the type to pointer to X by taking the address of the first element.  So when the compiler sees an array type in a parameter list, it silently re-writes it to what it really is:

    int main(int argc, char **argv)

This is a throw-back to pre-ANSI C when the compiler would also silently re-write formal parameters of type "char" and "short" to "int" and "float" to "double".  It's too bad ANSI C didn't disallow writing parameters that appear incorrectly as array types, but the fact that they didn't made VLA parameters possible.

In my example, regardless of which declaration I use for argv, argv is a pointer in every way.  For example, we can say ++argv.  We wouldn't be able to increment it if it were an array.

The VLA parameter is similarly silently rewritten as a pointer type, and just as above, when we have:

    void f(int n, int a[n])

We can say ++a inside the function.

[toc] | [prev] | [next] | [standalone]

#6447

"pdx_scooter@yahoo.com" <pdx_scooter@yahoo.com> writes:
> On Saturday, August 18, 2012 at 5:33:19 AM UTC-7, jacob navia wrote:
>
>> In my implementation [of VLA parameters] I had a REAL sizeof that will return the actual 
>> size. I was told to replace it, but I think I will not.
>
> An implementation of sizeof that returns something other than the size
> of the pointer when given a VLA parameter violates the fundamental
> rules of C pointer arithmetic.
[...]

Agreed.

Are you aware that you just replied to an article that was posted 10
years ago?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#6471

> void f(int n, int a[n]) 
> 
> We can say ++a inside the function.

There is some debate if it is an actual VLA type. The standard requires to transform the declaration of `int a[n]` to `int* a`.
To my understanding, the original VLA type is erased during at function's *definition* and its top-level size expression should not never be evaluated.
The situation is different while passing a pointer to an array:

```
void f(int n, int (*a)[n]) { ... }
```

Now, `n` must be evaluated at every invocation of the function.

[toc] | [prev] | [next] | [standalone]

#1525

On 8/17/2012 6:42 PM, Keith Thompson wrote:
> C99 introduced VLAs (variable length arrays); a conforming C99
> compiler *must* implement them.
>
> C11 made them an optional feature; a conforming C11 compiler can
> fail to implement VLAs if it predefines the macro __STDC_NO_VLA__.
>
> BTW, a positive name would have been more
> convenient ("#ifdef __STDC_VLA__" is more readable than
> "#ifndef __STDC_NO_VLA__"), but I suppose it's too late to
> change that.

     That choice, at least, is clear: Since a C99 compiler is not
under any obligation to define a macro with this indication, a
test

	#if __STDC_VLA__

... would come up "false" on a fully-conforming C99 implementation
*with* VLA support.  That is, a compiler that conformed to C99 and
had passed any number of certification tests could suddenly become
non-conforming by fiat were __STDC_VLA__ added, ex post facto, to
the conformance requirement.

> Why did C11 make VLAs optional?

     More generally, why did C11 abandon the principle expressed
in the Rationale:

	By defining both conforming hosted and conforming
	Beyond this two-level scheme, no additional subsetting
	is defined for C, since the C89 Committee felt strongly
	that too many levels dilutes the effectiveness of a
	standard.

?  6.10.8.3 introduces one two three four five six seven eight
"conditional feature macros," which along with the hosted vs.
freestanding choice gives

                F I V E   H U N D R E D   T W E L V E

different language subsets, all entitled to call themselves
"fully conforming Standard-compliant dyed-in-the-wool accept-
no-substitutes JenYouWine C."

     Embrace, extend, extinguish -- and it's an inside job!

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#1526

On 8/17/2012 3:42 PM, Keith Thompson wrote:
> C99 introduced VLAs (variable length arrays); a conforming C99
> compiler *must* implement them.
> 
> C11 made them an optional feature; a conforming C11 compiler can
> fail to implement VLAs if it predefines the macro __STDC_NO_VLA__.
> 
> BTW, a positive name would have been more
> convenient ("#ifdef __STDC_VLA__" is more readable than
> "#ifndef __STDC_NO_VLA__"), but I suppose it's too late to
> change that.
> 
> Why did C11 make VLAs optional?
> 
> The obvious answer would be to cater to some compiler implementer
> that would be willing to implement C11 *without* VLAs, but considers
> implementing C11 *with* VLAs to be too burdensome.  

   Microsoft has stated their position:

"We have added support for C-99 features (variadic macros, long long)
and we really do listen to our customers (both big and small) and the
overwhelming feedback we get is to focus on C++. Even one of our largest
and most focal group of C customers - developers of device drivers - are
now asking us to make C++ more friendly to the device driver space.

Having said that: 2 C-99 features (VLA's and the ability to mix
declarations and statements) are on the wish list for the next release -
but it all depends on the resources we can dedicate to the compiler -
and there are a lot of other C++-0x features that users want us to support."

   Jonathan Caves - Visual C++ Compiler Team

    (ref:
http://social.msdn.microsoft.com/Forums/en-US/vcprerelease/thread/6099f453-db2c-49c3-b59a-b799c379cebb)

				John Nagle

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.std.c

csiph-web