Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #393106 > unrolled thread

Regarding assignment to struct

Back to article view | Back to comp.lang.c

Contents

  Regarding assignment to struct Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-05-02 18:34 +0000
    Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-02 13:17 -0700
    Re: Regarding assignment to struct Barry Schwarz <schwarzb@delq.com> - 2025-05-02 13:35 -0700
      That depends... (Was: Regarding assignment to struct) gazelle@shell.xmission.com (Kenny McCormack) - 2025-05-02 20:44 +0000
        Re: That depends... (Was: Regarding assignment to struct) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-05-03 01:13 +0000
          Re: That depends... (Was: Regarding assignment to struct) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-03 02:28 +0000
          Re: That depends... (Was: Regarding assignment to struct) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-03 06:17 +0200
          Re: That depends... (Was: Regarding assignment to struct) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-03 04:31 +0000
            Re: That depends... (Was: Regarding assignment to struct) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-03 05:11 +0000
              Re: That depends... (Was: Regarding assignment to struct) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-05 12:30 +0200
                Re: That depends... (Was: Regarding assignment to struct) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-05 18:47 +0000
            Re: That depends... (Was: Regarding assignment to struct) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 11:05 -0700
          Re: That depends... (Was: Regarding assignment to struct) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-03 00:47 -0400
          Re: That depends... (Was: Regarding assignment to struct) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 10:59 -0700
            Re: That depends... (Was: Regarding assignment to struct) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-05-04 18:16 +0000
    Re: Regarding assignment to struct antispam@fricas.org (Waldek Hebisch) - 2025-05-02 21:35 +0000
      Re: Regarding assignment to struct Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-05-03 01:43 +0000
    Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-03 01:14 -0700
      Re: Regarding assignment to struct Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-03 22:46 +0000
        Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-03 17:37 -0700
          Re: Regarding assignment to struct James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-03 23:38 -0400
            Re: Regarding assignment to struct gazelle@shell.xmission.com (Kenny McCormack) - 2025-05-04 09:25 +0000
            Re: Regarding assignment to struct scott@slp53.sl.home (Scott Lurndal) - 2025-05-04 14:27 +0000
              Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-04 18:45 +0200
            Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-04 13:20 -0700
              Re: Regarding assignment to struct scott@slp53.sl.home (Scott Lurndal) - 2025-05-05 00:41 +0000
                Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-04 18:42 -0700
                Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 21:57 -0700
              Re: Regarding assignment to struct James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-04 21:08 -0400
      Re: Regarding assignment to struct Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-03 22:47 +0000
      Re: Regarding assignment to struct Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-03 22:46 +0000
      Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 06:48 -0700
        Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-04 22:22 -0700
          Re: Regarding assignment to struct Michael S <already5chosen@yahoo.com> - 2025-05-05 11:12 +0300
            Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-05 01:29 -0700
              Re: Regarding assignment to struct Michael S <already5chosen@yahoo.com> - 2025-05-05 12:01 +0300
                Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 07:14 -0700
                Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-05 08:45 -0700
                  Re: Regarding assignment to struct Michael S <already5chosen@yahoo.com> - 2025-05-05 20:20 +0300
                    Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 22:26 -0700
                    Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-29 05:11 -0700
                    Re: Regarding assignment to struct James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-29 12:57 -0400
                  Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-05 13:27 -0700
                    Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 17:04 -0700
                      Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-05 17:53 -0700
                        Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 18:54 -0800
                          Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-01 19:36 -0800
                    Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-06 11:35 +0200
                      Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-29 05:19 -0700
                        Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-29 21:05 +0200
                    Re: Regarding assignment to struct antispam@fricas.org (Waldek Hebisch) - 2025-05-06 17:36 +0000
                      Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-06 20:46 +0200
                        Re: Regarding assignment to struct scott@slp53.sl.home (Scott Lurndal) - 2025-05-06 19:22 +0000
                          Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-07 09:37 +0200
                            Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-29 05:49 -0700
                              Re: Regarding assignment to struct Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-29 16:33 +0200
                              Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-29 21:20 +0200
                                Re: Regarding assignment to struct scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 21:15 +0000
                                  Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-29 14:54 -0700
                                    Re: Regarding assignment to struct scott@slp53.sl.home (Scott Lurndal) - 2025-05-30 14:29 +0000
                                  Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-30 10:50 +0200
                              Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-22 04:40 -0800
                      Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-06 13:06 -0700
                      Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-29 05:21 -0700
                        Re: Regarding assignment to struct Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-29 16:43 +0200
                        Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-06 17:44 -0700
                    Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-29 05:14 -0700
                      Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-29 13:56 -0700
            Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 07:03 -0700
          Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-05 01:26 -0700
            Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-05 10:14 -0700
              Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 12:45 -0700
                Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-08 22:20 +0200
          Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-05 01:34 -0700
            Re: Regarding assignment to struct Michael S <already5chosen@yahoo.com> - 2025-05-05 12:03 +0300
              Re: Regarding assignment to struct gazelle@shell.xmission.com (Kenny McCormack) - 2025-05-05 11:30 +0000
              Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-05 13:32 -0700
                Re: Regarding assignment to struct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-05 21:10 +0000
                  Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 22:57 -0700
              Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 22:40 -0700
            Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 06:34 -0700
              Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-05 13:43 -0700
                Re: Regarding assignment to struct Nick Bowler <nbowler@draconx.ca> - 2025-05-06 19:06 +0000
                  Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-06 13:21 -0700
                    Re: Regarding assignment to struct Nick Bowler <nbowler@draconx.ca> - 2025-05-07 19:09 +0000
                      Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-07 14:23 -0700
                        Re: Regarding assignment to struct Nick Bowler <nbowler@draconx.ca> - 2025-05-08 12:58 +0000
                      Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-07 21:17 -0700
                Re: Regarding assignment to struct Andrey Tarasevich <noone@noone.net> - 2025-05-29 05:36 -0700
                  Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-29 14:36 -0700
          Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 07:56 -0700
            Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-05 20:00 +0200
          Re: Regarding assignment to struct NotAorB <atod101101@gmail.com> - 2025-05-12 16:38 -0400
    Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-03 11:46 +0200
      Re: Regarding assignment to struct Muttley@dastardlyhq.com - 2025-05-05 08:50 +0000
        Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-05 13:34 +0200
        Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-05 13:53 -0700
          Re: Regarding assignment to struct Muttley@DastardlyHQ.org - 2025-05-06 07:16 +0000
          Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-06 11:46 +0200
            Re: Regarding assignment to struct Muttley@DastardlyHQ.org - 2025-05-06 10:18 +0000
          Re: Regarding assignment to struct Michael S <already5chosen@yahoo.com> - 2025-05-06 16:34 +0300
    Re: Regarding assignment to struct Richard Damon <richard@damon-family.org> - 2025-05-03 21:42 -0400
      Re: Regarding assignment to struct Michael S <already5chosen@yahoo.com> - 2025-05-04 11:01 +0300
        Re: Regarding assignment to struct Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-04 08:34 +0000
          Re: Regarding assignment to struct David Brown <david.brown@hesbynett.no> - 2025-05-04 14:06 +0200
        Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 21:25 -0700
        Re: Regarding assignment to struct Rosario19 <Ros@invalid.invalid> - 2025-05-12 11:23 +0200
    Re: Regarding assignment to struct Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 07:49 -0700
    Re: Regarding assignment to struct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-04 14:09 -0700

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#393174

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.  [*]

