Re: Loops (was Re: do { quit; } else { })

On 2025-05-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:
[...]

Progarms that manipulate strings using standard library functions often
take advantage of the above. Strings are defined as null-terminated
arrays; but it is very common for strings to be arrays that are displaced
within larger arrays.

>
To be pedantic, a string is defined as "a contiguous sequence of
characters terminated by and including the first null character".
The word "array" is not used.  It does seem fairly obvious that
the contiguous sequence will be stored in an array (array object?),
but the standard doesn't quite say so.

This issue with a + 5 and all points to a more general issue.
There is no discussion about aliasing between arrays of
the same element type, but different sizes and displacements.

Given int a[10], we can do int (*p)[5] = (int (*)[5])(a + 5) to obtain
a pointer the upper half of the array as an int [5] array type.

Then *p is an array lvalue which recovers us a + 5.
Surely, that is valid; but it's not spelled out.

Arrays are not accessed themselves since they  cannot be passed,
returned or assigned, and their values "decay" to pointers.

An access like (*p)[1] cannot be considered an invalid aliasing for
a[6], since it uses the declared type of the element. The pointer is
valid, and not by chance; but doe to good arithmetic
on a good starting value.

*p itself cannot be invalid aliasing because that concept is defined in
terms of access using the wrong type, and *p doesn't access.

(And so, why couldn't we pass the expression *p as the argument to that
int a[static 5]? If *p doesn't count as an array, by what
rule is that? Surely not aliasing. And if *p is okay but a + 5 is not,
what's the point of the hair-splititng.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca