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 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#393627

On Mon 5/5/2025 10:20 AM, Michael S wrote:
>>
>> Here's a version of the same code that corrects the above distracting
>> issues
>>
>>     #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", (void *) pa, (void *) pb, (void *) pc);
>>     }
>>
>> This version has no UB.
>>
> 
> It's only not UB in the nazal demons sense.
> It's UB in a sense that we can't predict values of expressions
> like (pa==pc) and (pb==pc). I.e. pc is completely useless. In my book
> it is form of UB.

Whether we can or cannot predict the values of `(pa==pc)` and `(pb==pc)` 
has very little impact on the usability of such expressions. The 
practical usability of such expressions is very high without relying on 
`(pa==pc)` and `(pb==pc)`.

-- 
Best regards,
Andrey

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

#393642

On Mon 5/5/2025 10:20 AM, Michael S wrote:
>>
>> Here's a version of the same code that corrects the above distracting
>> issues
>>
>>     #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", (void *) pa, (void *) pb, (void *) pc);
>>     }
>>
>> This version has no UB.
>>
> 
> It's only not UB in the nazal demons sense.

UB is UB only in the nasal demons sense. UB means that "This
international standard imposes no requirements on the behavior". That
is, anything could happen, at least as far as the standard is concerned.
Code with undefined behavior should not be able to produce nasal demons
because there's no such thing as nasal demons (I think). However, if
they did exist, producing them would not violate any requirements
imposed by the standard, because it quite explicitly imposes none on
such code.

> It's UB in a sense that we can't predict values of expressions
> like (pa==pc) and (pb==pc). ...

Why not? Because of the comma operators, the lifetime of the temporary
extends all the way till the end of the printf() call, long enough to
make use of pc in that call safe.

> ... I.e. pc is completely useless. In my book
> it is form of UB.

If the problem were only that there's no restrictions on the value of an
expression, but that the code is otherwise safe to use, that would be
indicated by a much weaker term: "unspecified value".  Calling it "a
form of UB" would serve no useful purpose.

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

#393183

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", (void *) pa, (void *) pb, (void *) pc);
>   }
>
> This version has no UB.

I believe it does.  pc points to an element of an object with
temporary lifetime.  The value of pc is then used after the object
it points to has reached the end of its lifetime.  At that point,
pc has an indeterminate value.

N3096 6.2.4p2: "If a pointer value is used in an evaluation after
the object the pointer points to (or just past) reaches the end of
its lifetime, the behavior is undefined. The representation of a
pointer object becomes indeterminate when the object the pointer
points to (or just past) reaches the end of its lifetime."

-- 
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]

#393194

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", (void *) pa, (void *) pb, (void *) pc);
>>   }
>>
>> This version has no UB.
>
> I believe it does.  [...]

If you look again carefully, I expect you will reach a
different conclusion.

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

#393195

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", (void *) pa, (void *) pb, (void *) pc);
>>>   }
>>>
>>> This version has no UB.
>>
>> I believe it does.  [...]
>
> If you look again carefully, I expect you will reach a
> different conclusion.

Please explain.  Or don't.

I explained, in text that you snipped, why I think it has UB.
If there's a flaw in my reasoning, I invite you to point it out
without being mysterious.

-- 
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]

#396714

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:
>>
>>> 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", (void *) pa, (void *) pb, (void *) pc);
>>>>   }
>>>>
>>>> This version has no UB.
>>>
>>> I believe it does.  [...]
>>
>> If you look again carefully, I expect you will reach a
>> different conclusion.
>
> Please explain.  Or don't.
>
> I explained, in text that you snipped, why I think it has UB.
> If there's a flaw in my reasoning, I invite you to point it out
> without being mysterious.

I wasn't thinking about your reasoning or what flaw there may have
been in it.  My intention was to suggest a course of action that
would be helpful rather than to point out any sort of mistake.  But
since you ask, I think the mistake you made was jumping to a
conclusion without looking carefully enough at the problem.

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

