Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Regarding assignment to struct
Date: Tue, 06 May 2025 13:21:38 -0700
Organization: None to speak of
Lines: 81
Message-ID: <87frhhfq25.fsf@nosuchdomain.example.com>
References: <vv338b$16oam$1@dont-email.me> <vv4j9p$33vhj$1@dont-email.me>
	<86plgo7ahu.fsf@linuxsc.com> <vv9hu7$3nomg$1@dont-email.me>
	<87o6w7h2wn.fsf@nosuchdomain.example.com> <868qnb5gg6.fsf@linuxsc.com>
	<87bjs6hjpo.fsf@nosuchdomain.example.com>
	<vvdmjb$3ilpe$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 06 May 2025 22:21:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="200f1b2c855e9fa31fd1080bfdd034d6";
	logging-data="3863271"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+kjOvulcW5nNlp9Ur4t98k"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:lMKDrQdjh754KzKp0JmVLDYMjTQ=
	sha1:etHoej9WPfciPSLqCTDaq7Dj+B0=
Bytes: 4253

Nick Bowler <nbowler@draconx.ca> writes:
> On Mon, 05 May 2025 13:43:31 -0700, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Andrey Tarasevich <noone@noone.net> writes:
>>>> [...]
>>>>
>>>>>   #include <stdio.h>
>>>>>
>>>>>   struct S { int a[10]; };
>>>>>
>>>>>   int main()
>>>>>   {
>>>>>     struct S a, b = { 0 };
>>>>>     int *pa, *pb, *pc;
>>>>>
>>>>>     pa = &a.a[5];
>>>>>     pb = &b.a[5];
>>>>>     pc = &(a = b).a[5];
>>>>>
>>>>>     printf("%p %p %p\n", pa, pb, pc);
>>>>>   }
>>>>
>>>> [...]
>>>>
>>>> I think that code has undefined behavior.
>>>
>>> Right.  [*]
> [...]
>>> [*] Assuming C11 semantics.  At best inadvisable under C99
>>> semantics, and a constraint violation under C90 semantics.
>> 
>> What C90 constraint does it violate?  Both gcc and clang reject it
>> with "-std=c90 -pedantic-errors", with an error message "ISO C90
>> forbids subscripting non-lvalue array", but I don't see a relevant
>> constraint in the C90 standard.
>
> I don't know about C90, but in C89 the above code violates the
> constraint on the [] operator that "one of the expressions shall
> have type ``pointer to object type.''" (3.3.2.1, first paragraph)
>
> C89 (3.2.2.1, third paragraph) only describes conversion of lvalues with
> array type into pointers.  No similar rule applies for an expression
> with array type which is not an lvalue, so such expressions are not
> converted to pointers.
>
> So, given:
>
>   struct { int a[10]; } a, b;
>   /* ... */
>   (a = b).a[5];
>
> Since (a = b).a is not an lvalue, it is not converted to a pointer, so
> neither operand of [] has pointer type, so a diagnostic is required.
>
>> I know that C11 introduced "temporary lifetime" to cover cases
>> like this.  In C99, the wording for the indexing operator implicitly
>> assumes that there's an array object; if there isn't, I'd argue the
>> behavior is undefined by omission.  I'm not aware of any relevant
>> change from C90 to C99.
>
> The rule about conversions from arrays to pointers is different in C99
> (n1124 6.3.2.1, third paragraph) compared to C89.  In particular,
> "an lvalue that has type ``array of type'' ..." was changed to
> "an expression that has type ``array of type'' ...".

The best reference for C99 is n1256.  n1124 incorporates the official
C99 standard plus the first two Technical Corrigenda.  n1256 is similar,
but it incorporates all three TCs.

The change from "lvalue" to "expression" was made in C99.  I wonder why
that was done.  The semantics of indexing on a non-lvalue array
expression were not defined until C11.

BTW, you have a copy of ANSI C89?  Hard or soft copy?  Do you know if
it's still available in some form?  (I'd ask for a copy, but that would
almost certainly be a copyright violation.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */