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

#393671

On 29/05/2025 23:15, Scott Lurndal wrote:
> 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.

That is also an issue in the world of small-systems embedded programming.

While a lot of it these days is on ARM, and most of that is done using 
gcc, there are hundreds of C compilers of varying quality (and price, 
which is no indication of quality) for embedded systems.  Many of these 
other toolchains have bugs, non-conformities, inconsistencies and 
weaknesses.  (gcc is not perfect either!)  People programming for 8-bit 
and 16-bit microcontrollers using such tools will - and should - use a 
conservative subset of the C language.  Obscure and rarely used features 
of the language will be avoided, and code will be written in a simpler 
manner.  You don't write code in a way that increases the risk of 
catching a bug in a poorly tested part of the compiler, or in a way that 
might lead to unexpectedly inefficient results.

With 32-bit ARM now dominating the industry, along with more reliable 
tools (primarily gcc, with clang a distant second), there is much less 
need to pander to flaws in the toolchain but you still need to consider 
weaknesses in humans.  When you are writing software that is intended to 
run continuously without problems for years, or where a misunderstanding 
by a new maintainer a decade later can lead to safety risks, you don't 
write "cool" code!

It is well known that "Debugging is twice as hard as writing the code in 
the first place. Therefore, if you write the code as cleverly as 
possible, you are, by definition, not smart enough to debug it."  I 
would also say that understanding and maintaining other people's code is 
often a lot more than twice as hard as writing the code yourself.  I aim 
to code accordingly.

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

Of course people are experienced in different things - "programming", 
even when limited to a single language, is a broad field.

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

#395883

Andrey Tarasevich <noone@noone.net> writes:

