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

Groups > comp.lang.c > #155053 > unrolled thread

Microsoft Will now support C11 and C17 standard!!!!!!!!!!

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

Contents

  Microsoft Will now support C11 and C17 standard!!!!!!!!!! Real Troll <real.troll@trolls.com> - 2020-09-16 04:55 -1000
    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2020-09-16 15:23 +0000
    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-16 17:49 +0200
      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-16 12:53 -0700
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! scott@slp53.sl.home (Scott Lurndal) - 2020-09-16 19:58 +0000
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! doctor@doctor.nl2k.ab.ca (The Doctor) - 2020-09-16 22:31 +0000
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-16 21:10 -0700
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-17 12:28 +0200
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-17 17:00 -0700
      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Anton Shepelev <anton.txt@gmail.com> - 2020-09-17 02:13 +0300
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-17 07:44 +0200
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Manfred <noname@add.invalid> - 2020-09-18 22:08 +0200
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-19 06:54 +0200
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! gazelle@shell.xmission.com (Kenny McCormack) - 2020-09-17 11:05 +0000
      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2020-09-20 00:41 -0700
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-20 11:03 +0200
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Manfred <noname@add.invalid> - 2020-09-20 15:51 +0200
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-09-20 07:41 -0700
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! scott@slp53.sl.home (Scott Lurndal) - 2020-09-20 14:41 +0000
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! scott@slp53.sl.home (Scott Lurndal) - 2020-09-20 14:39 +0000
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-20 16:55 +0200
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! David Brown <david.brown@hesbynett.no> - 2020-09-20 17:10 +0200
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-20 18:14 +0200
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! already5chosen@yahoo.com - 2020-09-20 10:44 -0700
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! David Brown <david.brown@hesbynett.no> - 2020-09-20 21:14 +0200
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! already5chosen@yahoo.com - 2020-09-20 15:40 -0700
                    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! David Brown <david.brown@hesbynett.no> - 2020-09-21 08:34 +0200
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-20 12:55 -0500
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! David Brown <david.brown@hesbynett.no> - 2020-09-20 21:16 +0200
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-20 20:40 +0100
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-20 19:39 -0500
                    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! David Brown <david.brown@hesbynett.no> - 2020-09-21 09:20 +0200
                      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-21 11:25 +0100
                        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! David Brown <david.brown@hesbynett.no> - 2020-09-21 14:27 +0200
                          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-21 22:24 -0700
                            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-22 08:49 +0200
                        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Manfred <noname@add.invalid> - 2020-09-21 15:09 +0200
                    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Manfred <noname@add.invalid> - 2020-09-21 15:26 +0200
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-21 11:40 +0100
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! David Brown <david.brown@hesbynett.no> - 2020-09-21 14:48 +0200
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-09-21 06:03 -0700
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-21 16:44 +0100
                    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-21 12:06 -0500
                      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-21 20:03 +0100
                        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-21 18:33 -0500
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-21 11:09 -0500
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-09-20 16:13 +0000
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-20 09:53 -0700
    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-16 12:51 -0700
      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-16 21:00 +0100
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Thiago Adams <thiago.adams@gmail.com> - 2020-09-17 05:28 -0700
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-17 17:03 -0700
    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Leo <usenet@gkbrk.com> - 2020-09-17 16:45 +0300
      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-17 16:59 +0200
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! gazelle@shell.xmission.com (Kenny McCormack) - 2020-09-17 19:36 +0000
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-17 17:08 -0700
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-18 06:11 +0200
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-17 22:38 -0700
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! gazelle@shell.xmission.com (Kenny McCormack) - 2020-09-18 10:12 +0000
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-18 12:26 +0200
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-18 19:18 -0700
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-18 19:19 -0700
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-19 04:21 +0200
                    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-18 19:28 -0700
      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-17 16:53 +0100
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! already5chosen@yahoo.com - 2020-09-17 16:28 -0700
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-18 00:46 +0100
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! already5chosen@yahoo.com - 2020-09-18 07:31 -0700
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-18 17:53 -0500
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-19 01:02 +0100
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-18 17:34 -0700
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-18 20:57 -0500
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-18 23:43 -0700
                    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-19 11:01 +0100
                      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-19 13:33 -0500
                      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-11-29 00:23 -0800
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-18 20:53 -0400
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-18 21:38 -0500
                    Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-18 22:50 -0400
                      Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-18 20:09 -0700
                        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! BGB <cr88192@gmail.com> - 2020-09-18 23:52 -0500
                        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-18 23:42 -0700
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-19 06:43 +0200
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Manfred <noname@add.invalid> - 2020-09-18 20:32 +0200
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-18 20:06 +0100
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Manfred <noname@add.invalid> - 2020-09-18 22:04 +0200
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-18 21:05 +0100
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-18 23:05 +0100
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-18 23:14 +0100
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-18 14:09 -0700
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-18 22:33 +0100
        Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-18 23:20 -0700
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-18 23:44 -0700
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-18 23:59 -0700
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-09-19 11:32 +0000
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-19 07:37 -0700
          Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-19 12:43 +0100
            Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-19 13:52 +0100
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-19 13:58 +0100
              Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-19 19:18 +0100
                Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Bart <bc@freeuk.com> - 2020-09-19 23:03 +0100
                  Re: Microsoft Will now support C11 and C17 standard!!!!!!!!!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-09-19 23:54 +0100

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#155142

On 9/18/2020 10:09 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 9/18/20 10:38 PM, BGB wrote:
>>> On 9/18/2020 7:53 PM, James Kuyper wrote:
>>>> On 9/18/20 6:53 PM, BGB wrote:
>>>> ...
>>>>> In my compiler, both _Complex and _Imaginary are handled essentially as
>>>>> 2-element vector types (which in turn allow cast-conversion with some
>>>>> other types).
>>>>
>>>> Why in the world are you handling _Imaginary as a "2-element vector
>>>> type"? The whole point of, for example, double _Imaginary is that the
>>>> real part is guaranteed to be exactly 0.0, which allows it to store only
>>>> the imaginary part, the same way that plain double has an imaginary part
>>>> that is guaranteed to be exactly 0.0, which allows double to store only
>>>> the real part.
>>>> Situations where _Imaginary is useful are relatively rare, but it's also
>>>> optional. I don't see the point in implementing it unless you implement
>>>> it so that sizeof(double _Imaginary) == sizeof(double).
>>>
>>> Implementing _Imaginary as a 2-element vector means that both it and
>>> _Complex can be treated as more-or-less equivalent as far as the backend
>>> is concerned (with the primary difference between them being that the
>>> real part of an _Imaginary always holds zero).
>>
>> Any application for which such an implementation would be acceptable
>> would have been written to use _Complex, not _Imaginary. Properly
>> implemented _Imaginary is not only half as big as _Complex, but can also
>> substantially reduce the number of elementary floating point operations
>> that need to be performed. Virtually by definition, any application that
>> bothers to use _Imaginary would be using it precisely because those
>> benefits are important to that application.
> 
> And N1570 Annex G says:
> 
>      Each imaginary type has the same representation and alignment
>      requirements as the corresponding real type. The value of an object
>      of imaginary type is the value of the real representation times the
>      imaginary unit.
> 
> Support for imaginary types is optional.
> 
> I'm actually a bit unclear on the requirements for imaginary types
> (_Imaginary float, _Imaginary double, _Imaginary long double).  N1570
> Annex G, which is normative, says:
> 
>      This annex supplements annex F to specify complex arithmetic for
>      compatibility with IEC 60559 real floating-point arithmetic. An
>      implementation that defines __STDC_IEC_559_COMPLEX__ shall conform
>      to the specifications in this annex.
> 
> Both gcc and clang define __STDC_IEC_559_COMPLEX__, but neither
> supports imaginary types.  And a footnote in 6.4.1 (Keywords)
> merely says that "One possible specification for imaginary types
> appears in annex G.", which seems oddly vague.  The latest C2X
> draft I have, N2479, doesn't make any relevant changes.  (In C99,
> Annex G was informative, and it said "should conform" rather than
> "shall conform".)
> 
> Are gcc and clang non-conforming, or am I missing something?
> 

My initial implementation was, as noted, fairly lazy:
In nearly every regard the _Imaginary type was equivalent to _Complex.

I didn't really think too much into it, mostly noted that Imaginary 
mostly existed in relation to Complex, and given Complex can represent 
everything Imaginary can represent, it was initially easiest to treat 
them as more-or-less equivalent.


I went off and hacked on it some...

While still mostly untested, the _Imaginary should now be represented 
in-memory as a scalar type rather than as a vector type.

They will remain as a vector type in registers though; generally as a 
128-bit pair of 'double' values; and will still be operated on in 
basically the same way as _Complex, ...

