Path: csiph.com!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:19:54 -0700
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <861psrx1qt.fsf@linuxsc.com>
References: <vspbjh$8dvd$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> <100145s$2a235$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 14 May 2025 06:19:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="adcc0210618ce5c814d2d263cc71a7bf"; logging-data="2439490"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ELeV6WhOewdBXGmqBF4WW3xv3EyjN2jU="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:7OmxjO3adtv9FuDTEa5kuzzbbbM= sha1:1J1mbJXMfKQEQFl8lh6zuAggQtQ=
Xref: csiph.com comp.lang.c:393398

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 5/13/25 22:37, Keith Thompson wrote:
>
>> 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.
>
> ...
>
>>> 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.
>
> Tim - [...]

I don't know why you expect me to read postings meant for me but
posted as a reply to another poster.  Sometimes I do, sometimes
I don't.  You may take the correlation as being determined by
quantum mechanical uncertainty.