> 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`.

What's interesting is that the arguments given opposing what might
be called expression-level programming have been sociological rather
than technical.

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

#393215

antispam@fricas.org (Waldek Hebisch) writes:
> 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.

Right, I didn't see the commas and assumed semicolons.  Changing the
formatting would have made the point much clearer.

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

#393630

On Tue 5/6/2025 10:36 AM, 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.
> 

Exactly. I thought the nature of the corrections I made (i.e. the 
deliberate usage of comma operator) would be strikingly obvious to the 
participants of the thread. But alas...

-- 
Best regards,
Andrey

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

#393636

On 29.05.2025 14:21, Andrey Tarasevich wrote:
> On Tue 5/6/2025 10:36 AM, 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.
>>
> 
> Exactly. I thought the nature of the corrections I made (i.e. the
> deliberate usage of comma operator) would be strikingly obvious to the
> participants of the thread. But alas...

I wouldn't call it "strikingly obvious". Typically programmers have a
abstracting look at code, and if they're used to semicolon separated
commands the small difference between ';' and ',' may get missed (as
some replies also indicated). Myself, as I recall from that older post,
I did also miss it on the first glimpse. But only and after I asked
myself what the _intentions_ the post had been I had a closer look at
all the inconspicuous "details" and noticed the subtle difference.

I don't think there's anything wrong with it, to be sure. But if I
were to post such subtle differences I'd have added a comment or used
a formatting to point and hint to that subtle but crucial difference.

Janis

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

#393739

Andrey Tarasevich <noone@noone.net> writes:

> On Tue 5/6/2025 10:36 AM, 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.
>
> Exactly.  I thought the nature of the corrections I made (i.e. the
> deliberate usage of comma operator) would be strikingly obvious to the
> participants of the thread.  But alas...

My own reaction is that the changes were not by themselves
strikingly obvious.  But in combination with the explicit
statement that "This version has no UB" it seems obvious
enough.

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

#393628

On Mon 5/5/2025 1:27 PM, 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.

Nope. Nowhere in this code the value of `pc` is used beyond the lifetime 
of the object with temporary lifetime.

Pay attention to the fact that the last 4 lines in above code is a 
single expression joined by a comma operator, which is the whole point 
of the corrections that differentiate it from the original version.

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

Not applicable in this case.

-- 
Best regards,
Andrey

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

#393652

Andrey Tarasevich <noone@noone.net> writes:
> On Mon 5/5/2025 1:27 PM, 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.
>
> Nope. Nowhere in this code the value of `pc` is used beyond the
> lifetime of the object with temporary lifetime.
>
> Pay attention to the fact that the last 4 lines in above code is a
> single expression joined by a comma operator, which is the whole point
> of the corrections that differentiate it from the original version.

Yes, yes, the fact that the code uses comma operators rather
than semicolons was pointed out and discussed several weeks ago.
I initially missed that change, it was pointed out, I acknowledged
it, and we moved on.

If you're going to reply to an old article, please read the thread
before posting.

In response to something else you recently wrote in this thread,
the change from semicolons to commas was not at all obvious.
The code is formatted in a way that strongly suggests statements
with ending semicolons.  Several of us missed the commas on first
reading, having seen nearly identical code earlier in the thread
with no acknowledgement that the code had been modified.  I simply
assumed that it was the same code, and didn't bother to re-read it
character by character.

[...]

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

#393175

Michael S <already5chosen@yahoo.com> writes:

> On Sun, 4 May 2025 22:22:12 -0700
> Andrey Tarasevich <noone@noone.net> wrote:
>
>> 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
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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...
>
> According to my understanding, you are wrong.
> Taking pointer of non-lvalue is UB, so anything compiler does is
> conforming.

Maybe you are thinking of C90.

In both C99 and C11, the expression

   (a = b).a[5]

is an lvalue, so taking its address with & is allowed.

It's easy to verify this assertion using gcc -std=c99 -pedantic.  If
the given expression were not an lvalue then taking its address with
& would be a constraint violation, requiring a diagnostic.  But no
diagnostic is produced.  (Using clang in place of gcc also produces
no diagnostic.)

The behavior under C99 semantics is arguably murky.  But under C11
semantics the behavior is well-defined.

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

#393164

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

You snipped this: "Any attempt to modify an object with temporary
lifetime results in undefined behavior.".  Which means, I think,
that an implementation that shared storage for "such an object"
with something else probably isn't going to cause problems for any
code with defined behavior.

Though I can imagine the possibility of code that modifies `a` and
reads via `pc` within the same full expression.  Perhaps a compiler
would refrain from optimizing the storage if `a` and `*pc` overlap.
I'm too lazy at the moment to write a demo.

But unless I've somehow missed it, the "Such an object need not
have a unique address." wording doesn't appear on that web page or
in my copy of n1570.pdf.  C17 does add these two sentences:

    An object with temporary lifetime behaves as if it were declared
    with the type of its value for the purposes of effective type. Such
    an object need not have a unique address.

Normally any two objects with overlapping lifetime must have distinct
addresses.  This addition, I think, gives compilers permission to have
temporary lifetime objects overlap with other existing objects, but not
to have a modification to one object affect the value of the other
(unless the modification invokes UB, of course).

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

#393179

On Mon 5/5/2025 1:26 AM, Keith Thompson wrote:
>>
>> 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.
> 
> You snipped this: "Any attempt to modify an object with temporary
> lifetime results in undefined behavior.".  Which means, I think,
> that an implementation that shared storage for "such an object"
> with something else probably isn't going to cause problems for any
> code with defined behavior.

It is going to cause problems, if the code relies on the address 
identity of the object, assuming the standard intends to provide such 
guarantees.

> Though I can imagine the possibility of code that modifies `a` and
> reads via `pc` within the same full expression.  

That's easy (in the context of declarations from my previous example):

   pc = &(a = b).a[5], a.a[5] = 42, printf("%d\n", *pc);

As one would expect, this produces different output in GCC and Clang for 
the reasons I already described.

> But unless I've somehow missed it, the "Such an object need not
> have a unique address." wording doesn't appear on that web page or
> in my copy of n1570.pdf.  C17 does add these two sentences:
> 
>      An object with temporary lifetime behaves as if it were declared
>      with the type of its value for the purposes of effective type. Such
>      an object need not have a unique address.
> 
> Normally any two objects with overlapping lifetime must have distinct
> addresses.  This addition, I think, gives compilers permission to have
> temporary lifetime objects overlap with other existing objects, but not
> to have a modification to one object affect the value of the other
> (unless the modification invokes UB, of course).

If so, that would be extremely underspecified. A mere "such an object 
need not have a unique address" is insufficient to fully convey the 
permission to overlap existing named objects. And that's probably what 
led to difference in interpretation between GCC and Clang.

Modification of the temporary is "prohibited" (as UB), but modification 
of the overlapped named object is not. The consequences can be quite 
surprising.

-- 
Best regards,
Andrey

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

#393260

Andrey Tarasevich <noone@noone.net> writes:

> On Mon 5/5/2025 1:26 AM, Keith Thompson wrote:
>
>>> 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.
>>
>> You snipped this:  "Any attempt to modify an object with temporary
>> lifetime results in undefined behavior.".  Which means, I think,
>> that an implementation that shared storage for "such an object"
>> with something else probably isn't going to cause problems for any
>> code with defined behavior.
>
> It is going to cause problems, if the code relies on the address
> identity of the object, assuming the standard intends to provide such
> guarantees.
>
>> Though I can imagine the possibility of code that modifies `a` and
>> reads via `pc` within the same full expression.
>
> That's easy (in the context of declarations from my previous example):
>
>   pc = &(a = b).a[5], a.a[5] = 42, printf("%d\n", *pc);
>
> As one would expect, this produces different output in GCC and Clang
> for the reasons I already described.
>
>> But unless I've somehow missed it, the "Such an object need not
>> have a unique address." wording doesn't appear on that web page or
>> in my copy of n1570.pdf.  C17 does add these two sentences:
>>
>>      An object with temporary lifetime behaves as if it were declared
>>      with the type of its value for the purposes of effective type.  Such
>>      an object need not have a unique address.
>>
>> Normally any two objects with overlapping lifetime must have distinct
>> addresses.  This addition, I think, gives compilers permission to have
>> temporary lifetime objects overlap with other existing objects, but not
>> to have a modification to one object affect the value of the other
>> (unless the modification invokes UB, of course).
>
> If so, that would be extremely underspecified.  A mere "such an object
> need not have a unique address" is insufficient to fully convey the
> permission to overlap existing named objects.

I don't see why you say that.  The statement says objects with
temporary lifetime need not have a unique address.  In the absence
of any other statement on the subject, this statement admits the
inference that an object with temporary lifetime might have the same
address as any other object.  Removing the constraint (that the
addresses of those objects must be distinct from the addresses
of all other objects), /and doing nothing else/, can only mean that
the addresses of such objects might match the address of any other
object in the environment.

If you think there should be a non-normative footnote explaining
that point, I expect I would vote in favor of that, but as far
as normative text goes I don't see any fuzziness about what is
allowed under the existing wording.

> And that's probably what led to difference in interpretation
> between GCC and Clang.

I suspect the implication actually goes the other way.  It is
because what gcc has done (past tense) violates the rules of the C11
standard that someone had the bright idea that the C standard should
be changed to allow this stupidity.

> Modification of the temporary is "prohibited" (as UB), but
> modification of the overlapped named object is not.  The
> consequences can be quite surprising.

In my view the problem is not that what is allowed is unclear, but
that the whole idea of possibly overlapping objects is a crock.
It's a sad statement on the quality of gcc that it does the wrong
thing even when -std=c11 and -pedantic are given as compilation
options.  Bleah.

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

#393261

On 08/05/2025 21:45, Tim Rentsch wrote:
> Andrey Tarasevich <noone@noone.net> writes:
> 

> 
>> And that's probably what led to difference in interpretation
>> between GCC and Clang.
> 
> I suspect the implication actually goes the other way.  It is
> because what gcc has done (past tense) violates the rules of the C11
> standard that someone had the bright idea that the C standard should
> be changed to allow this stupidity.
> 
>> Modification of the temporary is "prohibited" (as UB), but
>> modification of the overlapped named object is not.  The
>> consequences can be quite surprising.
> 
> In my view the problem is not that what is allowed is unclear, but
> that the whole idea of possibly overlapping objects is a crock.
> It's a sad statement on the quality of gcc that it does the wrong
> thing even when -std=c11 and -pedantic are given as compilation
> options.  Bleah.

While I think it is important that compilers try to follow the C 
standards (at least when you specify conforming modes), are there any 
potential realistic consequences of this?

Posters here have gone far out of their way to make hypothetical code 
that demonstrates this flaw in gcc without invoking undefined behaviour. 
  Is there any risk that anyone would come across this in real code?

In addition, is it reasonable to suppose that C programmers that have 
not studied the C standards here would be expecting the behaviour of 
gcc, or the behaviour of clang here?  Certainly if /I/ saw "pc = &(a = 
b).a[5]" prior to this thread, I would expect the contents of the struct 
"b" to be copied to the memory of the struct "a", and "pc" set to point 
to the member of the array within "a".  I would expect the code to work 
as gcc works, and would find clang's behaviour completely unexpected.  I 
would be surprised if I were alone in that.

So to me, it makes sense that the C standard has changed to support a 
more sane approach to such situations.  It would be unreasonable to 
change it to guarantee the sensible behaviour - that would mean 
compilers like clang that generated technically correct but surprising 
(to many) code would now be wrong.

(gcc's behaviour is also more efficient, but of course correctness 
trumps efficiency every time.)

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

#393166

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.

(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.

And more obviously, "%p" requires an argument of type void*, not int*.

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

#393169

On Mon, 05 May 2025 01:34:16 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> 
> And more obviously, "%p" requires an argument of type void*, not int*.
> 

That part of otherwise very good comment is unreasonably pedantic.

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

#393172

In article <20250505120331.000015b2@yahoo.com>,
Michael S  <already5chosen@yahoo.com> wrote:
>On Mon, 05 May 2025 01:34:16 -0700
>Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> 
>> And more obviously, "%p" requires an argument of type void*, not int*.
>> 
>
>That part of otherwise very good comment is unreasonably pedantic.

That's KT for you.  That's his reason for existence.

Welcome to CLC!

-- 
Alice was  something of a  handful to her  father, Theodore Roosevelt.  He was
once asked by a visiting dignitary  about parenting his spitfire of a daughter
and he  replied, "I can be  President of the  United States, or I  can control
Alice. I cannot possibly do both."

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

#393184

Michael S <already5chosen@yahoo.com> writes:
> On Mon, 05 May 2025 01:34:16 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> And more obviously, "%p" requires an argument of type void*, not int*.
>
> That part of otherwise very good comment is unreasonably pedantic.

I disagree.  I suggest it's a bad habit to use "%p" without ensuring,
by a cast if necessary, that the argument is of type void*.

In most implementations, it's likely that all pointers have the same
size and representation and are passed as arguments in the same way,
but getting the types right means one less thing to worry about.
And since the behavior is undefined, a compiler could warn about
it or even generate code with unexpected behavior.  Variadic functions
place the burden of using the correct types on the programmer.

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

#393187

On 2025-05-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Mon, 05 May 2025 01:34:16 -0700
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> And more obviously, "%p" requires an argument of type void*, not int*.
>>
>> That part of otherwise very good comment is unreasonably pedantic.
>
> I disagree.  I suggest it's a bad habit to use "%p" without ensuring,
> by a cast if necessary, that the argument is of type void*.
>
> In most implementations, it's likely that all pointers have the same
> size and representation and are passed as arguments in the same way,
> but getting the types right means one less thing to worry about.

If the codebade assumes all data pointers are the same size, bit pattern
and are treated the same in the calling conventions / ABI, then it
is probably moot.

That code is doomed on a platform where the assumption doesn't hold, and
the printf statemnts are probably not independently reusable.

(I mostly put in these casts just to communicate to others that
an ISO C language lawyer works here, if you happen to need one.)

Also, it owuld be amazingly stupid of any such platform not just
make those printfs work: to promote variadic arguments of
pointer-to-object type to a common representation which is the same as
void *, combined with a matching behavior in the va_arg macro for
extracting the value back into any pointer-to-object type.

Mountains of non-standard-conforming code exert tremendous pressure on
both hardware platforms and the way C implementations are adapted to
those platforms.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#393200

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2025-05-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Mon, 05 May 2025 01:34:16 -0700
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>> And more obviously, "%p" requires an argument of type void*, not
>>>> int*.
>>>
>>> That part of otherwise very good comment is unreasonably pedantic.
>>
>> I disagree.  I suggest it's a bad habit to use "%p" without
>> ensuring, by a cast if necessary, that the argument is of type
>> void*.
>>
>> In most implementations, it's likely that all pointers have the
>> same size and representation and are passed as arguments in the
>> same way, but getting the types right means one less thing to worry
>> about.
>
> If the codebade assumes all data pointers are the same size, bit
> pattern and are treated the same in the calling conventions / ABI,
> then it is probably moot.
>
> That code is doomed on a platform where the assumption doesn't
> hold, and the printf statemnts are probably not independently
> reusable.
>
> (I mostly put in these casts just to communicate to others that
> an ISO C language lawyer works here, if you happen to need one.)
>
> Also, it owuld be amazingly stupid of any such platform not just
> make those printfs work:  to promote variadic arguments of
> pointer-to-object type to a common representation which is the
> same as void *, combined with a matching behavior in the va_arg
> macro for extracting the value back into any pointer-to-object
> type.

This statement strikes me as would an utterance coming from a
resident of Fantasyland.

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

#393199

Michael S <already5chosen@yahoo.com> writes:

> On Mon, 05 May 2025 01:34:16 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> And more obviously, "%p" requires an argument of type void*, not
>> int*.
>
> That part of otherwise very good comment is unreasonably pedantic.

I don't have the same reaction.  My sense is Keith was just being
thorough.  Speaking for myself his statement wasn't needed, but
that condition might not hold for other readers.  Given that his
comment is just one not-overly-long sentence, I don't think it's
too much to ask that readers already familiar with the point
simply skip over it.

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

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

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

csiph-web