#396716

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:
>>>> 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", (void *) pa, (void *) pb, (void *) pc);
>>>>>   }
>>>>>
>>>>> This version has no UB.
>>>>
>>>> I believe it does.  [...]
>>>
>>> If you look again carefully, I expect you will reach a
>>> different conclusion.
>>
>> Please explain.  Or don't.
>>
>> I explained, in text that you snipped, why I think it has UB.
>> If there's a flaw in my reasoning, I invite you to point it out
>> without being mysterious.
>
> I wasn't thinking about your reasoning or what flaw there may have
> been in it.  My intention was to suggest a course of action that
> would be helpful rather than to point out any sort of mistake.  But
> since you ask, I think the mistake you made was jumping to a
> conclusion without looking carefully enough at the problem.

The mistake I made was failing to notice that the line with the
assignment to pc ends with a comma operator rather than a semicolon.

The code was deliberately obfuscated, and I fell for it.

I acknowledged that nearly a year ago.  Why bring it up now?
I find it extremely annoying.

-- 
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]

#393203

On 05/05/2025 22:27, Keith Thompson wrote:
> 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", (void *) pa, (void *) pb, (void *) pc);
>>    }
>>
>> This version has no UB.
> 
> I believe it does.  pc points to an element of an object with
> temporary lifetime.  The value of pc is then used after the object
> it points to has reached the end of its lifetime.  At that point,
> pc has an indeterminate value.
> 
> N3096 6.2.4p2: "If a pointer value is used in an evaluation after
> the object the pointer points to (or just past) reaches the end of
> its lifetime, the behavior is undefined. The representation of a
> pointer object becomes indeterminate when the object the pointer
> points to (or just past) reaches the end of its lifetime."
> 

It seems clear to me that "pc" has an indeterminate value after the 
expression assigning, since it points to an object with temporary lifetime.

And attempting to use the value of an object with automatic storage 
while it has an indeterminate value is undefined behaviour.

As far as I can see, simply reading the value in "pc" to print it out is 
UB according to the C standards.  It is clearly going to be a harmless 
operation on most hardware, but there are processors where pointer 
registers are more complicated than simple linear addresses - they can 
track some kind of segment structure describing the range of a data 
block, or permissions for access to the data, and such structures could 
have been deactivated or deallocated when the temporary lifetime object 
died.  Even attempting to read the value of the pointer, without 
dereferencing it, would then cause some kind of fault or trap.

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

#393629

On Tue 5/6/2025 2:35 AM, David Brown wrote:
>>
>> N3096 6.2.4p2: "If a pointer value is used in an evaluation after
>> the object the pointer points to (or just past) reaches the end of
>> its lifetime, the behavior is undefined. The representation of a
>> pointer object becomes indeterminate when the object the pointer
>> points to (or just past) reaches the end of its lifetime."
>>
> 
> It seems clear to me that "pc" has an indeterminate value after the 
> expression assigning, since it points to an object with temporary lifetime.
> 
> And attempting to use the value of an object with automatic storage 
> while it has an indeterminate value is undefined behaviour.

Again, this makes no sense. Please, pay attention to the code and the 
corrections made after the initial version (e.g. usage of comma 
operator). No, the value of `pc` is not indeterminate, and no, there's 
no undefined behavior in the above version of the code.

> As far as I can see, simply reading the value in "pc" to print it out is 
> UB according to the C standards.  It is clearly going to be a harmless 
> operation on most hardware, but there are processors where pointer 
> registers are more complicated than simple linear addresses - they can 
> track some kind of segment structure describing the range of a data 
> block, or permissions for access to the data, and such structures could 
> have been deactivated or deallocated when the temporary lifetime object 
> died.  Even attempting to read the value of the pointer, without 
> dereferencing it, would then cause some kind of fault or trap.

Again, irrelevant. In the above code the temporary object does not die 
during the entire period when pointer `pc` is used in any way.

-- 
Best regards,
Andrey

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

#393646