Similarly, they will remain as vector types as far as function call and 
returns and similar are concerned.

The ISA in question basically has its register space as 32x64-bit or 
16x128-bit, so the added register pressure shouldn't be too much of an 
issue in this case.


May need to go off and write some test cases for this stuff.

Can also note that there is not yet any support for "long double 
_Complex" or similar, but as-is, this would be essentially a 256-bit 
monstrosity (and probably rather unlikely to see much use in practice; 
with types in this size range generally being pass-by-reference and then 
copied around as needed, vs 128-bit types being able to be passed in 
registers).


>>> Then again, I guess it is possible that it could be made to have a
>>> special purpose behavior that it is stored as a single element in memory
>>> (while still being two element once loaded into a register).
>>
>> Not only it that possible, it's the whole point of having such a type,
>> which was carefully designed to ensure that it was possible.
> 

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

#155145

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> On 9/18/20 10:38 PM, BGB wrote:
>>
>>> On 9/18/2020 7:53 PM, James Kuyper wrote:
>>>
>>>> On 9/18/20 6:53 PM, BGB wrote:
>>>> ...
>>>>
>>>>> In my compiler, both _Complex and _Imaginary are handled essentially as
>>>>> 2-element vector types (which in turn allow cast-conversion with some
>>>>> other types).
>>>>
>>>> Why in the world are you handling _Imaginary as a "2-element vector
>>>> type"?  The whole point of, for example, double _Imaginary is that the
>>>> real part is guaranteed to be exactly 0.0, which allows it to store only
>>>> the imaginary part, the same way that plain double has an imaginary part
>>>> that is guaranteed to be exactly 0.0, which allows double to store only
>>>> the real part.
>>>> Situations where _Imaginary is useful are relatively rare, but it's also
>>>> optional.  I don't see the point in implementing it unless you implement
>>>> it so that sizeof(double _Imaginary) == sizeof(double).
>>>
>>> Implementing _Imaginary as a 2-element vector means that both it and
>>> _Complex can be treated as more-or-less equivalent as far as the backend
>>> is concerned (with the primary difference between them being that the
>>> real part of an _Imaginary always holds zero).
>>
>> Any application for which such an implementation would be acceptable
>> would have been written to use _Complex, not _Imaginary.  Properly
>> implemented _Imaginary is not only half as big as _Complex, but can also
>> substantially reduce the number of elementary floating point operations
>> that need to be performed.  Virtually by definition, any application that
>> bothers to use _Imaginary would be using it precisely because those
>> benefits are important to that application.
>
> And N1570 Annex G says:
>
>     Each imaginary type has the same representation and alignment
>     requirements as the corresponding real type.  The value of an object
>     of imaginary type is the value of the real representation times the
>     imaginary unit.
>
> Support for imaginary types is optional.
>
> I'm actually a bit unclear on the requirements for imaginary types
> (_Imaginary float, _Imaginary double, _Imaginary long double).  N1570
> Annex G, which is normative, says:
>
>     This annex supplements annex F to specify complex arithmetic for
>     compatibility with IEC 60559 real floating-point arithmetic.  An
>     implementation that defines __STDC_IEC_559_COMPLEX__ shall conform
>     to the specifications in this annex.
>
> Both gcc and clang define __STDC_IEC_559_COMPLEX__, but neither
> supports imaginary types.  And a footnote in 6.4.1 (Keywords)
> merely says that "One possible specification for imaginary types
> appears in annex G.", which seems oddly vague.  The latest C2X
> draft I have, N2479, doesn't make any relevant changes.  (In C99,
> Annex G was informative, and it said "should conform" rather than
> "shall conform".)

Annex G is obligatory (in C11) only if __STDC_IEC_559_COMPLEX__
is defined.  An implementation may support imaginary types
without defining __STDC_IEC_559_COMPLEX__, in which case those
types need not conform to Annex G.  Thus Annex G is one possible
specification for imaginary types, but not the only possible
specification for imaginary types.

> Are gcc and clang non-conforming, or am I missing something?

For C99, Annex G is merely advisory, so both gcc and clang are
conforming.

For C11, gcc is not conforming.

The situation with clang is different.  By itself clang does not
define __STDC_IEC_559_COMPLEX__.  This may be seen by running
clang on an input like

    typedef unsigned long UL;

