Re: Segments

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.