On 29/05/2025 14:19, Andrey Tarasevich wrote:
> On Tue 5/6/2025 2:35 AM, David Brown wrote:
>>>
>>> N3096 6.2.4p2: "If a pointer value is used in an evaluation after
>>> the object the pointer points to (or just past) reaches the end of
>>> its lifetime, the behavior is undefined. The representation of a
>>> pointer object becomes indeterminate when the object the pointer
>>> points to (or just past) reaches the end of its lifetime."
>>>
>>
>> It seems clear to me that "pc" has an indeterminate value after the 
>> expression assigning, since it points to an object with temporary 
>> lifetime.
>>
>> And attempting to use the value of an object with automatic storage 
>> while it has an indeterminate value is undefined behaviour.
> 
> Again, this makes no sense. Please, pay attention to the code and the 
> corrections made after the initial version (e.g. usage of comma 
> operator). No, the value of `pc` is not indeterminate, and no, there's 
> no undefined behavior in the above version of the code.
> 
>> As far as I can see, simply reading the value in "pc" to print it out 
>> is UB according to the C standards.  It is clearly going to be a 
>> harmless operation on most hardware, but there are processors where 
>> pointer registers are more complicated than simple linear addresses - 
>> they can track some kind of segment structure describing the range of 
>> a data block, or permissions for access to the data, and such 
>> structures could have been deactivated or deallocated when the 
>> temporary lifetime object died.  Even attempting to read the value of 
>> the pointer, without dereferencing it, would then cause some kind of 
>> fault or trap.
> 
> Again, irrelevant. In the above code the temporary object does not die 
> during the entire period when pointer `pc` is used in any way.
> 

I posted later that I had made a mistake, and not noticed the use of the 
comma instead of a semicolon.

Why are you dredging up an outdated thread?  I made an error three weeks 
ago, and realised the mistake shortly afterwards.  What do you expect me 
or anyone else to learn from that now, after all this time?

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

#393210

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 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", (void *) pa, (void *) pb, (void *) pc);
>>   }
>>
>> This version has no UB.
> 
> I believe it does.  pc points to an element of an object with
> temporary lifetime.  The value of pc is then used after the object
> it points to has reached the end of its lifetime.  At that point,
> pc has an indeterminate value.
> 
> N3096 6.2.4p2: "If a pointer value is used in an evaluation after
> the object the pointer points to (or just past) reaches the end of
> its lifetime, the behavior is undefined. The representation of a
> pointer object becomes indeterminate when the object the pointer
> points to (or just past) reaches the end of its lifetime."

Note commas above.  Assignment to pc and call to printf are parts
of a single expression, so use of pc is within lifetime of the
temporary object.

-- 
                              Waldek Hebisch

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

#393212

On 06/05/2025 19:36, Waldek Hebisch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> 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", (void *) pa, (void *) pb, (void *) pc);
>>>    }
>>>
>>> This version has no UB.
>>
>> I believe it does.  pc points to an element of an object with
>> temporary lifetime.  The value of pc is then used after the object
>> it points to has reached the end of its lifetime.  At that point,
>> pc has an indeterminate value.
>>
>> N3096 6.2.4p2: "If a pointer value is used in an evaluation after
>> the object the pointer points to (or just past) reaches the end of
>> its lifetime, the behavior is undefined. The representation of a
>> pointer object becomes indeterminate when the object the pointer
>> points to (or just past) reaches the end of its lifetime."
> 
> Note commas above.  Assignment to pc and call to printf are parts
> of a single expression, so use of pc is within lifetime of the
> temporary object.
> 

I must admit I had not noticed that detail.

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

#393214

David Brown <david.brown@hesbynett.no> writes:
>On 06/05/2025 19:36, Waldek Hebisch wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> 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", (void *) pa, (void *) pb, (void *) pc);
>>>>    }
>>>>
>>>> This version has no UB.
>>>
>>> I believe it does.  pc points to an element of an object with
>>> temporary lifetime.  The value of pc is then used after the object
>>> it points to has reached the end of its lifetime.  At that point,
>>> pc has an indeterminate value.
>>>
>>> N3096 6.2.4p2: "If a pointer value is used in an evaluation after
>>> the object the pointer points to (or just past) reaches the end of
>>> its lifetime, the behavior is undefined. The representation of a
>>> pointer object becomes indeterminate when the object the pointer
>>> points to (or just past) reaches the end of its lifetime."
>> 
>> Note commas above.  Assignment to pc and call to printf are parts
>> of a single expression, so use of pc is within lifetime of the
>> temporary object.
>> 
>
>I must admit I had not noticed that detail.

That would get an immediate downcheck during review for exactly
that reason.

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

#393223

On 06/05/2025 21:22, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 06/05/2025 19:36, Waldek Hebisch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> 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", (void *) pa, (void *) pb, (void *) pc);
>>>>>     }
>>>>>
>>>>> This version has no UB.
>>>>
>>>> I believe it does.  pc points to an element of an object with
>>>> temporary lifetime.  The value of pc is then used after the object
>>>> it points to has reached the end of its lifetime.  At that point,
>>>> pc has an indeterminate value.
>>>>
>>>> N3096 6.2.4p2: "If a pointer value is used in an evaluation after
>>>> the object the pointer points to (or just past) reaches the end of
>>>> its lifetime, the behavior is undefined. The representation of a
>>>> pointer object becomes indeterminate when the object the pointer
>>>> points to (or just past) reaches the end of its lifetime."
>>>
>>> Note commas above.  Assignment to pc and call to printf are parts
>>> of a single expression, so use of pc is within lifetime of the
>>> temporary object.
>>>
>>
>> I must admit I had not noticed that detail.
> 
> That would get an immediate downcheck during review for exactly
> that reason.

Of course.  In fact, if someone presented such code for review (and 
assuming I noticed the commas!) I'd have to consider whether it was done 
maliciously, intentionally deceptively, due to incompetence, or 
smart-arse coding.  In all my C coding experience, I can't recall ever 
coming across a single situation when I thought the use of the comma 
operator was appropriate in the kind of code I work with.

Other people, projects, and teams work with different standards, 
different requirements, and different kinds of code - there are a lot of 
things that are common practice in some C coding that are strongly 
rejected in my field (and perhaps vice versa).  So I am not suggesting 
that the comma operator is always bad in C - just that it is pretty much 
always bad in my line of work.

And of course Andrey was using it here to make a specific point in a 
discussion about C details, rather than real-life code.

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

#393634

On Wed 5/7/2025 12:37 AM, David Brown wrote:
>>
>> That would get an immediate downcheck during review for exactly
>> that reason.
> 
> Of course.  In fact, if someone presented such code for review (and 
> assuming I noticed the commas!) I'd have to consider whether it was done 
> maliciously, intentionally deceptively, due to incompetence, or smart- 
> arse coding.  In all my C coding experience, I can't recall ever coming 
> across a single situation when I thought the use of the comma operator 
> was appropriate in the kind of code I work with.

Wow! That's catastrophically bad.

As it has been stated many times before, both C and C++ are programming 
languages that embrace both statement-level and expression-level 
programming. Expression-level programming (e.g. where `?:` is used for 
branching and `,` for sequencing) is a very valuable and massively 
important programming paradigm in these languages. The fact that 
elaborate expression-level programming is not in nay way abandoned or 
shunned today is pretty obvious in C++, since C++ took major steps 
lately to develop its expression-level capabilities. But it has always 
been and will always remain important in C as well.

The proclivity to stick exclusively to statement-level programming in C 
and, God forbid, impose it in others through so called "code reviews"... 
that would be a trait specific to "sweatshop" development outfits, which 
strive to replace quality with quantity. I'd agree that in a revolving 
door employment environment relying on a large number of low-competence 
developers such code might be seen as "too confusing". But I don't see 
why we should set our standards that low here, in `comp.lang.c`.

-- 
Best regards,
Andrey

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

#393635

On 29.05.2025 14:49, Andrey Tarasevich wrote:
> On Wed 5/7/2025 12:37 AM, David Brown wrote:
>>>
>>> That would get an immediate downcheck during review for exactly
>>> that reason.
>>
>> Of course.  In fact, if someone presented such code for review (and
>> assuming I noticed the commas!) I'd have to consider whether it was
>> done maliciously, intentionally deceptively, due to incompetence, or
>> smart- arse coding.  In all my C coding experience, I can't recall
>> ever coming across a single situation when I thought the use of the
>> comma operator was appropriate in the kind of code I work with.
> 
> Wow! That's catastrophically bad.
> 
> As it has been stated many times before, both C and C++ are programming
> languages that embrace both statement-level and expression-level
> programming. Expression-level programming (e.g. where `?:` is used for
> branching and `,` for sequencing) is a very valuable and massively
> important programming paradigm in these languages. The fact that
> elaborate expression-level programming is not in nay way abandoned or
> shunned today is pretty obvious in C++, since C++ took major steps
> lately to develop its expression-level capabilities. But it has always
> been and will always remain important in C as well.
> 
> The proclivity to stick exclusively to statement-level programming in C
> and, God forbid, impose it in others through so called "code reviews"...
> that would be a trait specific to "sweatshop" development outfits, which
> strive to replace quality with quantity. I'd agree that in a revolving
> door employment environment relying on a large number of low-competence
> developers such code might be seen as "too confusing". But I don't see
> why we should set our standards that low here, in `comp.lang.c`.

Well said.

Janis

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

#393647

On 29/05/2025 14:49, Andrey Tarasevich wrote:
> On Wed 5/7/2025 12:37 AM, David Brown wrote:
>>>
>>> That would get an immediate downcheck during review for exactly
>>> that reason.
>>
>> Of course.  In fact, if someone presented such code for review (and 
>> assuming I noticed the commas!) I'd have to consider whether it was 
>> done maliciously, intentionally deceptively, due to incompetence, or 
>> smart- arse coding.  In all my C coding experience, I can't recall 
>> ever coming across a single situation when I thought the use of the 
>> comma operator was appropriate in the kind of code I work with.
> 
> Wow! That's catastrophically bad.
> 
> As it has been stated many times before, both C and C++ are programming 
> languages that embrace both statement-level and expression-level 
> programming. Expression-level programming (e.g. where `?:` is used for 
> branching and `,` for sequencing) is a very valuable and massively 
> important programming paradigm in these languages. The fact that 
> elaborate expression-level programming is not in nay way abandoned or 
> shunned today is pretty obvious in C++, since C++ took major steps 
> lately to develop its expression-level capabilities. But it has always 
> been and will always remain important in C as well.

No, expression-level programming has always been and will likely always 
remain a very minor part of C programming.  Yes, some people make use of 
the comma operator.  Some people do so extensively - and they are often, 
but not necessarily, considered "smart-arse" programmers rather than 
"smart" programmers.  If the comma operator were removed from the C 
language, I guess some 95% of programmers would barely notice - at 
worst, they would have to add an extra line inside an occasional "for" 
loop.  (The tertiary operator is used much more.)

I did not say that the use of comma operators is always bad - I said I 
do not recall seeing it in the kind of code I work with in a situation 
where I thought it was a good way to write the code.  A significant part 
of that is the kind of code I work with - in code for small systems 
where high reliability and safety is vital, code clarity is of utmost 
importance.  Code that does not do what it first appears to do is 
severely frowned upon.  Code is written in a very imperative style.

In my world, code that uses "malloc" is rarely acceptable, and for most 
programs, "double" is very seldom an appropriate choice of type.  But 
that does not mean these are not usable for other kinds of C 
programming.  There are many reasons why different styles of coding are 
used in different circumstances.

Even when C++ is used, with its significantly broader support for a 
variety of programming paradigms, I do not recall seeing the comma 
operator used.

> 
> The proclivity to stick exclusively to statement-level programming in C 
> and, God forbid, impose it in others through so called "code reviews"... 
> that would be a trait specific to "sweatshop" development outfits, which 
> strive to replace quality with quantity. I'd agree that in a revolving 
> door employment environment relying on a large number of low-competence 
> developers such code might be seen as "too confusing". But I don't see 
> why we should set our standards that low here, in `comp.lang.c`.
> 

I don't quite see how you are in any position to judge the coding styles 
used by people you know nothing about, working in fields that you know 
nothing about.

I am happy that different types of programming styles and paradigms are 
used for different purposes - imperative C is not suitable for most 
coding tasks.  Equally, expression-style programming is not appropriate 
for all coding tasks.

However, one thing that is never suitable for any real-world programming 
is deceptive code that is not what it appears to be.

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

#393654

David Brown <david.brown@hesbynett.no> writes:
>On 29/05/2025 14:49, Andrey Tarasevich wrote:
>> On Wed 5/7/2025 12:37 AM, David Brown wrote:
>>>>
>>>> That would get an immediate downcheck during review for exactly
>>>> that reason.
>>>
>>> Of course.  In fact, if someone presented such code for review (and 
>>> assuming I noticed the commas!) I'd have to consider whether it was 
>>> done maliciously, intentionally deceptively, due to incompetence, or 
>>> smart- arse coding.  In all my C coding experience, I can't recall 
>>> ever coming across a single situation when I thought the use of the 
>>> comma operator was appropriate in the kind of code I work with.
>> 
>> Wow! That's catastrophically bad.
>> 
>> As it has been stated many times before, both C and C++ are programming 
>> languages that embrace both statement-level and expression-level 
>> programming. Expression-level programming (e.g. where `?:` is used for 
>> branching and `,` for sequencing) is a very valuable and massively 
>> important programming paradigm in these languages. The fact that 
>> elaborate expression-level programming is not in nay way abandoned or 
>> shunned today is pretty obvious in C++, since C++ took major steps 
>> lately to develop its expression-level capabilities. But it has always 
>> been and will always remain important in C as well.
>
>No, expression-level programming has always been and will likely always 
>remain a very minor part of C programming.  Yes, some people make use of 
>the comma operator.  Some people do so extensively - and they are often, 
>but not necessarily, considered "smart-arse" programmers rather than 
>"smart" programmers.  If the comma operator were removed from the C 
>language, I guess some 95% of programmers would barely notice - at 
>worst, they would have to add an extra line inside an occasional "for" 
>loop.  (The tertiary operator is used much more.)

And sometimes, excessive use of the comma operator causes
compiler failures.

cfront generated the comma operator extensively, and expression trees
would grow to very large sizes.   There was a bug in PCC (for the
88100) where it would run out of temporary registers while generating
code for some cfront generated comma expressions (which were -far- from
human readable).    I had to fix the temporary register allocation
code in PCC to spill registers when the sethi-ullman number for an
expression exceeded the number of registers.

That was circa 1990, and I've generally not found any arguments
favoring their general use persuasive in the years since, including
Andrey's and Kaz's responses recently posted here.

The simple fact that experienced programmers that read this usenet
newsgroup missed the comma operators in the original example speaks
volumes.

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

#393661

scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> And sometimes, excessive use of the comma operator causes
> compiler failures.
>
> cfront generated the comma operator extensively, and expression trees
> would grow to very large sizes.   There was a bug in PCC (for the
> 88100) where it would run out of temporary registers while generating
> code for some cfront generated comma expressions (which were -far- from
> human readable).    I had to fix the temporary register allocation
> code in PCC to spill registers when the sethi-ullman number for an
> expression exceeded the number of registers.
> 
> That was circa 1990, and I've generally not found any arguments
> favoring their general use persuasive in the years since, including
> Andrey's and Kaz's responses recently posted here.

So a compiler you used circa 1990 had problems with comma expressions.

That's hardly an argument against using comma operators today.

> The simple fact that experienced programmers that read this usenet
> newsgroup missed the comma operators in the original example speaks
> volumes.

*That's* a valid argument.

-- 
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]

#393675

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>[...]
>> And sometimes, excessive use of the comma operator causes
>> compiler failures.
>>
>> cfront generated the comma operator extensively, and expression trees
>> would grow to very large sizes.   There was a bug in PCC (for the
>> 88100) where it would run out of temporary registers while generating
>> code for some cfront generated comma expressions (which were -far- from
>> human readable).    I had to fix the temporary register allocation
>> code in PCC to spill registers when the sethi-ullman number for an
>> expression exceeded the number of registers.
>> 
>> That was circa 1990, and I've generally not found any arguments
>> favoring their general use persuasive in the years since, including
>> Andrey's and Kaz's responses recently posted here.
>
>So a compiler you used circa 1990 had problems with comma expressions.
>
>That's hardly an argument against using comma operators today.

Tru, was an anecdote, not an argument, which conditioned
my opinion of comma operators.

>
>> The simple fact that experienced programmers that read this usenet
>> newsgroup missed the comma operators in the original example speaks
>> volumes.
>
>*That's* a valid argument.

Indeed.

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

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

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

csiph-web