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 1 of 2  [1] 2  Next page →

#1521 — Why are VLAs optional in C11?

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.  Note that full
support for C99 was notoriously slow; were VLAs part of the reason
for that?

Was this the reason for making VLAs optional?  If so, what compiler
implementer supported, or would have supported, either C99 or C11
*without* VLAs?

The two non-examples I'm most familiar with are gcc (which does
support VLAs and presumably will continue to do so) and Microsoft
(which has expressed a lack of interest in supporting anything past
C90 *at all*, except perhaps for some features that are also in C++).

Or is there another rationale?

-- 
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] | [next] | [standalone]

#1523

Am 18.08.2012 00:42, schrieb Keith Thompson:
> Why did C11 make VLAs optional?

I vaguely remember reading that the motif was similar as for the
complex data types. There are platforms with specialized compilers
that really don't need VLA (embedded stuff comes into mind). They
shouldn't lag behind in addopting the core features of modern C. The
same strategy has been followed for other new features such as
threads, for example.

Up to now, there was the main difference in hosted and standalone
environments. This classification was perhaps to coarse. With C11, C
becomes a toolbox with optional modules that is build arround some
sort of core language.

It is really unfortunate, that we don't have the rationale document
for C11, yet.

Jens

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

#1524

Jens Gustedt <jens.gustedt@loria.fr> writes:
> Am 18.08.2012 00:42, schrieb Keith Thompson:
>> Why did C11 make VLAs optional?
>
> I vaguely remember reading that the motif was similar as for the
> complex data types. There are platforms with specialized compilers
> that really don't need VLA (embedded stuff comes into mind). They
> shouldn't lag behind in addopting the core features of modern C. The
> same strategy has been followed for other new features such as
> threads, for example.

Then let me add to my previous question: Would it have been reasonable
to make VLAs mandatory for hosted implementations but optional for
freestanding implementations?

[...]

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

#1531

Am 18.08.2012 01:23, schrieb Keith Thompson:
> Jens Gustedt <jens.gustedt@loria.fr> writes:
>> Am 18.08.2012 00:42, schrieb Keith Thompson:
>>> Why did C11 make VLAs optional?
>>
>> I vaguely remember reading that the motif was similar as for the
>> complex data types. There are platforms with specialized compilers
>> that really don't need VLA (embedded stuff comes into mind). They
>> shouldn't lag behind in addopting the core features of modern C. The
>> same strategy has been followed for other new features such as
>> threads, for example.
> 
> Then let me add to my previous question: Would it have been reasonable
> to make VLAs mandatory for hosted implementations but optional for
> freestanding implementations?

Probably not. There will be more and more borderline architectures in
the future that combine aspects of hosted and freestanding
environments. Best example are platforms with GPU. E.g OpenCL is
supposed to implement most elements of C99, but not VLA. It combines
compilation on the host environment and on the GPU device.

And programming for devices will become more specialized. For a device
like GPU that does parallel geometric processing you might want
complex numbers (so you'd support that option), atomics and threads
(maybe the C11 can be made compatible with their lowlevel threads) but
you don't want VLA on the device.

The programming model would be very close of what nowadays is a hosted
environment, but without VLA.

Jens

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

#1527

On 8/17/2012 4:19 PM, Jens Gustedt wrote:
> Am 18.08.2012 00:42, schrieb Keith Thompson:
>> Why did C11 make VLAs optional?
...
> It is really unfortunate, that we don't have the rationale document
> for C11, yet.

   True.  Here are some of the known problems with VLAs:

- Putting arbitrarily large arrays on the stack causes trouble
in multithreaded programs in implementations where stack growth
is bounded.

- There's no way to recover from an out-of-memory condition when
allocating a VLA.

- Microsoft declines to support them.

- VLAs aren't used much.  There appear to be only three in
Google Code, and no VLA parameters. The Linux kernel had one,
but it was taken out because there was no way to handle an
out of space condition.  (If anyone can find an example of
a VLA parameter in publicly visible production code, please
let me know.)

- The semantics of VLA parameters is painful.  They're
automatically reduced to pointers, with the length information
lost.  "sizeof" returns the size of a pointer.

- Prototypes of functions with VLA parameters do not have
to exactly match the function definition. This is
incompatible with C++ style linkage and C++ function
overloading, preventing the extension of this feature
into C++.

			John Nagle

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

#1528

In article <k0n48g$tsc$1@dont-email.me>, John Nagle  <nagle@animats.com> wrote:
>out of space condition.  (If anyone can find an example of
>a VLA parameter in publicly visible production code, please
>let me know.)

MPlayer has a few.

svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer

Examples:

command.c:1304
    if (mpctx->demuxer->type == DEMUXER_TYPE_TV) {
        int l = strlen(prop->name);
        char tv_prop[3 + l + 1];
        sprintf(tv_prop, "tv_%s", prop->name);
        return mp_property_do(tv_prop, action, arg, mpctx);
    }

ffmpeg/libavutil/pca.c:73
int ff_pca(PCA *pca, double *eigenvector, double *eigenvalue){
    int i, j, pass;
    int k=0;
    const int n= pca->n;
    double z[n];

input/input.c (2 separate locations) (end and iter are local variables)
	char name[end-iter+1];
	strncpy(name,iter,end-iter);
	name[end-iter] = '\0';

libmenu/menu.c:749 (w and h are function parameters)
    int stride = (w+7)&(~7); // round to 8
    char pic[stride*h],pic_alpha[stride*h];

libmpcodecs/ad_twin.c:507
        float out[priv->framesize*sh_audio->channels];

libmpdemux/demux_mov.c:2038
		    int len=trak->samples[i].size;
		    char buf[len];

-- 
Alan Curry

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

#1529

On 8/17/2012 10:34 PM, Alan Curry wrote:
> In article <k0n48g$tsc$1@dont-email.me>, John Nagle  <nagle@animats.com> wrote:
>> out of space condition.  (If anyone can find an example of
>> a VLA parameter in publicly visible production code, please
>> let me know.)
> 
> MPlayer has a few.
...

  Those are all local VLAs.  A VLA parameter looks like

	void fn(size_t n, double mat[n][n])
	{
	}

Seen any of those, anyone?

				John Nagle

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

#1532

In article <k0nbeb$ojg$1@dont-email.me>, John Nagle  <nagle@animats.com> wrote:
>On 8/17/2012 10:34 PM, Alan Curry wrote:
>> In article <k0n48g$tsc$1@dont-email.me>, John Nagle 
><nagle@animats.com> wrote:
>>> out of space condition.  (If anyone can find an example of
>>> a VLA parameter in publicly visible production code, please
>>> let me know.)
>> 
>> MPlayer has a few.
>...
>
>  Those are all local VLAs.  A VLA parameter looks like

Oops. I misread the question.

>
>	void fn(size_t n, double mat[n][n])
>	{
>	}
>
>Seen any of those, anyone?

None in any code I have nearby. If anyone wants to try my search,

find . -name '*.c' -exec egrep \
  '^[^ 	/#].*\<([a-zA-Z_][a-zA-Z0-9_]*)\>,.*\[[^]]*\<\1\>' \
  /dev/null '{}' +

(there's a space and a tab in the initial negated character class)

gave only 8 false positives out of 20 million lines searched.

-- 
Alan Curry

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

#1537

On 8/18/2012 1:29 AM, Alan Curry wrote:
> In article <k0nbeb$ojg$1@dont-email.me>, John Nagle  <nagle@animats.com> wrote:
>> On 8/17/2012 10:34 PM, Alan Curry wrote:
>>> In article <k0n48g$tsc$1@dont-email.me>, John Nagle 
>> <nagle@animats.com> wrote:
>>>> out of space condition.  (If anyone can find an example of
>>>> a VLA parameter in publicly visible production code, please
>>>> let me know.)
>>>
>>> MPlayer has a few.
>> ...
>>
>>  Those are all local VLAs.  A VLA parameter looks like
> 
> Oops. I misread the question.
> 
>>
>> 	void fn(size_t n, double mat[n][n])
>> 	{
>> 	}
>>
>> Seen any of those, anyone?
> 
> None in any code I have nearby. If anyone wants to try my search,
> 
> find . -name '*.c' -exec egrep \
>   '^[^ 	/#].*\<([a-zA-Z_][a-zA-Z0-9_]*)\>,.*\[[^]]*\<\1\>' \
>   /dev/null '{}' +
> 
> (there's a space and a tab in the initial negated character class)
> 
> gave only 8 false positives out of 20 million lines searched.

    Thanks.   Can anyone else try it on large volumes of
code they have?  So far, no one has been able to find even
one VLA parameter in production code anywhere.  I'd really
like to find at least one.

    I've tried Google Code Search (it's still live, but only
covers code stored in Google Code), and found no VLA parameters.
VLA arrays showed up in one game (once), the Erlang library
(twice), and the GCC test suite (once).  There was one VLA
in the Linux kernel, but it was removed as a risk to
kernel stack overflow.

    (Krugle's and Ohloh also have code search tools on line,
but neither allows a regular expression, so they're not
useful here.)


					John Nagle

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

#1542

John Nagle <nagle@animats.com> wrote:
> On 8/18/2012 1:29 AM, Alan Curry wrote:
> > [ how to look for VLAs in prototypes ]

>     Thanks.   Can anyone else try it on large volumes of
> code they have?  So far, no one has been able to find even
> one VLA parameter in production code anywhere.  I'd really
> like to find at least one.

I don't have to search.  I had to write some numerical code at work
two years ago and I used C99 features, VLAs among them, just to
see if they are any good.  Work for hire, proprietary, can't show
it, sorry.

The VLAs are *extraordinarily* useful.  First as a replacement
for alloca().  Second, to convert between flat and multidimensional
arrays.

    float flat[3*nx*ny*nz];
    float (*structured)[ny][nz][3]= (void *)flat;
    float *other_flat= &structured[0][0][0][0];

That sort of thing.  And, as you ask, in function prototypes.

    int fou(size_t n, size_t m, float A[/* n */][m]);

(Not a VLA parameter, since there are no array parameters,
but very much a pointer to VLA parameter.)

-- 
pa at panix dot com

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

#1538

On 2012-08-18, Alan Curry <pacman@kosh.dhis.org> wrote:
> None in any code I have nearby. If anyone wants to try my search,
>
> find . -name '*.c' -exec egrep \
>   '^[^ 	/#].*\<([a-zA-Z_][a-zA-Z0-9_]*)\>,.*\[[^]]*\<\1\>' \
>   /dev/null '{}' +
>
> (there's a space and a tab in the initial negated character class)
>
> gave only 8 false positives out of 20 million lines searched.

There may be false negatives.
The find command finds

  void g(size_t n, /* ... , */ double a[n])

but not

  void g(size_t n,
         /* ... , */
         double a[n])

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

#1530

Am 18.08.2012 06:04, schrieb John Nagle:
>    True.  Here are some of the known problems with VLAs:
> 

-- snip --

> - The semantics of VLA parameters is painful.

true, but you yourself with your proposal of reference show a way out
of that, that would make them bearable

>  They're
> automatically reduced to pointers, with the length information
> lost.  "sizeof" returns the size of a pointer.

technically not true, or only half the truth

only the size for innermost dimension is lost, the other dimensions
come accross and are perfectly accessible through sizeof. The first
dimension (as a sizeof expression) is usually not needed for the
computation inside the function.

And the reason that this dimension is lost is not the fault of VLA,
this dimension is lost for all "array" parameters.

Most disadvantages of VLA disappear if you just use pointers to VLA.

double (*A)[n][m] = malloc(sizeof(double[n][m]));

is easy to read, keeps track of both dimensions, is checkable for
allocation problems and is in no risk of smashing the stack.

If you want to introduce references à-la C++ to make the *use* of them
easier, this would be a strong argument for them.

+++

I have to observe that you reply here in this thread and not in the
other one where I gave you a detailed analysis of your proposal and
where I basically think I have proven that with your proposal you are
doing VLA (or more precisely VM types) anyhow.

Since this is already the second time, should I conclude that you are
more interested in VLA-bashing than in taking your own proposal
forward?

Jens

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

#1533

John Nagle <nagle@animats.com> writes:
[...]
> - The semantics of VLA parameters is painful.  They're
> automatically reduced to pointers, with the length information
> lost.  "sizeof" returns the size of a pointer.

That's no different from non-VLA arrays.

[...]

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

#1535

Le 18/08/12 06:04, John Nagle a écrit :
> On 8/17/2012 4:19 PM, Jens Gustedt wrote:
>> Am 18.08.2012 00:42, schrieb Keith Thompson:
>>> Why did C11 make VLAs optional?
> ...
>> It is really unfortunate, that we don't have the rationale document
>> for C11, yet.
>
>     True.  Here are some of the known problems with VLAs:
>
> - Putting arbitrarily large arrays on the stack causes trouble
> in multithreaded programs in implementations where stack growth
> is bounded.
>

This is not specific to VLAs. In general VLAs REDUCE stack growth.

Without VLAs you write:

#define MAXELEMENTS 512

int fn(void)
{
	int table[MAXELEMENT];
}


MOST cases will be 10-20, some cases it would go to 100, and the
programmer, careful to avoid overflows decides 512.

With VLAs in most cases you will just use 10-20 elements, not one more 
as it is NEEDED. There is no need for an arbitrary maximum.

Under windows, the stack can start with 1MB, if I remember correctly.


> - There's no way to recover from an out-of-memory condition when
> allocating a VLA.
>

Neither is possible to recover when you write:

int fn(void)
{
	int foo;
}


> - Microsoft declines to support them.
>

o Microsoft declines to support mixing declarations and code.

o Microsoft did not introduce "long long" into their compiler line until
    2009, using before its __int64 keyword.

o Microsoft doesn't support the standard C library emitting a warning
   at each call of most library functions "this function is deprecated"

o Microsoft doesn't like the C language at all. Let's close shop then.
   Microsoft may have a point. There is no need for a C committee if we
   have Microsoft.

   WHAT?

   You are again MICROSOFT, the software giant? You must be nuts.

> - VLAs aren't used much.  There appear to be only three in
> Google Code, and no VLA parameters. The Linux kernel had one,
> but it was taken out because there was no way to handle an
> out of space condition.  (If anyone can find an example of
> a VLA parameter in publicly visible production code, please
> let me know.)
>

Just one example:

struct foo;

This is an opaque definition of a data type, published by a library
that keeps the internals hidden.

problem: You can't make a local variable of type "foo" since the size
isn't know. If the library provides a library function

size_t SizeofFoo(void);

You can declare a local variable of type foo with

int FunctionThatUsesAFoo(void)
{
	char myFooBuf[SizeofFoo()];
	struct foo *myFoo = &myFooBuf;
}

This is VERY important for libraries that hide their internals but want 
to allow local variables with their types saving one expensive call to
malloc().

> - The semantics of VLA parameters is painful.  They're
> automatically reduced to pointers, with the length information
> lost.  "sizeof" returns the size of a pointer.
>

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

> - Prototypes of functions with VLA parameters do not have
> to exactly match the function definition. This is
> incompatible with C++ style linkage and C++ function
> overloading, preventing the extension of this feature
> into C++.


I think that adding new features to C++ is a REALLY BAD IDEA (tm).

One of the useful things of VLAs is that they are incompatible with C++
then.

jacob

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

#1536

On 2012-08-18, jacob navia <jacob@spamsink.net> wrote:
> struct foo;
>
> This is an opaque definition of a data type, published by a library
> that keeps the internals hidden.
>
> problem: You can't make a local variable of type "foo" since the size
> isn't know. If the library provides a library function
>
> size_t SizeofFoo(void);
>
> You can declare a local variable of type foo with
>
> int FunctionThatUsesAFoo(void)
> {
> 	char myFooBuf[SizeofFoo()];
> 	struct foo *myFoo = &myFooBuf;
> }

Caveat: there can be an alignment mismatch.

> This is VERY important for libraries that hide their internals but want 
> to allow local variables with their types saving one expensive call to
> malloc().
>
>> - The semantics of VLA parameters is painful.  They're
>> automatically reduced to pointers, with the length information
>> lost.  "sizeof" returns the size of a pointer.
>
> In my implementation I had a REAL sizeof that will return the actual
> size.

The actual size of what? If, inside the function body, the parameter
has been reduced to a pointer, then applying sizeof to such a
pointer should, of course, return the size of the pointer.

If your sizeof, applied to a pointer, does not yield the size of the
pointer, it is a broken sizeof.

Or is it the case that you do not let the array decay to a pointer,
so that sizeof is applied to an array?

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

#1539

jacob navia <jacob@spamsink.net> writes:
> Le 18/08/12 06:04, John Nagle a écrit :
>> On 8/17/2012 4:19 PM, Jens Gustedt wrote:
>>> Am 18.08.2012 00:42, schrieb Keith Thompson:
>>>> Why did C11 make VLAs optional?
>> ...
>>> It is really unfortunate, that we don't have the rationale document
>>> for C11, yet.
>>
>>     True.  Here are some of the known problems with VLAs:
>>
>> - Putting arbitrarily large arrays on the stack causes trouble
>> in multithreaded programs in implementations where stack growth
>> is bounded.
>>
>
> This is not specific to VLAs. In general VLAs REDUCE stack growth.
>
> Without VLAs you write:
>
> #define MAXELEMENTS 512
>
> int fn(void)
> {
> 	int table[MAXELEMENT];
> }
>
>
> MOST cases will be 10-20, some cases it would go to 100, and the
> programmer, careful to avoid overflows decides 512.
>
> With VLAs in most cases you will just use 10-20 elements, not one more 
> as it is NEEDED. There is no need for an arbitrary maximum.

Without VLAs, I'd probably use malloc().

VLAs can either increase or reduce stack growth, depending on how you
use them.

[...]

>> - Microsoft declines to support them.
[...]
> o Microsoft doesn't like the C language at all. Let's close shop then.
>    Microsoft may have a point. There is no need for a C committee if we
>    have Microsoft.
>
>    WHAT?
>
>    You are again MICROSOFT, the software giant? You must be nuts.

This isn't about anybody being against anybody.  Microsoft exists and
is significant.  There are other C compilers for Windows, but using
one of them may not be an option for some projects (for example,
management might insist on using only Microsoft development tools).
Conclusion: *some* C programmers (those who need to use Microsoft
C compilers) are unable to use most C99 and C11 features.  I don't
like it any more than you do, but sarcasm isn't going to change it --
and it may be quite relevant to this discussion.

>> - VLAs aren't used much.  There appear to be only three in
>> Google Code, and no VLA parameters. The Linux kernel had one,
>> but it was taken out because there was no way to handle an
>> out of space condition.  (If anyone can find an example of
>> a VLA parameter in publicly visible production code, please
>> let me know.)
>>
>
> Just one example:
>
> struct foo;
>
> This is an opaque definition of a data type, published by a library
> that keeps the internals hidden.
>
> problem: You can't make a local variable of type "foo" since the size
> isn't know. If the library provides a library function
>
> size_t SizeofFoo(void);
>
> You can declare a local variable of type foo with
>
> int FunctionThatUsesAFoo(void)
> {
> 	char myFooBuf[SizeofFoo()];
> 	struct foo *myFoo = &myFooBuf;
> }

Using malloc instead of an automatic char array would avoid alignment
problems.
[...]

>> - The semantics of VLA parameters is painful.  They're
>> automatically reduced to pointers, with the length information
>> lost.  "sizeof" returns the size of a pointer.
>>
>
> In my implementation I had a REAL sizeof that will return the actual
> size. I was told to replace it, but I think I will not.

You should at least fix it.  With the version of lcc-win64 I installed
on June 9, this program:

    #include <stdio.h>
    
    void func(int n, int param[n]) {
        printf("sizeof param = %zu\n", sizeof param);
    }
    
    int main(void) {
        enum { LEN = 10 };
        int obj[LEN];
        printf("sizeof obj   = %zu\n", sizeof obj);
        func(LEN, obj);
        return 0;
    }
    
produces this output:

    sizeof obj   = 40
    sizeof param = 10

A conforming C99 or C11 compiler must compute `sizeof param` to
be the same as `sizeof (int*)`, since param is a pointer.  If,
as you suggest, `sizeof param` should instead be the size of the
argument, then it should be 40 rather than 10.  If you intend it to
be the number of elements rather than the size in bytes, I suggest
introducing a new implementation-defined operator, perhaps something
like `_Lengthof`.  (It's between you and your customers to decide
whether lcc-win needs to be conforming.)

(Incidentally, `...` is the Markdown syntax for code samples; see
<http://en.wikipedia.org/wiki/Markdown>.  I think I'm going to start
using it here.)

[...]

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

#1540

Le 18/08/12 22:48, Keith Thompson a écrit :

I wrote:
>> o Microsoft doesn't like the C language at all. Let's close shop then.
>> >    Microsoft may have a point. There is no need for a C committee if we
>> >    have Microsoft.
>> >
>> >    WHAT?
>> >
>> >    You are again MICROSOFT, the software giant? You must be nuts.

Then Mr Thompson answered:

> This isn't about anybody being against anybody.

That's your opinion. I am definitely against the policy of microsoft
of degrading the support of standard C and against their opinion
that is they that rule what windows users should use as a language.

> Microsoft exists

I am not denying that... :-)

> and
> is significant.

I am just denying that. 640K should be OK for everyone said someone
years ago. No, that opinion wasn't significant even if microsoft was
a software giant then. For me having a lot of money doesn't make you 
right, sorry. You snipped all other arguments (declarations at any
place, making the whole standard C library "deprecated") how convenient
for you.

> There are other C compilers for Windows, but using
> one of them may not be an option for some projects (for example,
> management might insist on using only Microsoft development tools).

And so what?

If management insists on using "MICROSOFT ONLY" why should be
declare that ALL OTHERS even those users that do not use Microsoft
(Apple programmers, iOS programmers, Android programmers,
Sun programmers, and a VERY long list) should have a language
that is defined by Microsoft?

> Conclusion:*some*  C programmers (those who need to use Microsoft
> C compilers) are unable to use most C99 and C11 features.

Life is tough when you have to use Microsoft, I know. But if life
is tough for people using Microsoft, at least do not generalize and
make it tough for everyone!

> I don't
> like it any more than you do, but sarcasm isn't going to change it --
> and it may be quite relevant to this discussion.
>

I believe that there is nothing about Microsoft that is relevant here
since WHATEVER WE DO Microsoft will NOT follow it since it has given
up supporting C as a language. That is a fact, that doesn't change if
they say somewhere in a blog that if they would have more resources
they *could* implement some standard C feature from a standard that is
12 years old.

The committee tried to please Microsoft and declared VLA's optional.

Great.

The result?

Has Microsoft changed anything about its C99 support?

Please, let's get real.

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

#1541

jacob navia <jacob@spamsink.net> writes:
> Le 18/08/12 22:48, Keith Thompson a écrit :
> I wrote:
>>> o Microsoft doesn't like the C language at all. Let's close shop then.
>>> >    Microsoft may have a point. There is no need for a C committee if we
>>> >    have Microsoft.
>>> >
>>> >    WHAT?
>>> >
>>> >    You are again MICROSOFT, the software giant? You must be nuts.
>
> Then Mr Thompson answered:
>
>> This isn't about anybody being against anybody.
>
> That's your opinion. I am definitely against the policy of microsoft
> of degrading the support of standard C and against their opinion
> that is they that rule what windows users should use as a language.

I'm not disputing your opinion.  I actually agree with much of it.
I'm suggesting that *this discussion* isn't about being for or
against Microsoft policies.

>> Microsoft exists
>
> I am not denying that... :-)
>
>> and
>> is significant.
>
> I am just denying that. 640K should be OK for everyone said someone
> years ago. No, that opinion wasn't significant even if microsoft was
> a software giant then. For me having a lot of money doesn't make you 
> right, sorry. You snipped all other arguments (declarations at any
> place, making the whole standard C library "deprecated") how convenient
> for you.

I snipped things that I wasn't commenting on, either because I agreed
with them or because I just didn't have anything to say about them.
Inferring some ulterior motive from that is a mistake.

Are you under the impression that I *approve* of Microsoft not
supporting mixed declarations and statements in C and deprecrating
some functions in the standard C library?  If so, please indicate
when and where I said that so I can clarify it.

The fact that you and I both happen to disagree with certain
Microsoft policies does not imply that Microsoft is insignificant.

For the record, I would prefer it if Microsoft would fully support
C99 in its C compiler, and fully support C11 as soon as practical.
But since I don't run Microsoft, and am only barely a Microsoft user,
I don't get a vote.  They make decisions for both technical and
financial reasons; they've made the business decision to concentrate
their resources on C++ rather than C.

Please stop mistaking my statement about what they've done for
agreement with it.

>> There are other C compilers for Windows, but using
>> one of them may not be an option for some projects (for example,
>> management might insist on using only Microsoft development tools).
>
> And so what?
>
> If management insists on using "MICROSOFT ONLY" why should be
> declare that ALL OTHERS even those users that do not use Microsoft
> (Apple programmers, iOS programmers, Android programmers,
> Sun programmers, and a VERY long list) should have a language
> that is defined by Microsoft?

Where on Earth are you getting this?

I did not say or imply that all users should be limited to what
Microsoft supports.  What I said, which you actually quoted, was:

>> Conclusion:*some*  C programmers (those who need to use Microsoft
>> C compilers) are unable to use most C99 and C11 features.

*Some* C programmers.  Those who *need* to use Microsoft C compilers.
What is unclear about that?

(At my previous job, we used Microsoft's compiler.  Using a different
compiler was not an option, at least not for me.  It was C++ and C#,
not C, so it's not *entirely* relevant, but there are programmers
who have no choice but to use Microsoft development environments.
This is not a value judgement, it is a statement of fact.)

> Life is tough when you have to use Microsoft, I know. But if life
> is tough for people using Microsoft, at least do not generalize and
> make it tough for everyone!

I don't.

>> I don't
>> like it any more than you do, but sarcasm isn't going to change it --
>> and it may be quite relevant to this discussion.

[snip]

> The committee tried to please Microsoft and declared VLA's optional.

Has someone on the committee actually said that it was done to please
Microsoft?  If so, I missed it -- which is exactly why I started this
discussion.  My hope is that someone *on the C committee* will explain
why VLAs were made optional in C11.

[snip]

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?

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

#1543

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.

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

#1544

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?)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web