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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#155134

On 9/18/2020 3:26 AM, Bonita Montero wrote:
>>> I'm talking about those programming for Windows and
>>> not those programming Windows.
> 
>> One note troll.
> 
> It is like what I said: C-only programmers are surely very rare
> on Windows-systems. 

C-only, or C sometimes?



> Maybe that's also because MS didn't support
> current C-versions until yet. But I doubt this will change with
> MS now supporting newer language features. I'm pretty sure this
> feature will be mainly used to port software from other platorms.

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

#155135

On 9/18/2020 3:26 AM, Bonita Montero wrote:
>>> I'm talking about those programming for Windows and
>>> not those programming Windows.
> 
>> One note troll.
> 
> It is like what I said: C-only programmers are surely very rare
> on Windows-systems. Maybe that's also because MS didn't support
> current C-versions until yet. But I doubt this will change with
> MS now supporting newer language features. I'm pretty sure this
> feature will be mainly used to port software from other platorms.

C is good for clean interfaces.

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

#155136

> C is good for clean interfaces.

C is good for interfacing to non-C-languages. But that's all.
Internally you could stick with C++.

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

#155137

On 9/18/2020 7:21 PM, Bonita Montero wrote:
>> C is good for clean interfaces.
> 
> C is good for interfacing to non-C-languages. But that's all.
> Internally you could stick with C++.
> 

Well... Agreed. C is a good language, but C++... Well, its great.

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

#155080

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

-- 
Ben.

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

#155096

On Thursday, September 17, 2020 at 6:53:57 PM UTC+3, 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.
> 

Isn't it about the same for complex number arithmetic?
Or was it already optional in C99?


> 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
> 
> -- 
> Ben.

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

#155097

already5chosen@yahoo.com writes:

> On Thursday, September 17, 2020 at 6:53:57 PM UTC+3, 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.
>
> Isn't it about the same for complex number arithmetic?

Yes, optional in C11.

> Or was it already optional in C99?

No, not optional in C99.

I don't know if MS has any opinion about _Complex in C, but its
opposition to VLAs was well known.

-- 
Ben.

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

#155109

On Friday, September 18, 2020 at 2:47:03 AM UTC+3, Ben Bacarisse wrote:
> already5chosen@yahoo.com writes:
> 
> > On Thursday, September 17, 2020 at 6:53:57 PM UTC+3, 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.
> >
> > Isn't it about the same for complex number arithmetic?
> 
> Yes, optional in C11.
> 
> > Or was it already optional in C99?
> 
> No, not optional in C99.
> 
> I don't know if MS has any opinion about _Complex in C, but its
> opposition to VLAs was well known.
> 
> -- 
> Ben.

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.

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

#155128

On 9/18/2020 9:31 AM, already5chosen@yahoo.com wrote:
> On Friday, September 18, 2020 at 2:47:03 AM UTC+3, Ben Bacarisse wrote:
>> already5chosen@yahoo.com writes:
>>
>>> On Thursday, September 17, 2020 at 6:53:57 PM UTC+3, 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.
>>>
>>> Isn't it about the same for complex number arithmetic?
>>
>> Yes, optional in C11.
>>
>>> Or was it already optional in C99?
>>
>> No, not optional in C99.
>>
>> I don't know if MS has any opinion about _Complex in C, but its
>> opposition to VLAs was well known.
>>
>> -- 
>> Ben.
> 
> 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.
> 

VLAs, at least to support them "well", could add a particular evil at 
the ABI level: variable length stack frames.

Though, there is still a fallback option:
   VLA -> alloca
   alloca -> wrapper interface over malloc/free

Which can technically allow them to work, but in this case they aren't 
necessarily a feature that one wants to use if doing so can be avoided 
(using VLAs will be worse in terms of performance and similar than using 
a fixed-size array).

Though, OTOH, such a mechanism can still be useful as it may allow large 
arrays to be present in a function with slightly less risk of 
overflowing the stack (or requiring an overly large stack). The compiler 
could impose a limit, and then fold out anything larger than this limit.



