Re: Segments

On Thu, 16 Jan 2025 12:36:45 +0100
David Brown <david.brown@hesbynett.no> wrote:

On 15/01/2025 21:59, Thomas Koenig wrote:

Michael S <already5chosen@yahoo.com> schrieb: 

On Wed, 15 Jan 2025 18:00:34 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
 

Michael S <already5chosen@yahoo.com> schrieb: 

On Wed, 15 Jan 2025 07:09:38 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
   

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

Thomas Koenig <tkoenig@netcologne.de> writes:
[...] 

CHERY targets C, which on the one hand, I understand (there's
a ton of C code out there), but trying to retrofit a safe
memory model onto C seems a bit awkward - it might have been
better to target a language which has arrays in the first
place, unlike C. 

[...]
>
C does have arrays. 

>
Sort of - they decay into pointers at first sight.
>
But what I should have written was "multi-dimensional arrays",
with a reasonable way of handling them. 

>
C language always had multi-dimensional arrays, with limitation
that dimensions have to be known in compile time.
C99 lifted that limitation, making C support for
multi-dimensional arrays comparable to that in old Fortran.
C11 said that lifting is optional.
Now C23 makes part of the lifting (variably-modified types) again
mandatory. 

>
I'd missed that one.
 

Relatively to F90, support for multi-dimensional arrays in C23 is
primitive. 

>
 From what you describe, support for multi-dimensional arrays
in C23 now reached the level of Fortran II, released in
1958.  Only a bit more than six decades, can't complain
about that. 

>
Well, apart from playing with what is mandatory and what is not,
arrays stuff in C had not changed (AFAIK) since C99. 

 
It's not mandatory, so compilers are free to ignore it (and a
major compiler, from a certain company in Redmond, does
not support it).  That's as good as sayhing that it does not
exist in the language. 

 
Not really, no.  The world of C programmers can be divided into those
that work with C compilers and can freely use pretty much anything in
C, and those that have to content with limited, non-standard or
otherwise problematic compilers and write code that works for them.
Such compilers include embedded toolchains for very small
microcontrollers or DSPs, and MS's C compiler.
 
Some C code needs to be written in a way that works on MS's C
compiler as well as other tools, but most is free from such
limitations.  Even for those targeting Windows, it's common to use
clang or gcc for serious C coding.
 
MS used to have a long-term policy of specifically not supporting C
well because that might make it easier for people to write
cross-platform C code for Windows and Linux.  Instead, they preferred
to push developers towards C# and Windows-only programming - or if
that failed, C++ which was not as commonly used on *nix.  Now, I
think, they just don't care much about C - they don't see many people
using their tools for C and haven't bothered supporting any feature
that needs much effort.  They know that they can't catch up with
other C compilers, so have made it easier to integrate clang with
their IDE's and development tools.
 

Microsoft does care about C, but only in one specific area - kernel
programming. The only other language officially allowed for Windows
kernel programming is C++, but coding kernel drivers in C++ is
discouraged. I suppose that driver written in C++ would have major
difficulties passing Windows HLK tests and getting WHQL signing.

As you can guess, in kernel drivers VLA are unwelcome. VMTs are, may
be, tolerable (I wonder what is current policy of Linux and BSD
kernels), but hardly desirable.