Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Segments
Date: Thu, 16 Jan 2025 12:36:45 +0100
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <vmar0d$3g078$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 16 Jan 2025 12:36:46 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2918de53a5f9f60dfa48430944162c87";
	logging-data="3670248"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/5sSQ9uNhZOOP4U53BFhg+OtZAR89bUOc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:0avVVWfw4tqh/STNIkQ4I8sceHw=
Content-Language: en-GB
In-Reply-To: <vm97j3$342b3$1@dont-email.me>
Bytes: 5128

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.