OTOH: _Complex is more in the situation of being not particularly 
commonly used, but at least doesn't make as much of a mess. In the 
backend it can be treated either as a structure or as a two-element 
vector type or similar.

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

Though, the general rule for cast-converting vectors:
   Allowed if they use the same representation:
     Such as casting between "_Complex double" and "__vec2d";
     (Elements copy over by value).
   Allowed if it is a generic type of the same size:
     Such as casting between "_Complex double" and "__m128";
     (Untyped copy of bit pattern).
   Allowed if there is a semantic equivalence:
     Such as casting between "_Complex double" and "_Complex float".
     (A sensible conversion path exists between the vector elements).

Direct casts between most other cases are not allowed if it would become 
ambiguous how to interpret the type conversion (however, multiple casts 
may still be allowed to achieve a desired effect).

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

#155129

On 18/09/2020 23:53, BGB wrote:
> On 9/18/2020 9:31 AM, already5chosen@yahoo.com wrote:
>> On Friday, September 18, 2020 at 2:47:03 AM UTC+3, Ben Bacarisse wrote:

>>> I don't know if MS has any opinion about _Complex in C, but its
>>> opposition to VLAs was well known.
>>>
>>> -- 
>>> Ben.
>>
>> 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.
>>
> 
> VLAs, at least to support them "well", could add a particular evil at 
> the ABI level: variable length stack frames.