> (a = b) is an rvalue that refers to an object of type struct S with
> temporary lifetime.  pc holds the address of a subobject of that
> temporary object.  The object reaches the end of its lifetime at the end
> of the evaluation of the full expression.  You then print its value.

Even if the printf() statement were replaced by

   (void)pc;

the behavior would be undefined, because the pointer held in pc
becomes indeterminate as soon as the statement containing the
assignment to pc completes.


[*] Assuming C11 semantics.  At best inadvisable under C99
semantics, and a constraint violation under C90 semantics.

[toc] | [prev] | [next] | [standalone]

#393185

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.  [*]
>
>> (a = b) is an rvalue that refers to an object of type struct S with
>> temporary lifetime.  pc holds the address of a subobject of that
>> temporary object.  The object reaches the end of its lifetime at the end
>> of the evaluation of the full expression.  You then print its value.
>
> Even if the printf() statement were replaced by
>
>    (void)pc;
>
> the behavior would be undefined, because the pointer held in pc
> becomes indeterminate as soon as the statement containing the
> assignment to pc completes.

Agreed.

> [*] 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 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.

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

[toc] | [prev] | [next] | [standalone]

#393213

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'' ...".

[toc] | [prev] | [next] | [standalone]

#393216

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 */

[toc] | [prev] | [next] | [standalone]

#393236

On Tue, 06 May 2025 13:21:38 -0700, Keith Thompson wrote:
> Nick Bowler <nbowler@draconx.ca> writes:
>> 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 change from "lvalue" to "expression" was made in C99.  I wonder why
> that was done.

It's not mentioned in the rationale, so we can only guess.  But it is
called out in the list of major changes in the C99 foreword.

> BTW, you have a copy of ANSI C89?  Hard or soft copy?  Do you know if
> it's still available in some form?

Hint: look for FIPS 160 on the NIST website.  This is the same standard
as ANSI X3.159-1989 Programming Language - C.

[toc] | [prev] | [next] | [standalone]

#393238

Nick Bowler <nbowler@draconx.ca> writes:
> On Tue, 06 May 2025 13:21:38 -0700, Keith Thompson wrote:
>> Nick Bowler <nbowler@draconx.ca> writes:
>>> 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 change from "lvalue" to "expression" was made in C99.  I wonder why
>> that was done.
>
> It's not mentioned in the rationale, so we can only guess.  But it is
> called out in the list of major changes in the C99 foreword.

I've just looked at the foreword of the C99 standard and the n1256
draft, and I couldn't find it.  Can you quote the precise wording?

>> BTW, you have a copy of ANSI C89?  Hard or soft copy?  Do you know if
>> it's still available in some form?
>
> Hint: look for FIPS 160 on the NIST website.  This is the same standard
> as ANSI X3.159-1989 Programming Language - C.

<https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub160.pdf>
includes the 1989 ANSI C standard *and* the ANSI C Rationale.
Like many PDFs from that era, it's a scan from printed documents,
but it's still possible to copy-and-paste text from the PDF.

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

[toc] | [prev] | [next] | [standalone]

#393247

On Wed, 07 May 2025 14:23:57 -0700, Keith Thompson wrote:
> Nick Bowler <nbowler@draconx.ca> writes:
>> On Tue, 06 May 2025 13:21:38 -0700, Keith Thompson wrote:
>>> The change from "lvalue" to "expression" was made in C99.  I wonder why
>>> that was done.
>>
>> It's not mentioned in the rationale, so we can only guess.  But it is
>> called out in the list of major changes in the C99 foreword.
> 
> I've just looked at the foreword of the C99 standard and the n1256
> draft, and I couldn't find it.  Can you quote the precise wording?

N1256 page xiii.  Fourth to last bullet point:

  "-- conversion of array to pointer not limited to lvalues"

[toc] | [prev] | [next] | [standalone]

#393243

Nick Bowler <nbowler@draconx.ca> writes:

> On Tue, 06 May 2025 13:21:38 -0700, Keith Thompson wrote:
>
>> Nick Bowler <nbowler@draconx.ca> writes:
>>
>>> 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 change from "lvalue" to "expression" was made in C99.  I
>> wonder why that was done.
>
> It's not mentioned in the rationale, so we can only guess.  [...]

To me it seems obvious.  The change in C99 was meant to allow
access to an array inside a non-lvalue struct.  When C99 was
done the committee didn't realize all the ramifications of
accessing non-value structs (which apparently has problems
even for scalar members, not just array members).  Later, when
they did realize the resulting problems, they fixed things up
in C11.

See also n1253.htm, by Clark Nelson.

[toc] | [prev] | [next] | [standalone]

#393631

On Mon 5/5/2025 1:43 PM, Keith Thompson wrote:
> 
> 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.


The "constraint" in C89/90 is simply the fact that C89/90 _requires_ an 
lvalue (of array type) in order to apply array to pointer conversion. 
Here's is the original wording:

   Except when it is the operand of the sizeof operator or the unary & 
operator, or is a character string literal used to initialize an array 
of character type, or is a wide string literal used to initialize an 
array with element type compatible with wchar-t, an *lvalue* that has 
type “array of type” is converted to an expression that has type 
“pointer to rype” that points to the initial element of the array object 
and is not an lvalue.

The presence of that "*lvalue*" requirement is what prevented up from 
using `[]` operator on non-lvalue arrays in C89/90, because `[]` 
critically relies on that conversion.

In C11 the wording has changed:

   Except when it is the operand of the sizeof operator, the _Alignof 
operator, or the unary & operator, or is a string literal used to 
initialize an array, an expression that has type ‘‘array of type’’ is 
converted to an expression with type ‘‘pointer to type’’ that points to 
the initial element of the array object and is not an lvalue. If the 
array object has register storage class, the behavior is undefined.

Note that the "lvalue" requirement has disappeared from this wording. 
That is exactly why since C99 we can apply `[]` to non-lvalue arrays.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#393658

Andrey Tarasevich <noone@noone.net> writes:
> On Mon 5/5/2025 1:43 PM, Keith Thompson wrote:
>> 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.
>
> The "constraint" in C89/90 is simply the fact that C89/90 _requires_
> an lvalue (of array type) in order to apply array to pointer
> conversion. Here's is the original wording:
>
>   Except when it is the operand of the sizeof operator or the unary &
>   operator, or is a character string literal used to initialize an
>   array of character type, or is a wide string literal used to
>   initialize an array with element type compatible with wchar-t, an
>   *lvalue* that has type “array of type” is converted to an expression
>   that has type “pointer to rype” that points to the initial element
>   of the array object and is not an lvalue.
>
> The presence of that "*lvalue*" requirement is what prevented up from
> using `[]` operator on non-lvalue arrays in C89/90, because `[]`
> critically relies on that conversion.
>
> In C11 the wording has changed:
>
>   Except when it is the operand of the sizeof operator, the _Alignof
>   operator, or the unary & operator, or is a string literal used to
>   initialize an array, an expression that has type ‘‘array of type’’
>   is converted to an expression with type ‘‘pointer to type’’ that
>   points to the initial element of the array object and is not an
>   lvalue. If the array object has register storage class, the behavior
>  is undefined.
>
> Note that the "lvalue" requirement has disappeared from this
> wording. That is exactly why since C99 we can apply `[]` to non-lvalue
> arrays.

Yes, this was discussed in this thread several weeks ago.

A quibble: There are no implicit constraints.  All constraints
are in sections clearly marked "Constraints".  I believe that the
C90 constraint that's violated by `(a = b).a[5]` is the one that
requires the operands of [] to have pointer and integer types.
Since `(a = b).a` does not undergo array-to-pointer conversion
*in C90*, it's of array type.

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

[toc] | [prev] | [next] | [standalone]

#393177

Andrey Tarasevich <noone@noone.net> writes:

> On Sun 5/4/2025 6:48 AM, Tim Rentsch wrote:
>
>>> One dark corner this feature has, is that in C (as opposed to C++) the
>>> result of an assignment operator is an rvalue, which can easily lead
>>> to some interesting consequences related to structs with arrays
>>> inside.
>>
>> I'm curious to know what interesting consequences you mean here.  Do
>> you mean something other than cases that have undefined behavior?
>
> I'm referring to the matter of the address identity of the resultant
> rvalue object.  At first, "address identity of rvalue" might sound
> strange, but the standard says that there's indeed an object tied to
> such rvalue, and once we start applying array-to-pointer conversion
> (and use `[]` operator), lvalues and addresses quickly come into the
> picture.
>
> The standard says in 6.2.4/8:
>
> "A non-lvalue expression with structure or union type, where the
> structure or union contains a member with array type [...]
> refers to an object with automatic storage duration and temporary
> lifetime.  Its lifetime begins when the expression is evaluated and its
> initial value is the value of the expression.  Its lifetime ends when
> the evaluation of the containing full expression ends.  [...] Such an
> object need not have a unique address."
> https://port70.net/~nsz/c/c11/n1570.html#6.2.4p8

