Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Tue, 13 May 2025 21:12:53 -0700
Organization: A noiseless patient Spider
Lines: 128
Message-ID: <865xi3x22i.fsf@linuxsc.com>
References: <vspbjh$8dvd$1@dont-email.me> <vtiuf0$18au8$1@dont-email.me> <vtj97r$1i3v3$1@dont-email.me> <vtl166$36p6b$1@dont-email.me> <vtlcg0$3f46a$2@dont-email.me> <20250415153419.00004cf7@yahoo.com> <86h62078i8.fsf@linuxsc.com> <20250504180833.00000906@yahoo.com> <86plggzilx.fsf@linuxsc.com> <vvnsvt$3k1mu$1@dont-email.me> <86ldr4yx0x.fsf@linuxsc.com> <vvpmm2$3dhl$1@dont-email.me> <vvpsji$4jht$1@dont-email.me> <vvr5mg$l85c$1@dont-email.me> <vvt2tg$14otk$2@dont-email.me> <1000cs3$2234m$1@dont-email.me> <87sel8nqid.fsf@nosuchdomain.example.com> <86msbgw49b.fsf@linuxsc.com> <875xi4cevz.fsf@nosuchdomain.example.com> <86ecwsvunb.fsf@linuxsc.com> <87sel7c3y6.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 14 May 2025 06:12:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="adcc0210618ce5c814d2d263cc71a7bf";
	logging-data="2439490"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Hbu+S4CZH2nrR1hXHCNytH6dQUq6AQac="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:Cue0VMAtPPCcWLc41dStGYsAtTs=
	sha1:Wid7UbKPvZ8pRLp4cvgQJj6KJyg=
Bytes: 6739

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>> [...]
>>>
>>>>> My personal interpretation is that this:
>>>>>
>>>>> void func(int arr[static 5]) {
>>>>> }
>>>>>
>>>>> int main(void) {
>>>>>     int arr[10];
>>>>>     func(arr+5);    // OK
>>>>>     // func(arr+6); // UB
>>>>> }
>>>>>
>>>>> is valid, because, for example, the last 5 elements of a 10-element
>>>>> array object can be treated as a 5-element array object.  gcc seems
>>>>> to agree, based on the fact that it warns about func(arr+6) but
>>>>> not about func(arr+5).
>>>>>
>>>>> This is a fundamental part of my mental model of C, but in a few
>>>>> minutes of searching I wasn't able to find explicit wording in the
>>>>> standard that supports it.
>>>>
>>>> In N1570, 6.7.6.3 p7.
>>>
>>> Did you mean to imply that that paragraph supports (or refutes) my
>>> statement?  [...]
>>
>> No.  I posted the reference to say that the cited paragraph supports
>> the conclusion that 'func(arr+6)' is undefined behavior.
>
> I wish you had said so in the first place.  Of course func(arr+6) has
> undefined behavior.  Did anyone in this thread say or imply otherwise?

In my view the same reasoning about the meaning applies to both
cases, so there is no reason to talk about them separately.

>>> """
>>> A declaration of a parameter as ??array of _type_?? shall
>>> be adjusted to ??qualified pointer to _type_??, where the
>>> type qualifiers (if any) are those specified within the [ and ]
>>> of the array type derivation.  If the keyword static also appears
>>> within the [ and ] of the array type derivation, then for each call
>>> to the function, the value of the corresponding actual argument
>>> shall provide access to the first element of an array with at least
>>> as many elements as specified by the size expression.
>>> """
>>>
>>> The question is whether, for example, the last 5 elements of a
>>> 10-element array object can be treated as a 5-element array object.
>>> If someone can cite wording in the standard that answers that
>>> question, I'd appreciate it.  (I'll be happier if the answer is yes.)
>>
>> To me it seems obvious that 6.7.6.3 p7 is meant to cover the
>> case of 'func(arr+6)' as being undefined behavior.
>
> But that's not the question I was addressing.  My question is whether
> func(arr+5) has defined behavior, based on whether or not a+5 points to
> the *first element* of an array.

To me it seems obvious that 6.7.6.3 p7 is meant to cover the
case of 'func(arr+5)' as satisfying the "shall" requirement,
for the same reasons that it is meant to cover the case of
'func(arr+6)' as being undefined behavior.

>> Note that 6.7.6.3 p7 doesn't say "array object", it says just
>> "array".  I believe the choice of wording is neither an accident nor
>> an oversight.
>
> Then please explain what you see as the difference.  Wording in the
> standard to support the distinction would be welcome.
>
> Given `int arr[10];`, do the last 5 elements of arr constitute an
> "array"?   Do they constitute an "array object"?  And the same
> questions for arr as a whole.

The meanings follow from a plain understanding of the English
language.

Consider the following example:

   typedef struct { int s; float f; } T;

   extern void foo( unsigned char blah[ static sizeof(T)-1 ] );

   void
   bas( T *it ){
      foo( (unsigned char *)it + 1 );
   }

There is no array object.  But surely there is an array (or at
least an array is indicatated, and an array is present if 'it' is
a valid pointer).  This example satisfies the "shall" requirement
in 6.7.6.3 p7, despite there being no array object in sight.

>>> Looking into this a bit more, I realize that the question doesn't
>>> matter if there's no "static" keyword between the [ and ].  In that
>>> case, the parameter is of pointer type, and the description of
>>> pointer arithmetic (N1570 6.5.6p8) explicitly allows the pointer
>>> to point to the i-th element of an array object.  The wording for
>>> [static N] is the only place I've seen (so far) that specifically
>>> refers to the *first* element of an array object, raising the
>>> question of whether a subobject of an array object is itself an
>>> array object.
>>
>> Again, not an array object, just an array.
>>
>>> This might just be some slightly sloppy wording that was
>>> introduced in C99 and never corrected.
>>
>> I draw the opposite conclusion.  The wording of 6.7.6.3 p7 was
>> carefully chosen so that it would cover cases like 'func(arr+6)'.
>
> But func(arr+5) is the case I was wondering about.  (That's why I
> commented out the func(arr+6) call.)

The wording of 6.7.6.3 p7 was carefully chosen so that it would allow
cases like 'func(arr+5)', for the same reasons that it would deem
'func(arr+6)' as being undefined behavior.