That would be the least of the problems. Others complications include 
VLAs inside block scopes (as they must be deallocated at block end_, 
loops that redeclare a VLA with a different size each time, and gotos 
into and out of blocks that contain VLAs.

Plus the fact that a VLA is the simplest example of what is really a 
variable /type/ specifier:

   void fn(int m,n) {
       typedef int (*T)[m][n];
       ....
       T A;
       ++m; --n;
       {T B; ...}
Does changing m and n here change the value sizeof returns from the 
array parts of A?

And this is just to do with implementation.



> Though, there is still a fallback option:
>    VLA -> alloca
>    alloca -> wrapper interface over malloc/free
> 
> Which can technically allow them to work, but in this case they aren't 
> necessarily a feature that one wants to use if doing so can be avoided 
> (using VLAs will be worse in terms of performance and similar than using 
> a fixed-size array).
> 
> Though, OTOH, such a mechanism can still be useful as it may allow large 
> arrays to be present in a function with slightly less risk of 
> overflowing the stack (or requiring an overly large stack). The compiler 
> could impose a limit, and then fold out anything larger than this limit.

The compiler doesn't know (usually) how much stack is left. Detecting 
one 1MB VLA is one thing, how about 100 10KB VLAs in an arbitrary 
pattern of recursive functions?

It's a feature out of place in a language like C.

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

#155130

Bart <bc@freeuk.com> writes:
[snip]
> Plus the fact that a VLA is the simplest example of what is really a
> variable /type/ specifier:
>
>   void fn(int m,n) {
>       typedef int (*T)[m][n];
>       ....
>       T A;
>       ++m; --n;
>       {T B; ...}
> Does changing m and n here change the value sizeof returns from the
> array parts of A?

No, the size is determined when the declaration is reached (and
most likely stored in some anonymous objects).  Please don't invent
problems that don't exist.

[...]

> The compiler doesn't know (usually) how much stack is left. Detecting
> one 1MB VLA is one thing, how about 100 10KB VLAs in an arbitrary
> pattern of recursive functions?
>
> It's a feature out of place in a language like C.

The depth of recursion can also be unpredictable at compile time,
and can lead to stack overflow.  VLAs aren't *that* much different.

Let's say you want to allocate an array of N objects, where N is at
most 1000.  If you don't want use malloc() for some reason, a VLA
lets you define an array that is no more than 1000 elements long, and
takes up only as much storage as you need.  A common alternative in
the absence of VLAs is to define an array of exactly 1000 elements
and use only the first N of them.  In that particular use case,
VLAs save memory and make stack overflows less likely.

Of course other uses of VLAs can increase the risk of stack overflow.
If you don't want to accept that risk, you can use them with care,
or avoid them altogether, or adopt a coding standard that forbids
their use.

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

#155133

On 9/18/2020 7:02 PM, Bart wrote:
> On 18/09/2020 23:53, BGB wrote:
>> On 9/18/2020 9:31 AM, already5chosen@yahoo.com wrote:
>>> On Friday, September 18, 2020 at 2:47:03 AM UTC+3, Ben Bacarisse wrote:
> 
>>>> I don't know if MS has any opinion about _Complex in C, but its
>>>> opposition to VLAs was well known.
>>>>
>>>> -- 
>>>> Ben.
>>>
>>> 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.
>>>
>>
>> VLAs, at least to support them "well", could add a particular evil at 
>> the ABI level: variable length stack frames.
> 
> That would be the least of the problems. Others complications include 
> VLAs inside block scopes (as they must be deallocated at block end_, 
> loops that redeclare a VLA with a different size each time, and gotos 
> into and out of blocks that contain VLAs.
> 

It seems likely the details could be fudged slightly.
It also seems possible that doing weird control flow involving VLAs 
could cause the program to crash or otherwise be terminated.


> Plus the fact that a VLA is the simplest example of what is really a 
> variable /type/ specifier:
> 
>    void fn(int m,n) {
>        typedef int (*T)[m][n];
>        ....
>        T A;
>        ++m; --n;
>        {T B; ...}
> Does changing m and n here change the value sizeof returns from the 
> array parts of A?
> 
> And this is just to do with implementation.
> 


There are possible workarounds, such as having the variable part of a 
mulidimensional VLA decay into a fixed type but having some run-time 
information (say, the array has an object header and index tables, with 
array accesses essentially doing a multi-level pointer dereference).

Creating the VLA would also initialize the header and any index tables.
This would mean though that VLAs would be essentially a fundamentally 
different type from that of traditional fixed-length arrays.


> 
> 
>> Though, there is still a fallback option:
>>    VLA -> alloca
>>    alloca -> wrapper interface over malloc/free
>>
>> Which can technically allow them to work, but in this case they aren't 
>> necessarily a feature that one wants to use if doing so can be avoided 
>> (using VLAs will be worse in terms of performance and similar than 
>> using a fixed-size array).
>>
>> Though, OTOH, such a mechanism can still be useful as it may allow 
>> large arrays to be present in a function with slightly less risk of 
>> overflowing the stack (or requiring an overly large stack). The 
>> compiler could impose a limit, and then fold out anything larger than 
>> this limit.
> 
> The compiler doesn't know (usually) how much stack is left. Detecting 
> one 1MB VLA is one thing, how about 100 10KB VLAs in an arbitrary 
> pattern of recursive functions?
> 
> It's a feature out of place in a language like C.

I was figuring that possibly any array over 8K or so could be folded 
out. This wouldn't prevent stack overflows, but it would at least deal 
reasonably well with a few functions with overly large arrays (which 
would be implicitly folded out to the heap).


Likely, compiler support could be handled via internal runtime calls 
(for any functions which use these features).

Essentially, it seems possible that the internal interface could look 
something like:
   void *__alloca_begin(void);      //enter a call frame
   void __alloca_end(void *mark);   //leave a call frame
   void *__alloca(int size);        //allocate within current frame
   void *__alloca_vla1d(void *tyi, int bsz, int s);
   void *__alloca_vla2d(void *tyi, int bsz, int s, int t);
   void *__alloca_vla3d(void *tyi, int bsz, int s, int t, int u);
   ...

An implementation need not necessarily support variable-length stack 
frames, but might instead implement something like this on top of malloc 
and thread-local storage or similar.

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

#155146

Bart <bc@freeuk.com> writes:

> On 18/09/2020 23:53, BGB wrote:
>
>> On 9/18/2020 9:31 AM, already5chosen@yahoo.com wrote:
>>
>>> On Friday, September 18, 2020 at 2:47:03 AM UTC+3, Ben Bacarisse wrote:
>>>
>>>> I don't know if MS has any opinion about _Complex in C, but its
>>>> opposition to VLAs was well known.
>>>>
>>>> -- >>> Ben.
>>>
>>> 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.
>>
>> VLAs, at least to support them "well", could add a particular evil
>> at the ABI level:  variable length stack frames.
>
> That would be the least of the problems.  Others complications include
> VLAs inside block scopes (as they must be deallocated at block end_,
> loops that redeclare a VLA with a different size each time, and gotos
> into and out of blocks that contain VLAs.

Bart displays his willful ignorance.

> Plus the fact that a VLA is the simplest example of what is really a
> variable /type/ specifier:
>
>   void fn(int m,n) {
>       typedef int (*T)[m][n];
>       ....
>       T A;
>       ++m; --n;
>       {T B; ...}
> Does changing m and n here change the value sizeof returns from the
> array parts of A?

Bart again displays his willful ignorance.

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

#155149

On 19/09/2020 07:43, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 18/09/2020 23:53, BGB wrote:
>>

>>> VLAs, at least to support them "well", could add a particular evil
>>> at the ABI level:  variable length stack frames.
>>
>> That would be the least of the problems.  Others complications include
>> VLAs inside block scopes (as they must be deallocated at block end_,
>> loops that redeclare a VLA with a different size each time, and gotos
>> into and out of blocks that contain VLAs.
> 
> Bart displays his willful ignorance.

And Tim displays /his/ ignorance about what constitutes a complex 
language feature.

Actually, in /my/ language, although I don't have them, VLAs would be 
comparatively simple, because:

* There are no block scopes

* It is only actual arrays, not types, that have the runtime dimensions

* There are no conditional or repeated declarations

* These arrays would be allocated once at function entry and 
dealloacated once at one point of return

Even then, they are not /that/ easy, for example because the usually 
fixed stack-frame offsets used to access locals are now variables. And 
you have to make arrangements to store the dimension for each VLA, which 
has to be a copy of the VLA dimension expression as that could change.

If would also get harder with VLAs of more than one dimension, as now it 
affects address mode calculations. While using they involve multipying 
by a constant, now it is a variable. And also less efficient when it is 
a power of two because the compiler doesn't know that.

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

#155157

On 9/19/2020 5:01 AM, Bart wrote:
> On 19/09/2020 07:43, Tim Rentsch wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 18/09/2020 23:53, BGB wrote:
>>>
> 
>>>> VLAs, at least to support them "well", could add a particular evil
>>>> at the ABI level:  variable length stack frames.
>>>
>>> That would be the least of the problems.  Others complications include
>>> VLAs inside block scopes (as they must be deallocated at block end_,
>>> loops that redeclare a VLA with a different size each time, and gotos
>>> into and out of blocks that contain VLAs.
>>
>> Bart displays his willful ignorance.
> 
> And Tim displays /his/ ignorance about what constitutes a complex 
> language feature.
> 
> Actually, in /my/ language, although I don't have them, VLAs would be 
> comparatively simple, because:
> 
> * There are no block scopes
> 
> * It is only actual arrays, not types, that have the runtime dimensions
> 
> * There are no conditional or repeated declarations
> 
> * These arrays would be allocated once at function entry and 
> dealloacated once at one point of return
> 

In one of my other languages (BS2 / BGBScript2), I had made a split:
There were C-style fixed arrays, with C style semantics;
There were Java / C# style arrays, which were more similar to these 
languages.

The language did not use a GC, but instead split up the "new" operator:
* "new T", allocated a type on the heap, explicit "delete" needed;
** More or less, this builds on top of malloc/free.
** If "delete" is not used, then a memory leak will occur.
* "new! T", allocated the type in automatic storage;
** This alloc will be destroyed automatically on function exit.
*** Delete is not used in this case.
** Generally shares the "alloca()" mechanism.

A few of the other messages more-or-less describe how this mechanism 
works (and in many areas, there is a reasonable level of semantic 
overlap with C).

However, if compared with C++, things diverge a bit (has more in common 
with C#, Java, and AS3 than it does with C++; but retains a C-like core 
as well as the C preprocessor).
Otherwise, it uses a single-inheritance + interfaces model, objects are 
pass-by-reference (and objects and arrays have explicit types at 
runtime, *1).

*1: This is partly via a combination of pointer tagging, as well as 
every object starting with a VTable pointer, which also points to a 
ClassInfo structure, which may either identify the class, or provide a 
"signature string" in the case of arrays (basically, types are flattened 
down to an ASCII based notation, which is also used as part of the 
name-mangling convention). The VTable also mostly holds an array of 
function pointers for any virtual methods associated with the class 
(implemented interfaces are basically similar, just sort of glued on to 
the end of the objects' payload area, *2).

The malloc implementation does add a few minor extensions vs a 
traditional malloc, such as the ability to lookup the object-base for a 
pointer into the object, and the ability to retrieve the size of a heap 
allocation (though, this may be a padded size rather than the exact size 
for the original "malloc" call, ...).

*2: If one can imagine it, it is sort of like if a method call:
   foo_obj.bar(x, y);
were translated to something analogous to:
   (*(foo_class_vt **)foo_obj)->bar_ii(obj, x, y);
or, for interfaces:
   (*(foo_iface_vt **)foo_obj)->bar_ii(
       ((void *)foo_obj)-((*(foo_iface_vt **)foo_obj)->offset),
       x, y);
Casting a class to an interface is mostly done by adding a displacement 
to the object's base pointer (such that it points to the corresponding 
interfaces' vtable pointer).


My C compiler actually does both languages, but BS2 has not been 
receiving nearly as much attention in my current project.
In a similar way to C++, both languages share the same underlying ABI.

An inescapable drawback of the language is that high-level features 
don't come from free, and so the highest-performance option is generally 
to write code which mostly looks like what one would write in C, at 
which point, may as well just use C (and then have more freedom to move 
the code between compilers).


> Even then, they are not /that/ easy, for example because the usually 
> fixed stack-frame offsets used to access locals are now variables. And 
> you have to make arrangements to store the dimension for each VLA, which 
> has to be a copy of the VLA dimension expression as that could change.
> 

Generally, I always used fixed-size stack frames... (The compiler 
doesn't actually support non-constant stack frames).


> If would also get harder with VLAs of more than one dimension, as now it 
> affects address mode calculations. While using they involve multipying 
> by a constant, now it is a variable. And also less efficient when it is 
> a power of two because the compiler doesn't know that.
> 

Ironically enough, I have a possible workaround for this:
   Using the BS2 array objects in C mode for the VLAs...

These arrays already more or less implement the needed functionality and 
semantics.

Though, not yet added support for VLAs in C mode.


The C language style I generally use mostly resembles C89 with a few C99 
features glued on. IIRC, I did implement a few minor things from C11, 
but this was mostly because they already aligned pretty well.

I had been pretty lazy about features which I don't really use, and 
which if-implemented, would "still kinda suck".

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

#156802

Bart <bc@freeuk.com> writes:

> On 19/09/2020 07:43, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> On 18/09/2020 23:53, BGB wrote:
>>>
>>>> VLAs, at least to support them "well", could add a particular evil
>>>> at the ABI level:  variable length stack frames.
>>>
>>> That would be the least of the problems.  Others complications include
>>> VLAs inside block scopes (as they must be deallocated at block end_,
>>> loops that redeclare a VLA with a different size each time, and gotos
>>> into and out of blocks that contain VLAs.
>>
>> Bart displays his willful ignorance.
>
> And Tim displays /his/ ignorance about what constitutes a complex
> language feature.

Just the opposite.  I know what is required here.  You are the
one who doesn't.

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

#155131

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

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

#155138

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

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


The compiler already does something vaguely similar in relation to 
half-float (represented as 16-bit in memory, but often held in registers 
and operated on as a 64-bit double; though with an exception for vector 
operations).

As for types:
   short float   //IEEE Binary16 (AKA: Half Float)
   float         //IEEE Binary32 (AKA: Single)
   double        //IEEE Binary64 (AKA: Double)
   long double   //IEEE Binary128

Implicitly, "long double" is implemented via runtime calls, as the 
target ISA lacks native hardware support for 128-bit floating point ops.

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

#155139

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.

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

#155140

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?

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

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

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

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

csiph-web