with a command like 'clang -std=c11 -pedantic -E -dM', and noting
the absence of the ..._IEC_559_... macros.  The definitions for
these macros comes from <complex.h>.  We might say clang+glibc is
not conforming.  I prefer to think of it as glibc overstepping
its bounds.  Either way, clang together with those header files
is failing (under C11 rules) to meet some of the obligations
stated in Annex G.

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

#155141

> I would think that Microsoft doesn't like C features that can't be easily expressed in C++. Especially those of them that are not "just parser", but require non-trivial support by code generator or language runtime.

Windows systems-programmers are adhered to C++ and MS saw no reason to
support newer C-versions because of that. But as MS opens to the open
-source world, supporting newer C-versions becomes more appropriate as
other platforms like Unix / Linux have a stronger C-bias than Windows.
So with supporting C11 and C17 more Linux-software could be ported to
Windows.

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

#155119

On 9/17/2020 5:53 PM, Ben Bacarisse wrote:
> Leo <usenet@gkbrk.com> writes:
> 
>> This is good news for those cross-compiling their software. Not sure
>> how hopeful I am though, does MSVC even support C99 properly now?
> 
> That won't ever happen.  C11 made VLAs optional and that cleared the way
> for MS to support later standards.
> 
> It's a shame, because the baby of variably modified array types was
> thrown out with the VLA bath water.  I don't think any of MS's
> objections apply to variably modified types in the absence of VLAs
> 

I wonder how they can compare VLAs with gets()

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

#155120

On 18/09/2020 19:32, Manfred wrote:
> On 9/17/2020 5:53 PM, Ben Bacarisse wrote:
>> Leo <usenet@gkbrk.com> writes:
>>
>>> This is good news for those cross-compiling their software. Not sure
>>> how hopeful I am though, does MSVC even support C99 properly now?
>>
>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>> for MS to support later standards.
>>
>> It's a shame, because the baby of variably modified array types was
>> thrown out with the VLA bath water.  I don't think any of MS's
>> objections apply to variably modified types in the absence of VLAs
>>
> 
> I wonder how they can compare VLAs with gets()

Create a function like:

   void fred(int n){
     int A[n*n];
   }

then call it with fred(10000), or with a value which is a program input. 
VLAs make it so easy to overflow the stack.

It is also easy to /inadvertently/ create a VLA because you haven't 
realised the dimension isn't a compile-time constant expression.

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

#155121

On 9/18/2020 9:06 PM, Bart wrote:
> On 18/09/2020 19:32, Manfred wrote:
>> On 9/17/2020 5:53 PM, Ben Bacarisse wrote:
>>> Leo <usenet@gkbrk.com> writes:
>>>
>>>> This is good news for those cross-compiling their software. Not sure
>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>
>>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>>> for MS to support later standards.
>>>
>>> It's a shame, because the baby of variably modified array types was
>>> thrown out with the VLA bath water.  I don't think any of MS's
>>> objections apply to variably modified types in the absence of VLAs
>>>
>>
>> I wonder how they can compare VLAs with gets()
> 
> Create a function like:
> 
>    void fred(int n){
>      int A[n*n];
>    }
> 
> then call it with fred(10000), or with a value which is a program input. 
> VLAs make it so easy to overflow the stack.
> 
> It is also easy to /inadvertently/ create a VLA because you haven't 
> realised the dimension isn't a compile-time constant expression.

Yes, but you are still in control of the fred() call. The risk is only 
related with a programming error, however easy to make.
I don't see how this can compare to gets() where stdin can overrun the 
buffer with no control by the programmer.

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

#155122

Bart <bc@freeuk.com> writes:

> On 18/09/2020 19:32, Manfred wrote:
>> On 9/17/2020 5:53 PM, Ben Bacarisse wrote:
>>> Leo <usenet@gkbrk.com> writes:
>>>
>>>> This is good news for those cross-compiling their software. Not sure
>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>
>>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>>> for MS to support later standards.
>>>
>>> It's a shame, because the baby of variably modified array types was
>>> thrown out with the VLA bath water.  I don't think any of MS's
>>> objections apply to variably modified types in the absence of VLAs
>>>
>>
>> I wonder how they can compare VLAs with gets()
>
> Create a function like:
>
>   void fred(int n){
>     int A[n*n];
>   }
>
> then call it with fred(10000), or with a value which is a program
> input. VLAs make it so easy to overflow the stack.

Why is that a problem?  I'm not very familiar with Windows so maybe
there is a reason this is a particular problem in that environment.

