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 11:43:48 +0100
Organization: A noiseless patient Spider
Lines: 144
Message-ID: <vmant5$3fes2$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 16 Jan 2025 11:43:50 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2918de53a5f9f60dfa48430944162c87";
	logging-data="3652482"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+lHawHwudt8tk1h4MFlZDvbjwMytK3oxQ="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:RSRtv7Hbzz1KgFObIizv1I71Fco=
Content-Language: en-GB
In-Reply-To: <20250115222824.000034d6@yahoo.com>
Bytes: 8019

On 15/01/2025 21:28, Michael S wrote:
> 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.

It's not a big thing.  VLA's were added in C99, but one big and 
influential compiler supplier didn't want to bother supporting them 
(there's lots in C99 that they didn't bother supporting) so the argued 
for it to be optional in C11.  By the time C23 was in planning, they had 
finally got around to supporting most of C99, so it is no longer 
optional for standards compliance.  But basically the situation is the 
same as it always has been - if you use a solid C compiler like gcc, 
clang, icc, etc., you can freely use VLA's.  If you use MS's half-done 
effort, you can't.  (MS's compiler has much better support for newer C++ 
standards - they just seem determined to be useless at C support.)

>>
>>> 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. So, more like four
> decades. Or 33 years since Fortran got its first standard.
> 

Yes.

>>
>>> There are no array descriptors generated automatically by
>>> compiler. But saying that there is no support is incorrect.
>>
>> What happens for mismatched array bounds between caller
>> and callee?  Nothing, I guess?

Bad things /might/ happen.  But they might not - it's undefined behaviour.

> 
> I don't know. I didn't read this part of the standard. Or any part of
> any C standard past C89.
> 
> Never used them, too. For me, multi-dimensional arrays look mostly like
> source of confusion rather than useful feature. At least as long as
> there are no automatically generated descriptors. With exception for
> VERY conservative cases like array fields in structure, with all
> dimensions fixed at compile time.
> 
> I don't know, but I can guess. And in case I am wrong Keith Thompson
> will correct me.
> Most likely the standard says that mismatched array bounds between
> caller and callee is UB.

Yes.

If you have:

	int x[4][6];

then the expression "x[i]" is evaluated by converting "x" to a pointer 
to an array of 6 ints.  Thus x[0][6] would be an out-of-bounds access to 
the first array of 6 ints in x - it is /not/ defined to work like 
x[1][0], even though you'd get the same bit of memory if you worked out 
the array address by hand.

In practice, it might work fine.  When you declare an array type, the 
compiler will believe you - C is a trusting language.  But if you have 
given the compiler conflicting information, things can go badly wrong. 
So if you declare an array somewhere with one format that the compiler 
can see, and then access it through an lvalue (such as a pointer) with a 
different format that the compiler also can see, the compiler might 
generate code that assumes one format or the other, or a mix of them. 
Or it might assume that the pointer can't refer to the declared array 
because they are not the same format, and keep values cached in 
registers that don't match up.

I expect you'd see problems most often if the compiler is able to make 
use of SIMD or vector registers to handle blocks of the data at a time. 
And you are more likely to see trouble with cross-module optimisations 
(LTO in gcc terms) since it leads to greater sharing of information over 
wider ranges of the code.

As always, the advice is not to lie to your compiler - it might not bite 
you now, but it may well do in the future when you least expect it.


> And most likely in practice it works as expected. I.e. if caller
> defined the matrix as X[M][N] and caller is treating it as Y[P][Q] then
> access to Y[i][j] for as long as k=i*Q+j < M*N  will go to X[k/N][k%N].
> 

Remember that in C (and all other programming languages), if you try to 
do something that is not defined behaviour, there isn't any concept of 
"works as expected" as far as the language is concerned.  What the 
/programmer/ expected is a different matter - but if the language (or 
additional information from the compiler) does not define the behaviour, 
then the programmer's expectations are based on a misunderstanding.

> However, you have to pay attention that in practice something like that
> happening by mistake with variably-modified types is far less likely
> than it is with classic C multi-dimensional arrays.
> 

I'm not sure why you'd say that.

The rule for getting array code right is quite simple - don't use arrays 
without knowing the bounds for each dimension.  You can get these by 
passing bounds as parameters, or using fixed constants, or wrapping 
fixed-size arrays in a struct and using sizeof - however you do it, make 
sure you know the bounds and keep them consistent.