Groups | Search | Server Info | Login | Register
Groups > comp.lang.c > #393400
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Loops (was Re: do { quit; } else { }) |
| Date | 2025-05-13 22:38 -0700 |
| Organization | None to speak of |
| Message-ID | <87h61nbvlo.fsf@nosuchdomain.example.com> (permalink) |
| References | (16 earlier) <86msbgw49b.fsf@linuxsc.com> <875xi4cevz.fsf@nosuchdomain.example.com> <86ecwsvunb.fsf@linuxsc.com> <87sel7c3y6.fsf@nosuchdomain.example.com> <865xi3x22i.fsf@linuxsc.com> |
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:
>>>> 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.
Again, of course the behavior of func(arr+6) is undefined. The behavior
of func(arr+5) is less clear *to me*.
>>>> """
>>>> 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.
It does so only if the argument arr+5 provides access to "the first
element of an array". You seem to think that it's obvious that it does
so, based on the disinction you make between "array" and "array object".
>>> 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.
I note that you haven't answered the above questions. They were not
rhetorical. I asked them because I thought that answers to those
specific questions would help me to understand the distinction that you
make between "array" and "array object".
> The meanings follow from a plain understanding of the English
> language.
I disagree. Perhaps my understanding of certain combinations of English
words differs from yours.
> 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.
Is there no "region of data storage in the execution environment, the
contents of which can represent values"? Cannot that region represent
a value of type unsigned char[sizeof(T)-1]? Is a region of data
storage that can represent values of array type not an array object?
Again, none of these questions are rhetorical.
Can you define, preferably in something approaching standardese, what
you mean by "array" and by "array object", and in particular how they
differ?
I believe that, in my example above, arr+5 *does* "provide access
to an array" with at least 5 elements. (I also believe that that
"array" is an "array object".) My difficulty is in demonstrating
this based on the normative wording in the standard. *Maybe*
if you could explain the distinction you make between "array" and
"array object" it would help.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 07:31 -0700
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-04 18:08 +0300
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-05 10:42 +0300
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-10 06:43 -0700
Re: Loops (was Re: do { quit; } else { }) Muttley@dastardlyhq.com - 2025-05-10 15:56 +0000
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-05-10 17:48 +0000
Re: Loops (was Re: do { quit; } else { }) Muttley@dastardlyhq.com - 2025-05-11 08:20 +0000
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-10 14:29 -0700
Re: Loops (was Re: do { quit; } else { }) Muttley@dastardlyhq.com - 2025-05-11 08:21 +0000
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-11 12:02 +0200
Re: Loops (was Re: do { quit; } else { }) Muttley@dastardlyhq.com - 2025-05-11 15:30 +0000
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-05-11 16:29 +0000
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-11 18:49 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-11 14:41 -0700
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-11 17:43 -0400
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-11 15:06 -0700
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-11 18:30 -0400
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-11 18:15 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-11 19:09 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 00:16 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 02:23 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 07:19 -0700
Re: Loops (was Re: do { quit; } else { }) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 15:34 +0100
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 22:42 -0700
Re: Loops (was Re: do { quit; } else { }) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-13 07:31 +0100
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-14 21:12 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 09:30 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-13 22:28 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 13:31 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-14 20:44 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-14 21:45 -0700
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-12 17:24 +0200
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-12 00:07 -0400
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 00:43 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 02:27 -0700
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-12 17:18 +0200
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-12 19:53 -0400
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 23:03 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-12 19:04 -0700
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-12 17:08 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 13:38 -0700
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-13 12:41 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-13 23:16 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 14:35 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 15:10 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 15:41 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 18:38 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 19:37 -0700
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-13 23:54 -0400
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 21:19 -0700
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 21:12 -0700
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 22:38 -0700
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-14 03:35 +0000
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 21:54 -0700
Re: Loops (was Re: do { quit; } else { }) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-14 06:31 +0000
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 06:01 -0700
Re: Loops (was Re: do { quit; } else { }) Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-14 12:24 +0200
Re: Loops (was Re: do { quit; } else { }) scott@slp53.sl.home (Scott Lurndal) - 2025-06-14 13:57 +0000
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-06-14 22:27 +0300
Re: Loops (was Re: do { quit; } else { }) Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-15 09:32 +0200
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-14 13:00 +0200
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-14 13:20 +0200
Re: Loops (was Re: do { quit; } else { }) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-14 23:20 -0400
Re: Loops (was Re: do { quit; } else { }) David Brown <david.brown@hesbynett.no> - 2025-05-15 11:23 +0200
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-11 17:59 -0700
Re: Loops (was Re: do { quit; } else { }) Muttley@DastardlyHQ.org - 2025-05-12 10:11 +0000
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-12 17:09 +0300
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-11 01:09 +0300
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-11 17:30 -0700
Re: Loops (was Re: do { quit; } else { }) Michael S <already5chosen@yahoo.com> - 2025-05-12 16:18 +0300
Re: Loops (was Re: do { quit; } else { }) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-14 11:09 -0700
Re: Loops (was Re: do { quit; } else { }) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-13 15:57 +0200
Re: Loops (was Re: do { quit; } else { }) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-04 13:52 -0700
csiph-web