-- 
Ben.

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

#155126

On 18/09/2020 21:05, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 18/09/2020 19:32, Manfred wrote:
>>> On 9/17/2020 5:53 PM, Ben Bacarisse wrote:
>>>> Leo <usenet@gkbrk.com> writes:
>>>>
>>>>> This is good news for those cross-compiling their software. Not sure
>>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>>
>>>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>>>> for MS to support later standards.
>>>>
>>>> It's a shame, because the baby of variably modified array types was
>>>> thrown out with the VLA bath water.  I don't think any of MS's
>>>> objections apply to variably modified types in the absence of VLAs
>>>>
>>>
>>> I wonder how they can compare VLAs with gets()
>>
>> Create a function like:
>>
>>    void fred(int n){
>>      int A[n*n];
>>    }
>>
>> then call it with fred(10000), or with a value which is a program
>> input. VLAs make it so easy to overflow the stack.
> 
> Why is that a problem?  I'm not very familiar with Windows so maybe
> there is a reason this is a particular problem in that environment.
> 

On Windows the stack has a fixed upper size, typically a few MB. It is 
not expandable.

But I've just tried it on Linux. There it does not fail immediately, 
only when you try to use the memory past the end of the stack (write to 
high elements of A, or call another function).

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

#155127

Bart <bc@freeuk.com> writes:

> On 18/09/2020 21:05, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 18/09/2020 19:32, Manfred wrote:
>>>> On 9/17/2020 5:53 PM, Ben Bacarisse wrote:
>>>>> Leo <usenet@gkbrk.com> writes:
>>>>>
>>>>>> This is good news for those cross-compiling their software. Not sure
>>>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>>>
>>>>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>>>>> for MS to support later standards.
>>>>>
>>>>> It's a shame, because the baby of variably modified array types was
>>>>> thrown out with the VLA bath water.  I don't think any of MS's
>>>>> objections apply to variably modified types in the absence of VLAs
>>>>>
>>>>
>>>> I wonder how they can compare VLAs with gets()
>>>
>>> Create a function like:
>>>
>>>    void fred(int n){
>>>      int A[n*n];
>>>    }
>>>
>>> then call it with fred(10000), or with a value which is a program
>>> input. VLAs make it so easy to overflow the stack.
>>
>> Why is that a problem?  I'm not very familiar with Windows so maybe
>> there is a reason this is a particular problem in that environment.
>
> On Windows the stack has a fixed upper size, typically a few MB. It is
> not expandable.

I don't see what that has to do with VLAs.  I thought MS's opposition
might rest on some technical difficulty that was specific to VLAs.

-- 
Ben.

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

#155124

Bart <bc@freeuk.com> writes:
[...]
> Create a function like:
>
>   void fred(int n){
>     int A[n*n];
>   }
>
> then call it with fred(10000), or with a value which is a program
> input. VLAs make it so easy to overflow the stack.

Create a function like:

    void fred(void) {
        int A[N*N];
    }

and have this visible to the definition:

    #define N 10000

Arrays make it so easy to overflow the stack.

[...]

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

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

#155125

On 18/09/2020 22:09, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Create a function like:
>>
>>    void fred(int n){
>>      int A[n*n];
>>    }
>>
>> then call it with fred(10000), or with a value which is a program
>> input. VLAs make it so easy to overflow the stack.
> 
> Create a function like:
> 
>      void fred(void) {
>          int A[N*N];
>      }
> 
> and have this visible to the definition:
> 
>      #define N 10000
> 
> Arrays make it so easy to overflow the stack.


Yes, but they will do so the first time fred is called. Since the 'n' is 
my example is a variable, it can be called millions of times without 
anything going wrong. Until an input is encountered that will trigger 
the problem.

Try another:

   #define N -1
   int A[N];

This is reported by the compiler. But do this:

   int n = -1;
   int A[n];

No error. What it does at runtime varies.

(No error with C99 compilers anyway. Mine says "Can't do VLAs".)

I'm just highlighting ways that VLAs can cause failures that are harder 
to test for or control than other approaches. Example:

   int data[getfilesize(F)];

is fine for files of 1 or 2 or 4MB, depending on stack size. But it can 
easily blow up. What would be a suitable upper limit? We don't know.

Using heap memory can run into problems too, but there, there might be 
1000x  more capacity, and malloc (when the OS deigns it ought to) can 
return a failure code.

With the VLA, it might nearly but not quite fill the stack, but then 
crash a little bit later on in a piece of code that has nothing wrong 
with it.

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

#155144

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Leo <usenet@gkbrk.com> writes:
>
>> This is good news for those cross-compiling their software.  Not sure
>> how hopeful I am though, does MSVC even support C99 properly now?
>
> That won't ever happen.  C11 made VLAs optional and that cleared the way
> for MS to support later standards.

Do you know why Microsoft objected to VLAs?  I've searched the
web a bit but wasn't able to find anything with any real
substance.

> It's a shame, because the baby of variably modified array types was
> thrown out with the VLA bath water.  I don't think any of MS's
> objections apply to variably modified types in the absence of VLAs

I agree about variably modified types as contrasted with VLAs.
But I confess to being somewhat baffled by the reaction that VLAs
are a deal breaker.  Implementing VLAs shouldn't be that hard, if
one is willing to accept a minimally usable implementation.  So I
wonder what it was that Microsoft found so difficult to swallow.

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

#155147

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Leo <usenet@gkbrk.com> writes:
>>> This is good news for those cross-compiling their software.  Not sure
>>> how hopeful I am though, does MSVC even support C99 properly now?
>>
>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>> for MS to support later standards.
>
> Do you know why Microsoft objected to VLAs?  I've searched the
> web a bit but wasn't able to find anything with any real
> substance.

The article at the top of this thread cited this article:
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
which says:

    Astute readers will note that VLAs are also not
    supported. Variable length arrays are generally less efficient
    than comparable fixed sized arrays, and generally inefficient
    compared to equivalent malloc(), when safely and securely
    implemented. VLAs provide attack vectors comparable to those
    of the infamous gets() — deprecated and destined to removal
    — for opportunities of “shifting the stack” and other
    exploits. For these reasons we intend not to support VLAs as
    an optional feature in C11.