The last sentence there is not present in N1570.  Apparently it was
introduced later, in C17.  (My appreciation to Keith Thompson for
reporting this.)

> I wondering what the last sentence is intended to mean ("... need not
> have a unique address").  At the first sight, the intent seems to be
> obvious:  it simply says that such temporary objects might repeatedly
> appear (and disappear) at the same location in storage, which is a
> natural thing to expect.

Ahh, I see now what your concern is.

> But is it, perhaps, intended to also allow such temporaries to have
> addresses identical to regular named objects?  It is not immediately
> clear to me.

My reading of the post-C11 standards is that they allow the "new"
object to overlap with already existing objects, including both
declared objects and objects whose storage was allocated using
malloc().

> And when I make the following experiment with GCC and Clang
>
>   #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 consistently get the following output from GCC
>
>   0x7fff73eb5544 0x7fff73eb5574 0x7fff73eb5544
>
> And this is what I get from Clang
>
>   0x7ffd2b8dbf44 0x7ffd2b8dbf14 0x7ffd2b8dbee4
>
> As you can see, GCC apparently took C++-like approach to this
> situation.  The returned "temporary" is not really a separate temporary
> at all, but actually `a` itself.

Yeah.

> Meanwhile, in Clang all three pointers are different, i.e. Clang
> decided to actually create a separate temporary object for the result
> of the assignment.

Which in my reading of the standard is required under C11 rules.
I have reproduced your results under -std=c11 -pedantic, for both
gcc and clang.

> I have a strong feeling that GCC's behavior is non-conforming.  The
> last sentence of 6.2.4/8 is not supposed to permit "projecting" the
> resultant temporaries onto existing named objects.  I could be wrong...

My judgment is that the behavior under gcc is non-conforming if the
compilation was done using C11 semantics.  Under C17 or later rules
the gcc behavior is allowed (and may have been what prompted the
change in C17, but that is just speculation on my part).  In any
case I understand now what you were getting at.  Thank you for
bringing this hazard to the group's attention.

I hope someone files a bug report for gcc using -std=c11 rules,
because what gcc does under that setting (along with -pedantic)
is surely at odds with the plain reading of the C11 standard,
for the situation being discussed here.

Editorial comment:  here is yet another case where post-C11 changes
to the C standard seem ill advised, and another reason not to use
any version of the ISO C standard for C17 or later.  And it's
disappointing that gcc -std=c11 -pedantic strays into the realm of
non-conforming behavior.

[toc] | [prev] | [next] | [standalone]

#393181

On 05/05/2025 16:56, Tim Rentsch wrote:
> Andrey Tarasevich <noone@noone.net> writes:
> 
>> On Sun 5/4/2025 6:48 AM, Tim Rentsch wrote:
>>
>>>> One dark corner this feature has, is that in C (as opposed to C++) the
>>>> result of an assignment operator is an rvalue, which can easily lead
>>>> to some interesting consequences related to structs with arrays
>>>> inside.
>>>
>>> I'm curious to know what interesting consequences you mean here.  Do
>>> you mean something other than cases that have undefined behavior?
>>
>> I'm referring to the matter of the address identity of the resultant
>> rvalue object.  At first, "address identity of rvalue" might sound
>> strange, but the standard says that there's indeed an object tied to
>> such rvalue, and once we start applying array-to-pointer conversion
>> (and use `[]` operator), lvalues and addresses quickly come into the
>> picture.
>>
>> The standard says in 6.2.4/8:
>>
>> "A non-lvalue expression with structure or union type, where the
>> structure or union contains a member with array type [...]
>> refers to an object with automatic storage duration and temporary
>> lifetime.  Its lifetime begins when the expression is evaluated and its
>> initial value is the value of the expression.  Its lifetime ends when
>> the evaluation of the containing full expression ends.  [...] Such an
>> object need not have a unique address."
>> https://port70.net/~nsz/c/c11/n1570.html#6.2.4p8
> 
> The last sentence there is not present in N1570.  Apparently it was
> introduced later, in C17.  (My appreciation to Keith Thompson for
> reporting this.)
> 
>> I wondering what the last sentence is intended to mean ("... need not
>> have a unique address").  At the first sight, the intent seems to be
>> obvious:  it simply says that such temporary objects might repeatedly
>> appear (and disappear) at the same location in storage, which is a
>> natural thing to expect.
> 
> Ahh, I see now what your concern is.
> 
>> But is it, perhaps, intended to also allow such temporaries to have
>> addresses identical to regular named objects?  It is not immediately
>> clear to me.
> 
> My reading of the post-C11 standards is that they allow the "new"
> object to overlap with already existing objects, including both
> declared objects and objects whose storage was allocated using
> malloc().
> 
>> And when I make the following experiment with GCC and Clang
>>
>>    #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 consistently get the following output from GCC
>>
>>    0x7fff73eb5544 0x7fff73eb5574 0x7fff73eb5544
>>
>> And this is what I get from Clang
>>
>>    0x7ffd2b8dbf44 0x7ffd2b8dbf14 0x7ffd2b8dbee4
>>
>> As you can see, GCC apparently took C++-like approach to this
>> situation.  The returned "temporary" is not really a separate temporary
>> at all, but actually `a` itself.
> 
> Yeah.
> 
>> Meanwhile, in Clang all three pointers are different, i.e. Clang
>> decided to actually create a separate temporary object for the result
>> of the assignment.
> 
> Which in my reading of the standard is required under C11 rules.
> I have reproduced your results under -std=c11 -pedantic, for both
> gcc and clang.
> 

Compilers don't have to follow the behaviour specified by the standard 
in a "direct translation" manner in order to be correct and conforming. 
They have to generate code that in the absence of any attempt to execute 
something with undefined behaviour, will give the same observable 
behaviour as a "direct translation" would.

The result of the "(a = b)" expression should be a temporary object 
distinct from "a" and "b", with a lifetime extending only to the end of 
the expression assigning to "pc" (prior to C17).

Is there any way to distinguish between "pc" pointing to an int inside 
this now dead temporary object, and it pointing to an int inside "a", 
without invoking undefined behaviour?

By the time you are using "pc" to print it, the pointer itself has an 
indeterminate value - the compiler can quite happily give it the same 
value as "pa", so looking at the pointer in the printf() statement does 
not show a non-conformance.

Attempting to modify the temporary lifetime object, such as by writing 
"*(pc = &(a = b).a[5]) = 42;", is undefined behaviour.

It is entirely possible that there /is/ some way to determine that the 
compiler is not making a distinct temporary object while avoiding any 
undefined behaviour or indeterminate values.  But I don't think the code 
here does show that - and it is therefore not an example of 
non-conforming behaviour.  I think GCC and clang can be viewed as having 
simply picked different ways to generate their indeterminate values.

I will be happy to change that opinion if someone has a better argument 
or example.


>> I have a strong feeling that GCC's behavior is non-conforming.  The
>> last sentence of 6.2.4/8 is not supposed to permit "projecting" the
>> resultant temporaries onto existing named objects.  I could be wrong...
> 
> My judgment is that the behavior under gcc is non-conforming if the
> compilation was done using C11 semantics.  Under C17 or later rules
> the gcc behavior is allowed (and may have been what prompted the
> change in C17, but that is just speculation on my part).  In any
> case I understand now what you were getting at.  Thank you for
> bringing this hazard to the group's attention.
> 
> I hope someone files a bug report for gcc using -std=c11 rules,
> because what gcc does under that setting (along with -pedantic)
> is surely at odds with the plain reading of the C11 standard,
> for the situation being discussed here.
> 
> Editorial comment:  here is yet another case where post-C11 changes
> to the C standard seem ill advised, and another reason not to use
> any version of the ISO C standard for C17 or later.  And it's
> disappointing that gcc -std=c11 -pedantic strays into the realm of
> non-conforming behavior.

[toc] | [prev] | [next] | [standalone]

#393362

Looks good!

[toc] | [prev] | [next] | [standalone]

#393119

On 02/05/2025 20:34, Lew Pitcher wrote:
> Back in the days of K&R, Kernighan and Ritchie published an addendum
> to the "C Reference Manual" titled "Recent Changes to C" (November 1978)
> in which they detailed some differences in the C language post "The
> C Programming Language".
> 
> The first difference they noted was that
>    "Structures may be assigned, passed as arguments to functions, and
>     returned by functions."
> 
>  From what I can see of the ISO C standards, the current C language
> has kept these these features. However, I don't see many C projects
> using them.


I use these features regularly.  I have no problem passing structs 
around if that is the convenient way to structure the code.

Some people mistakenly think that it is very inefficient, in comparison 
to passing around pointers to structs (which is the usual alternative). 
There are circumstances where you might end up with an extra struct and 
an extra copy, but unless you are dealing with very big structs and 
otherwise very fast functions, it's unlikely to be significant.  Modern 
ABI's support passing small structs around in registers, and bigger 
structs get passed around using hidden pointers - using the structs in 
your code, rather than pointers to structs, makes the code clearer, 
safer, and gives the optimiser more information for better static 
analysis and code generation.

> 
> I have a project in which these capabilities might come in handy; has
> anyone had experience with assigning to structures, passing them as
> arguments to functions, and/or having a function return a structure?
> 
> Would code like
>    struct ab {
>      int a;
>      char *b;
>    } result, function(void);
> 
>    if ((result = function()).a == 10) puts(result.b);
> 
> be understandable, or even legal?
> 

I'd immediately reject any code that mixes declaration of a variable and 
a function in the same declaration.  I'd immediately reject any code 
that defines a type and declares a function in one shot.  I'd question 
code that defines a type and a variable in one go.  But that's my way of 
coding - other people have different rules, and your declarations are legal.

Personally, I'd have :

	typedef struct {
		int a;
		char * b;
	} ab;

	ab result;

	ab function(void);
	
(Obviously "ab" would not be a likely name in real code.)

Once the type "ab" is defined, I am quite happy making variables of it, 
assigning them, and using it for function parameters and return types.

[toc] | [prev] | [next] | [standalone]

#393167

On Sat, 3 May 2025 11:46:30 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 02/05/2025 20:34, Lew Pitcher wrote:
>> Back in the days of K&R, Kernighan and Ritchie published an addendum
>> to the "C Reference Manual" titled "Recent Changes to C" (November 1978)
>> in which they detailed some differences in the C language post "The
>> C Programming Language".
>> 
>> The first difference they noted was that
>>    "Structures may be assigned, passed as arguments to functions, and
>>     returned by functions."
>> 
>>  From what I can see of the ISO C standards, the current C language
>> has kept these these features. However, I don't see many C projects
>> using them.
>
>
>I use these features regularly.  I have no problem passing structs 
>around if that is the convenient way to structure the code.

If you twant o pass an actual array to a function instead of a pointer to it,
embedding it in a structure is the only way to do it. 

[toc] | [prev] | [next] | [standalone]

#393173

On 05/05/2025 10:50, Muttley@dastardlyhq.com wrote:
> On Sat, 3 May 2025 11:46:30 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 02/05/2025 20:34, Lew Pitcher wrote:
>>> Back in the days of K&R, Kernighan and Ritchie published an addendum
>>> to the "C Reference Manual" titled "Recent Changes to C" (November 1978)
>>> in which they detailed some differences in the C language post "The
>>> C Programming Language".
>>>
>>> The first difference they noted was that
>>>    "Structures may be assigned, passed as arguments to functions, and
>>>     returned by functions."
>>>
>>>  From what I can see of the ISO C standards, the current C language
>>> has kept these these features. However, I don't see many C projects
>>> using them.
>>
>>
>> I use these features regularly.  I have no problem passing structs 
>> around if that is the convenient way to structure the code.
> 
> If you twant o pass an actual array to a function instead of a pointer 
> to it,
> embedding it in a structure is the only way to do it.

Yes.

(Well, you could embed it in a union if you prefer, but a struct seems 
more likely.)

[toc] | [prev] | [next] | [standalone]

#393186

Muttley@dastardlyhq.com writes:
[...]
> If you twant o pass an actual array to a function instead of a pointer to it,
> embedding it in a structure is the only way to do it. 

Yes, but that's not necessarily useful.  An array that's a member
of a struct can only be of a constant length (unless it's a flexible
array member, but that doesn't help).  Functions that work with
arrays typically need to deal with arrays of arbitrary length.

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

[toc] | [prev] | [next] | [standalone]

#393201

On Mon, 05 May 2025 13:53:10 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wibbled:
>Muttley@dastardlyhq.com writes:
>[...]
>> If you twant o pass an actual array to a function instead of a pointer to it,
>
>> embedding it in a structure is the only way to do it. 
>
>Yes, but that's not necessarily useful.  An array that's a member

Depends what you're doing. Passing an array in a structure will copy the array 
saving you having to do it yourself if you don't want to work on the original
version. Obviously that doesn't happen if you just pass a pointer.

[toc] | [prev] | [next] | [standalone]

#393204

On 05/05/2025 22:53, Keith Thompson wrote:
> Muttley@dastardlyhq.com writes:
> [...]
>> If you twant o pass an actual array to a function instead of a pointer to it,
>> embedding it in a structure is the only way to do it.
> 
> Yes, but that's not necessarily useful.  An array that's a member
> of a struct can only be of a constant length (unless it's a flexible
> array member, but that doesn't help).  Functions that work with
> arrays typically need to deal with arrays of arbitrary length.
> 

I regularly use arrays with known fixed sizes.  In fact, in my code 
those are absolutely dominant - it is very rare for me to see or use an 
array whose size is /not/ fixed at compile time.  Sometimes I will have 
general functions that take parameters that are arrays of arbitrary 
length, but not often.

So this is very much dependent on the kind of code you are working with, 
and other people will have very different experiences for their own code.

However, I think it is not unlikely that people will see use of structs 
like :

	struct vector4int { int vs[4]; };

[toc] | [prev] | [next] | [standalone]

#393205

On Tue, 6 May 2025 11:46:21 +0200
David Brown <david.brown@hesbynett.no> wibbled:
>On 05/05/2025 22:53, Keith Thompson wrote:
>> Muttley@dastardlyhq.com writes:
>> [...]
>>> If you twant o pass an actual array to a function instead of a pointer to
>it,
>>> embedding it in a structure is the only way to do it.
>> 
>> Yes, but that's not necessarily useful.  An array that's a member
>> of a struct can only be of a constant length (unless it's a flexible
>> array member, but that doesn't help).  Functions that work with
>> arrays typically need to deal with arrays of arbitrary length.
>> 
>
>I regularly use arrays with known fixed sizes.  In fact, in my code 
>those are absolutely dominant - it is very rare for me to see or use an 
>array whose size is /not/ fixed at compile time.  Sometimes I will have 

I do a lot of networking code and with packet structures the arrays are
almost always of fixed size. Also with arrays the data is inline so a simple
memcpy() can copy the data from the struct to the output buffer. You can't
do that if you have pointers in the struct. Ditto a simple cast to char * to
use it directly as the ouput.

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web