Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Segments
Date: Thu, 16 Jan 2025 14:35:32 +0200
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <20250116143532.00002117@yahoo.com>
References: <vdlgl9$3kq50$2@dont-email.me>
	<vdtmv9$16lu8$1@dont-email.me>
	<2024Oct6.150415@mips.complang.tuwien.ac.at>
	<vl7m2b$6iat$1@paganini.bofh.team>
	<2025Jan3.093849@mips.complang.tuwien.ac.at>
	<vlcddh$j2gr$1@paganini.bofh.team>
	<2025Jan5.121028@mips.complang.tuwien.ac.at>
	<vleuou$rv85$1@paganini.bofh.team>
	<ndamnjpnt8pkllatkdgq9qn2turaao1f0a@4ax.com>
	<2025Jan6.092443@mips.complang.tuwien.ac.at>
	<vlgreu$1lsr9$1@dont-email.me>
	<vlhjtm$1qrs5$1@dont-email.me>
	<bdZeP.23664$Hfb1.16566@fx46.iad>
	<vlj1pg$25p0e$1@dont-email.me>
	<87cygo97dl.fsf@nosuchdomain.example.com>
	<vm7mvi$2rr87$1@dont-email.me>
	<20250115140026.00003f4f@yahoo.com>
	<vm8t42$3221i$1@dont-email.me>
	<20250115222824.000034d6@yahoo.com>
	<vm97j3$342b3$1@dont-email.me>
	<vmar0d$3g078$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 16 Jan 2025 13:35:51 +0100 (CET)
Injection-Info: dont-email.me; posting-host="195ccd439d007c6d565bd2c55530498a";
	logging-data="3649846"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX181TbJm5zD0YWOstIouYNKrAwd4BQ5dXcU="
Cancel-Lock: sha1:NngqsHCMec8ZgCy21VAAUvac7uE=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)

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.