(I'm not endorsing the claims in the article, just reporting them.)

[...]

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

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

#155148

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Leo <usenet@gkbrk.com> writes:
>>>
>>>> This is good news for those cross-compiling their software.  Not sure
>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>
>>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>>> for MS to support later standards.
>>
>> Do you know why Microsoft objected to VLAs?  I've searched the
>> web a bit but wasn't able to find anything with any real
>> substance.
>
> The article at the top of this thread cited this article:
> https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
> which says:
>
>     Astute readers will note that VLAs are also not
>     supported.  Variable length arrays are generally less efficient
>     than comparable fixed sized arrays, and generally inefficient
>     compared to equivalent malloc(), when safely and securely
>     implemented.  VLAs provide attack vectors comparable to those
>     of the infamous gets() ? deprecated and destined to removal
>     ? for opportunities of ?shifting the stack?  and other
>     exploits.  For these reasons we intend not to support VLAs as
>     an optional feature in C11.

Ahh, that is helpful.  Thank you.

> (I'm not endorsing the claims in the article, just reporting them.)

Right.  What they say strikes me as somewhat bogus in places,
but that's their comments, not yours.

Thanks again for the citation.

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

#155150

On Sat, 2020-09-19, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Leo <usenet@gkbrk.com> writes:
>>>>
>>>>> This is good news for those cross-compiling their software.  Not sure
>>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>>
>>>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>>>> for MS to support later standards.
>>>
>>> Do you know why Microsoft objected to VLAs?  I've searched the
>>> web a bit but wasn't able to find anything with any real
>>> substance.
>>
>> The article at the top of this thread cited this article:
>> https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
>> which says:
>>
>>     Astute readers will note that VLAs are also not
>>     supported.  Variable length arrays are generally less efficient
>>     than comparable fixed sized arrays, and generally inefficient
>>     compared to equivalent malloc(), when safely and securely
>>     implemented.  VLAs provide attack vectors comparable to those
>>     of the infamous gets() ? deprecated and destined to removal
>>     ? for opportunities of ?shifting the stack?  and other
>>     exploits.  For these reasons we intend not to support VLAs as
>>     an optional feature in C11.
>
> Ahh, that is helpful.  Thank you.

But it's written twenty years after they made their decision, so it's
not as helpful as it could have been.  Maybe the blogger didn't know
the background, so he picked the standard arguments against VLAs.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#155154

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Sat, 2020-09-19, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>>> Leo <usenet@gkbrk.com> writes:
>>>>>
>>>>>> This is good news for those cross-compiling their software.  Not sure
>>>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>>>
>>>>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>>>>> for MS to support later standards.
>>>>
>>>> Do you know why Microsoft objected to VLAs?  I've searched the
>>>> web a bit but wasn't able to find anything with any real
>>>> substance.
>>>
>>> The article at the top of this thread cited this article:
>>> https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
>>> which says:
>>>
>>>     Astute readers will note that VLAs are also not
>>>     supported.  Variable length arrays are generally less efficient
>>>     than comparable fixed sized arrays, and generally inefficient
>>>     compared to equivalent malloc(), when safely and securely
>>>     implemented.  VLAs provide attack vectors comparable to those
>>>     of the infamous gets() ? deprecated and destined to removal
>>>     ? for opportunities of ?shifting the stack?  and other
>>>     exploits.  For these reasons we intend not to support VLAs as
>>>     an optional feature in C11.
>>
>> Ahh, that is helpful.  Thank you.
>
> But it's written twenty years after they made their decision, so it's
> not as helpful as it could have been.  Maybe the blogger didn't know
> the background, so he picked the standard arguments against VLAs.

I take your point, and in fact I had similar thoughts when
replying to Keith's message.  The explanation given smacks of post
hoc rationalization.  There is no requirement that VLAs must be
allocated on the stack -- if they thought using malloc is faster
and safer then they could just as well as implemented VLAs using
malloc to allocate them.  Furthermore why now rather than 2012
when VLAs became optional?  No reason to wait those eight years if
VLAs were the only holdup.  Considering all that, there is a
distinct possibility that the true motivation had more to do with
satisfying a business agenda more than it did with satisfying a
technical agenda.  Still it is interesting to hear what they said
about why VLAs are unacceptable, even though what they said is
very likely not the whole story.

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

#155151

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Leo <usenet@gkbrk.com> writes:
>>
>>> This is good news for those cross-compiling their software.  Not sure
>>> how hopeful I am though, does MSVC even support C99 properly now?
>>
>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>> for MS to support later standards.
>
> Do you know why Microsoft objected to VLAs?  I've searched the
> web a bit but wasn't able to find anything with any real
> substance.

No I don't.  There was some talk I can't locate anymore about how
Windows allocates stack, but I don't recall the details nor do I know if
the information was reliable.

-- 
Ben.

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

#155152

On 19/09/2020 12:43, Ben Bacarisse wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> 
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Leo <usenet@gkbrk.com> writes:
>>>
>>>> This is good news for those cross-compiling their software.  Not sure
>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>
>>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>>> for MS to support later standards.
>>
>> Do you know why Microsoft objected to VLAs?  I've searched the
>> web a bit but wasn't able to find anything with any real
>> substance.
> 
> No I don't.  There was some talk I can't locate anymore about how
> Windows allocates stack, but I don't recall the details nor do I know if
> the information was reliable.
> 

It's enough to know that the stack can overflow and cause a crash, and 
VLAs make that easier.

The way that the stack is typically used is a little different from 
Linux AIUI. While a process will have an upper limit on the size, 
initially a lower limit is applied, with a 4KB guard page added.

When stack increases by not more than 4KB at a time, then any accesses 
to that guard page cause it to expand by another 4KB page.

Where the stack is known by the compiler (eg. gcc) to increase by more 
than 4KB in a function, then gcc will insert a call to a special routine 
(something like __chkstk()), which probably just incrementally extends 
it a page time (but I'm guessing).

In the case of VLAs, it doesn't know if the demand for stack at function 
entry will be small or large, so it needs to call __chkstk anyway, just 
in case. But this is a matter of efficiency (and yet another 
complication of VLA usage, since VLA sizes can incrementally grow within 
a function).

The stack will still overflow when it reaches the upper limit anyway.

However, there are other ways of doing this. In my compilers I allocate 
the whole stack (2MB or so) at program start. I don't know what terms, 
reserve, commit etc are involved, but it means the stack can grow by 
arbitrary amounts without checking.

I believe this allocates virtual but not physical storage, in the same 
what that malloc will allocate memory, until the memory is written.

Why it normally works in that peculiar way with a guard page, I don't 
know. But as I said VLAs don't really impact on that.

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

#155153

On 19/09/2020 13:52, Bart wrote:
> On 19/09/2020 12:43, Ben Bacarisse wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Leo <usenet@gkbrk.com> writes:
>>>>
>>>>> This is good news for those cross-compiling their software.  Not sure
>>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>>
>>>> That won't ever happen.  C11 made VLAs optional and that cleared the 
>>>> way
>>>> for MS to support later standards.
>>>
>>> Do you know why Microsoft objected to VLAs?  I've searched the
>>> web a bit but wasn't able to find anything with any real
>>> substance.
>>
>> No I don't.  There was some talk I can't locate anymore about how
>> Windows allocates stack, but I don't recall the details nor do I know if
>> the information was reliable.
>>
> 
> It's enough to know that the stack can overflow and cause a crash, and 
> VLAs make that easier.
> 
> The way that the stack is typically used is a little different from 
> Linux AIUI. While a process will have an upper limit on the size, 
> initially a lower limit is applied, with a 4KB guard page added.
> 
> When stack increases by not more than 4KB at a time, then any accesses 
> to that guard page cause it to expand by another 4KB page.
> 
> Where the stack is known by the compiler (eg. gcc) to increase by more 
> than 4KB in a function, then gcc will insert a call to a special routine 
> (something like __chkstk()), which probably just incrementally extends 
> it a page time (but I'm guessing).
> 
> In the case of VLAs, it doesn't know if the demand for stack at function 
> entry will be small or large, so it needs to call __chkstk anyway, just 
> in case. But this is a matter of efficiency (and yet another 
> complication of VLA usage, since VLA sizes can incrementally grow within 
> a function).
> 
> The stack will still overflow when it reaches the upper limit anyway.
> 
> However, there are other ways of doing this. In my compilers I allocate 
> the whole stack (2MB or so) at program start. I don't know what terms, 
> reserve, commit etc are involved, but it means the stack can grow by 
> arbitrary amounts without checking.


Here is part of an EXE dump of hello.exe created with gcc:

   Stack reserve:    2097152
   Stack commit:     4096

(TCC and lccwin are similar, but the reserve is 1MB.)

Here is it when on a hello.exe created by my bcc:

   Stack reserve:    4194304
   Stack commit:     2097152

(Not sure why I didn't just make these the same. But it'll crash out on 
stack overflow at about same point as gcc.)

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

#155156

Bart <bc@freeuk.com> writes:

> On 19/09/2020 12:43, Ben Bacarisse wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Leo <usenet@gkbrk.com> writes:
>>>>
>>>>> This is good news for those cross-compiling their software.  Not sure
>>>>> how hopeful I am though, does MSVC even support C99 properly now?
>>>>
>>>> That won't ever happen.  C11 made VLAs optional and that cleared the way
>>>> for MS to support later standards.
>>>
>>> Do you know why Microsoft objected to VLAs?  I've searched the
>>> web a bit but wasn't able to find anything with any real
>>> substance.
>>
>> No I don't.  There was some talk I can't locate anymore about how
>> Windows allocates stack, but I don't recall the details nor do I know if
>> the information was reliable.
>
> It's enough to know that the stack can overflow and cause a crash, and
> VLAs make that easier.

That's not enough to answer the question.  First, because it's not true
(unless you contrive a special notion of "easier") and, second, it does
not single out any one system and/or compiler.

> The way that the stack is typically used is a little different from
> Linux AIUI. While a process will have an upper limit on the size,
> initially a lower limit is applied, with a 4KB guard page added.
>
> When stack increases by not more than 4KB at a time, then any accesses
> to that guard page cause it to expand by another 4KB page.
>
> Where the stack is known by the compiler (eg. gcc) to increase by more
> than 4KB in a function, then gcc will insert a call to a special
> routine (something like __chkstk()), which probably just incrementally
> extends it a page time (but I'm guessing).

I take it gcc supports VLAs on Windows?

> In the case of VLAs, it doesn't know if the demand for stack at
> function entry will be small or large, so it needs to call __chkstk
> anyway, just in case. But this is a matter of efficiency (and yet
> another complication of VLA usage, since VLA sizes can incrementally
> grow within a function).

To clarify, the size of a VLA can't change, but differently sized VLAs
with the same name can be required:

   for (int i = 10; i < 20; i++) {
       char s[i];
       ...
    }

> The stack will still overflow when it reaches the upper limit anyway.

By overflow, I hope you don't mean silently.  You get a signal of some
sort I presume.

> Why it normally works in that peculiar way with a guard page, I don't
> know. But as I said VLAs don't really impact on that.

I wonder if having to check the guard page other than at function entry
was the killer issue?

-- 
Ben

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

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

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

csiph-web