Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399456 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-05-27 19:53 +0200 |
| Last post | 2026-05-30 11:18 +0200 |
| Articles | 20 on this page of 171 — 17 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
[OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 21:33 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 14:43 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:11 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:08 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:32 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:12 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 14:07 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:10 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:17 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 21:47 +0100
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 15:57 -0400
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 01:26 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 04:25 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:01 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-31 00:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 10:59 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-01 00:33 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 02:26 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:24 +0200
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 08:09 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 04:15 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 14:58 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 01:04 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:20 +0000
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-30 11:18 +0200
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-30 19:53 -0700 |
| Message-ID | <10vg7rk$18nd4$1@kst.eternal-september.org> |
| In reply to | #399543 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-05-31 01:43, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> [...]
>> [...]
>> C's operator precedence rules are complicated and arguably flawed.
>
> I'd say that just the (known) flaw makes them (slightly) complicated;
> so you need to remember that "flaw" (or "inconsistency") to be safe.
> The rest is completely sensible. And even if one doesn't have a table
> to look up the precedences they mostly can be derived (presuming one
> has a feeling for the underlying logic of these things or experiences
> from other related areas).
Reasonable, but I feel the need to say that that's your personal
opinion. You seem to think that C's precedence rules have one and
only one flaw, and a set of rules with that flaw corrected would
be ideal.
I don't even necessarily disagree, but others are likely to have
different opinions, and those opinions might be perfectly valid.
I don't want to make a huge deal out of this. I honestly don't have
a strong opinion myself. I usually find dealing with the rules
as they exist to be a much better use of my time and attention --
and I don't mean that as a criticism of anyone who choose to think
about alternatives.
>> They could have been defined differently. A simpler set of rules,
>> with fewer levels, *might* have been better. I don't have any
>> concrete suggestions -- nor do I have any strong preferences.
>> I accept C's rules as they are. I would accept them if they had
>> been defined differently.
>> Nothing about the current rules particularly bothers me. There are
>> no objective criteria for deciding what the rules *should* be.
>
> There are. (What I called above as "derived underlying logic".) Some
> aspects have already been formulated in this and other threads here.
> But maybe not obvious to recognize without background in mathematics,
> logic, or CS.
>
>> Even having multiplication bind more tightly than addition is
>> fundamentally an arbitrary choice
>
> (Now opinions are getting really strange; in the above stated sense.)
Mathematical notation almost universally has multiplication binding
more tightly than addition. It's consistent because the consistency
itself has big advantages so that you can write x + y * z (or x +
y × z) and everyone knows what you mean. Strict left-to-right
evaluation would also have been a valid choice. (I don't know the
history, but it probably goes back several centuries.)
>> (though one that's almost
>> universally recognized, even outside the context of programming
>> languages).
>> [...]
>>
>>> If not, people can choose to ignore those them when writing C code,
>>> for example like this where all () are technically superfluous:
>>>
>>> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
>> Yes, they can, and I personally tend to agree that they should.
>
> The more complex the expressions are the more structure they need.
>
> IMO, the parenthesis above make precedence clear (if unknown!), but
> are not contributing to readability. It would have made more sense
> to separate the sub-expression within the [...] in an own object to
> enhance readability and to more easily understand what's going on.
>
> To emphasize; not the precedences are the problem above, but the
> complexity of the expression in connexion with lack of structuring.
>
>>> [...]
>> When designing a new language, there are real advantages in strictly
>> imitating C's rules, just because so many programmers are familiar
>> with them.
>
> Huh? - How that? - Are you saying here that practically only C-like
> languages are in common use?
Huh? No, I didn't say that at all.
I suggest that if you're designing a somewhat C-like language,
sticking to C's precedence rules has advantages due to programmer
familiarity. Even for a language that's not particularly C-like,
but that has C-like expressions, the designer might consider
following C's rules.
Or not.
> - But even if so; there's quite some
> languages with differing precedence rules, not C-based, and without
> such a flaw like the one being discussed. - When designing a *new*
> language I'd certainly choose one of the sensible precedence rules,
> and just without those obvious flaws. (And not use "C" as base, of
> course.)
Certainly.
>> (I would have been silly for C++ or Objective-C to
>> change the precedence rules, even to improve them.) But there
>> are also real advantages in using precedence rules that are better
>> (e.g., simpler) than C's.
>
> Or - with reference to that flaw - just more consistent.
>
> Consistent systems are inherently simpler, in the sense of easier to
> understand and thus more straightforward to use. A precondition for
> that is, as said, at least a basic understanding of such things.
Ah, but consistent with what? Internal consistency and consistency
with existing practice are not necessarily the same thing.
>> It depends on the nature of the language.
>> It could be an interesting discussion for comp.lang.misc.
--
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]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-02 12:16 +0200 |
| Message-ID | <10vmah9$3uus8$12@dont-email.me> |
| In reply to | #399544 |
On 2026-05-31 04:53, Keith Thompson wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-05-31 01:43, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>>> [...] >>> [...] >>> C's operator precedence rules are complicated and arguably flawed. >> >> I'd say that just the (known) flaw makes them (slightly) complicated; >> so you need to remember that "flaw" (or "inconsistency") to be safe. >> The rest is completely sensible. And even if one doesn't have a table >> to look up the precedences they mostly can be derived (presuming one >> has a feeling for the underlying logic of these things or experiences >> from other related areas). > > Reasonable, but I feel the need to say that that's your personal > opinion. You seem to think that C's precedence rules have one and > only one flaw, and a set of rules with that flaw corrected would > be ideal. Erm, no. Not "ideal". (This is just another formulation for what Bart expressed with the word "perfect" that he'd put in my mouth.) What I'm saying is that with the knowledge of the contexts of the underlying models (mathematical and logical calculi, based on a sensible definition) the possible (sensible) options are sparse. We should always keep in mind that there's an inherent difference of subjective opinions and knowledge based sensible conventions. Such conventions are not as universal as natural laws, they can't be because they are human-made, but they can be sensibly defined (often due to practical reasoning). Arithmetic is such a case, and the hierarchy of lower-level operations to higher-level (+, *, **) straightforwardly defined. Practical consideration, like usage in positional notation systems add to the form of such conventions. That's certainly far from an unfounded just "subjective opinion". > > I don't even necessarily disagree, but others are likely to have > different opinions, and those opinions might be perfectly valid. It's not about opinions. (See above.) > > I don't want to make a huge deal out of this. I honestly don't have > a strong opinion myself. I usually find dealing with the rules > as they exist to be a much better use of my time and attention -- > and I don't mean that as a criticism of anyone who choose to think > about alternatives. Oh, I'm not handling that differently in practice. When I had read my K&R translation (from 1983) to learn the C-language I just made a small note in my book (http://volatile.gridbug.de/C-op-prec.png, where the faint comment "sinnvoll" means "sensible") and carried on. That comment was actually useful to immediately see that flaw when looking up the precedences while programming in "C" to not make a programming mistake. > [...] >>>> [...] >>> When designing a new language, there are real advantages in strictly >>> imitating C's rules, just because so many programmers are familiar >>> with them. >> >> Huh? - How that? - Are you saying here that practically only C-like >> languages are in common use? > > Huh? No, I didn't say that at all. > > I suggest that if you're designing a somewhat C-like language, > sticking to C's precedence rules has advantages due to programmer > familiarity. Even for a language that's not particularly C-like, > but that has C-like expressions, the designer might consider > following C's rules. Oh, I see. > Or not. > >> [...] > >>> (I would have been silly for C++ or Objective-C to >>> change the precedence rules, even to improve them.) But there >>> are also real advantages in using precedence rules that are better >>> (e.g., simpler) than C's. >> >> Or - with reference to that flaw - just more consistent. >> >> Consistent systems are inherently simpler, in the sense of easier to >> understand and thus more straightforward to use. A precondition for >> that is, as said, at least a basic understanding of such things. > > Ah, but consistent with what? Internal consistency and consistency > with existing practice are not necessarily the same thing. Right. And both should be considered when designing such things. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-31 11:47 +0200 |
| Message-ID | <10vh047$1epj1$1@dont-email.me> |
| In reply to | #399543 |
On 31/05/2026 03:37, Janis Papanagnou wrote: > On 2026-05-31 01:43, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>> [...] >>> If not, people can choose to ignore those them when writing C code, >>> for example like this where all () are technically superfluous: >>> >>> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)]; >> >> Yes, they can, and I personally tend to agree that they should. > > The more complex the expressions are the more structure they need. > > IMO, the parenthesis above make precedence clear (if unknown!), but > are not contributing to readability. It would have made more sense > to separate the sub-expression within the [...] in an own object to > enhance readability and to more easily understand what's going on. > > To emphasize; not the precedences are the problem above, but the > complexity of the expression in connexion with lack of structuring. > This is an example of how readability depends on the reader. To me, there is no benefit in having a sub-expression here because the structure is clear - this is how you do table-based crc's with 4-bit chunks. But to someone unfamiliar with CRC calculations, splitting the expression up might make it clearer. (Alternatively, a comment block with an explanation could help.) I /do/ think the parentheses here are helpful for readability, precisely because they emphasise the structure of the expression. You could write: crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF]; but that needs significantly more cognitive effort to parse when reading it, could be misinterpreted, and has lost all the structure that makes it easy to see what is going on. (I regularly use bit-manipulation and shift instructions in my code - but I still felt it best to check the details in a precedence table before writing that.) The expression as originally parenthesised is thus definitely easier for /me/ to read, and is almost exactly the way I would write it myself : crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)]; The only differences I would have are the names (why would anyone put variable types into the names like "crcu32" ? We are not writing BASIC), and I'd use a small case "0xf". Unlike almost every example Bart has shown before, it even has nice spacing!
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-02 12:55 +0200 |
| Message-ID | <10vmcq9$3uus7$8@dont-email.me> |
| In reply to | #399547 |
On 2026-05-31 11:47, David Brown wrote:
> On 31/05/2026 03:37, Janis Papanagnou wrote:
>> On 2026-05-31 01:43, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>
>>>> If not, people can choose to ignore those them when writing C code,
>>>> for example like this where all () are technically superfluous:
>>>>
>>>> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
>>>
>>> Yes, they can, and I personally tend to agree that they should.
>>
>> The more complex the expressions are the more structure they need.
>>
>> IMO, the parenthesis above make precedence clear (if unknown!), but
>> are not contributing to readability. It would have made more sense
>> to separate the sub-expression within the [...] in an own object to
>> enhance readability and to more easily understand what's going on.
>>
>> To emphasize; not the precedences are the problem above, but the
>> complexity of the expression in connexion with lack of structuring.
>>
> This is an example of how readability depends on the reader. To me,
> there is no benefit in having a sub-expression here because the
> structure is clear - this is how you do table-based crc's with 4-bit
> chunks.
To me, the precedence is as clear as the structure. That's not the
issue I see with that expression.
It's the overloaded expression that is what makes it "unreadable".
(It's actually similar to those overloaded expressions that we saw
in another recent sub-/thread about color-conversions.)
> But to someone unfamiliar with CRC calculations, splitting the
> expression up might make it clearer. (Alternatively, a comment block
> with an explanation could help.)
And that has also nothing to do neither with table-based algorithms
(which are a triviality) nor with the CRC (or other) coding-programs.
(Note that I'm saying that as someone who has implemented a lot of
such things, various CRCs, directly calculated and table-based, and
a lot much more demanding coding software than these simple CRCs.)
>
> I /do/ think the parentheses here are helpful for readability, precisely
> because they emphasise the structure of the expression. You could write:
>
> crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
>
> but that needs significantly more cognitive effort to parse when reading
> it, could be misinterpreted, and has lost all the structure that makes
> it easy to see what is going on.
Yes, I recognize that in that example the parentheses help combining
parts. (But as said, I see the primary problem in the complexity of
the expression.)
>
> (I regularly use bit-manipulation and shift instructions in my code -
> but I still felt it best to check the details in a precedence table
> before writing that.)
Agreed.
>
> The expression as originally parenthesised is thus definitely easier
> for /me/ to read, and is almost exactly the way I would write it myself :
>
> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
Acknowledged.
>
> The only differences I would have are the names (why would anyone put
> variable types into the names like "crcu32" ?
Given the more obvious problem I see with that expression I hadn't
commented on that; but you are right and I certainly agree.
The coding algorithms that I implemented had always been just plain
straight ("unsigned") registers. (So there's no need to reflect that
property in the names of such variable.)
> We are not writing
> BASIC), and I'd use a small case "0xf". Unlike almost every example
> Bart has shown before, it even has nice spacing!
I'm not that picky with the hexadecimal constants it seems; I seem to
use both forms, depending on subjective readability in the respective
context. A quick glimpse into my table-driven CRC C-code shows that I
used lower-case, and that seems generally to be the prevalent form.[*]
Janis
[*] Anecdotally: lowercase tables may have their issues though; once
I had implemented a DES-3 algorithm, which was full of tabular data.
(That was at times when we could obtain standards only as paper.)
My code failed against my tests in about 30% of the test cases. The
reason of the problem was a single table entry 'db' vs. 'bd' (or vv.)
It was a horror to find that typo in that huge stack of table data;
somehow it was difficult to find that even after having read several
times across all that constant data. I'm not sure the same could have
happened with uppercase, though...
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-05-31 09:12 +0100 |
| Message-ID | <10vgqhf$1d6tp$1@dont-email.me> |
| In reply to | #399541 |
On 31/05/2026 00:43, Keith Thompson wrote: > C's operator precedence rules are complicated and arguably flawed. > They could have been defined differently. A simpler set of rules, > with fewer levels,*might* have been better. I don't have any > concrete suggestions -- nor do I have any strong preferences. > I accept C's rules as they are. I would accept them if they had > been defined differently. Can't the compiler easily remove any parens that aren't necessary? So - just write complex expressions in a way that a human can most easily understand, it makes your intention clear and probable doesn't increase the size of the executable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-31 11:49 +0200 |
| Message-ID | <10vh074$1epj1$2@dont-email.me> |
| In reply to | #399545 |
On 31/05/2026 10:12, Richard Harnden wrote: > On 31/05/2026 00:43, Keith Thompson wrote: >> C's operator precedence rules are complicated and arguably flawed. >> They could have been defined differently. A simpler set of rules, >> with fewer levels,*might* have been better. I don't have any >> concrete suggestions -- nor do I have any strong preferences. >> I accept C's rules as they are. I would accept them if they had >> been defined differently. > > Can't the compiler easily remove any parens that aren't necessary? > So - just write complex expressions in a way that a human can most > easily understand, it makes your intention clear and probable doesn't > increase the size of the executable. > > Of course. Parentheses do not affect the generated code unless they affect the semantics of the expression. (Some people think parentheses affect the order of evaluation, but that is not the case for most compilers.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-31 11:10 +0100 |
| Message-ID | <10vh1eo$1ei50$2@dont-email.me> |
| In reply to | #399548 |
On 31/05/2026 10:49, David Brown wrote: > On 31/05/2026 10:12, Richard Harnden wrote: >> On 31/05/2026 00:43, Keith Thompson wrote: >>> C's operator precedence rules are complicated and arguably flawed. >>> They could have been defined differently. A simpler set of rules, >>> with fewer levels,*might* have been better. I don't have any >>> concrete suggestions -- nor do I have any strong preferences. >>> I accept C's rules as they are. I would accept them if they had >>> been defined differently. >> >> Can't the compiler easily remove any parens that aren't necessary? >> So - just write complex expressions in a way that a human can most >> easily understand, it makes your intention clear and probable doesn't >> increase the size of the executable. >> >> > > Of course. Parentheses do not affect the generated code unless they > affect the semantics of the expression. (Some people think parentheses > affect the order of evaluation, They can do if they make a expression be parsed differently. Do you have an example where they make no difference but people might think they do?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-31 13:18 +0200 |
| Message-ID | <10vh5f0$1g1ke$1@dont-email.me> |
| In reply to | #399550 |
On 31/05/2026 12:10, Bart wrote: > On 31/05/2026 10:49, David Brown wrote: >> On 31/05/2026 10:12, Richard Harnden wrote: >>> On 31/05/2026 00:43, Keith Thompson wrote: >>>> C's operator precedence rules are complicated and arguably flawed. >>>> They could have been defined differently. A simpler set of rules, >>>> with fewer levels,*might* have been better. I don't have any >>>> concrete suggestions -- nor do I have any strong preferences. >>>> I accept C's rules as they are. I would accept them if they had >>>> been defined differently. >>> >>> Can't the compiler easily remove any parens that aren't necessary? >>> So - just write complex expressions in a way that a human can most >>> easily understand, it makes your intention clear and probable doesn't >>> increase the size of the executable. >>> >>> >> >> Of course. Parentheses do not affect the generated code unless they >> affect the semantics of the expression. (Some people think >> parentheses affect the order of evaluation, > > They can do if they make a expression be parsed differently. As I said, they "do not affect the generated code unless they affect the semantics of the expression." Obviously that only applies to extra parentheses. If that's what you mean by "parsed differently", then we agree - clearly "(a + b) * c" gives different code from "a + (b * c)". But you might consider "(a + b) + c" to be "parsed differently" than "a + (b + c)", because of how a particular compiler implements its parser. It's possible that this results in different code for a particular compiler, but there is no difference in the meaning for the C language. I perhaps expressed it poorly when I said extra parentheses "do not" affect the generated code - extra parentheses do not change the meaning of the C code, and so compilers don't have to consider them in any way (and optimising compilers generally don't). But a compiler is, of course, free to be influenced by them and generate code that varies with extra parentheses, as long as the final results match those required by the standard. > Do you have > an example where they make no difference but people might think they do? > People might think they affect the order of evaluation, such as when you have function calls : u = foo(x) + (foo(y) + foo(z)); Some people might think the use of parentheses means that "foo(y)" and "foo(z)" are called before "foo(x)", when the order of all these calls (and the additions) is unspecified. (Again, a given compiler might be influenced by the parentheses, but the language does not require it.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-31 10:24 -0400 |
| Message-ID | <10vhgau$1iv7l$1@dont-email.me> |
| In reply to | #399553 |
On 2026-05-31 07:18, David Brown wrote: > On 31/05/2026 12:10, Bart wrote: >> On 31/05/2026 10:49, David Brown wrote: >>> On 31/05/2026 10:12, Richard Harnden wrote: >>>> On 31/05/2026 00:43, Keith Thompson wrote: ... > But you might consider "(a + b) + c" to be "parsed differently" than "a > + (b + c)", because of how a particular compiler implements its parser. > It's possible that this results in different code for a particular > compiler, but there is no difference in the meaning for the C language. (a + b) + c mandates adding a to b, then adding the result to c. a + (b + c) mandates adding b to c then adding the result to a. As far as mathematics is concerned, that's the same thing, but in computer math it can make a difference if one of the two results in overflow or unnecessary loss of precision, and the other does not. ... >> Do you have >> an example where they make no difference but people might think they do? >> > > People might think they affect the order of evaluation, such as when you > have function calls : > > u = foo(x) + (foo(y) + foo(z)); > > Some people might think the use of parentheses means that "foo(y)" and > "foo(z)" are called before "foo(x)", when the order of all these calls > (and the additions) is unspecified. (Again, a given compiler might be > influenced by the parentheses, but the language does not require it. You're correct with regard to the function calls, but the parenthesized addition must be performed first, and the other one second, which may make a difference, for the same reasons given in my previous paragraph.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-31 17:35 +0200 |
| Message-ID | <10vhkgl$1k67h$1@dont-email.me> |
| In reply to | #399556 |
On 31/05/2026 16:24, James Kuyper wrote: > On 2026-05-31 07:18, David Brown wrote: >> On 31/05/2026 12:10, Bart wrote: >>> On 31/05/2026 10:49, David Brown wrote: >>>> On 31/05/2026 10:12, Richard Harnden wrote: >>>>> On 31/05/2026 00:43, Keith Thompson wrote: > ... >> But you might consider "(a + b) + c" to be "parsed differently" than "a >> + (b + c)", because of how a particular compiler implements its parser. >> It's possible that this results in different code for a particular >> compiler, but there is no difference in the meaning for the C language. > > (a + b) + c mandates adding a to b, then adding the result to c. a + (b > + c) mandates adding b to c then adding the result to a. As far as > mathematics is concerned, that's the same thing, but in computer math it > can make a difference if one of the two results in overflow or > unnecessary loss of precision, and the other does not. > > ... >>> Do you have >>> an example where they make no difference but people might think they do? >>> >> >> People might think they affect the order of evaluation, such as when you >> have function calls : >> >> u = foo(x) + (foo(y) + foo(z)); >> >> Some people might think the use of parentheses means that "foo(y)" and >> "foo(z)" are called before "foo(x)", when the order of all these calls >> (and the additions) is unspecified. (Again, a given compiler might be >> influenced by the parentheses, but the language does not require it. > > You're correct with regard to the function calls, but the parenthesized > addition must be performed first, and the other one second, which may > make a difference, for the same reasons given in my previous paragraph. The parentheses do not dictate the order of evaluation. But you are correct - and it's worth pointing out, so thank you for doing that - that for floating point operations, the grouping of operations can affect the result. If you are talking about floating point arithmetic (I was thinking of integer arithmetic, but did not specify), then the operations are not necessarily commutative or associative, and the compiler cannot then re-arrange the operations unless it knows that doing so does not affect the result. But except for specific cases, the order of evaluation - both for the values and side-effects - of sub-expressions is unspecified. Indeed, they are unsequenced - the evaluations can interleave. Usually, both sub-expressions of a binary operator will be evaluated before the operator itself, simply because usually the results of the operator cannot be calculated until the sub-expression's values are known. But this is not a requirement of the language - if the compiler can get the same results without doing so, it is free to pick a different order. "(a + b) * 0" does not need to evaluate "a", "b", or "a + b" at all unless there is a possibility of a side-effect - and it can perform the side-effects in any order. "a + (b + c)" can check "a" for a trap representation and deal with that before looking at "b" and "c" or the results of "b + c", even though it cannot (for floating point operations) re-arrange the code to do "a + b" first. If an implementation provides additional semantics to signed integer arithmetic, such as saturating or trapping overflow, then signed integer arithmetic operations are no longer associative. But normal C undefined behaviour on overflow is fully associative (as is wrapping semantics, for addition, subtraction and multiplication). So for non-associative operations, parentheses can affect the semantics - and therefore the most likely (but not required) order of evaluation of at least some parts of the sub-expressions. However, that also then means we are not longer talking about parentheses that do not affect the semantics of the expression, which is what this thread branch is about.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-31 12:46 -0400 |
| Message-ID | <10vhol0$1iv7k$3@dont-email.me> |
| In reply to | #399558 |
On 2026-05-31 11:35, David Brown wrote: ... > Usually, both sub-expressions of a binary operator will be evaluated > before the operator itself, simply because usually the results of the > operator cannot be calculated until the sub-expression's values are > known. But this is not a requirement of the language "The value computations of the operands of an operator are sequenced before the value computation of the result of the operator." (6.5.1p3) - if the compiler > can get the same results without doing so, it is free to pick a > different order. Correct - but "same results" is crucial; it allows you to invoke the "as-if" rule. Otherwise, the sequencing specified by 6.5.1p3 must be honored. ... > If an implementation provides additional semantics to signed integer > arithmetic, such as saturating or trapping overflow, then signed integer > arithmetic operations are no longer associative. But normal C undefined > behaviour on overflow is fully associative (as is wrapping semantics, > for addition, subtraction and multiplication). I don't follow that. I believe that overflow is guaranteed for (5 + INT_MAX) + INT_MIN, and completely avoided by 5 + (INT_MAX + INT_MIN), which differ only by association. Are you saying they both have the same chance of overflowing?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-31 22:24 +0200 |
| Message-ID | <10vi5ej$1p77r$2@dont-email.me> |
| In reply to | #399560 |
On 31/05/2026 18:46, James Kuyper wrote: > On 2026-05-31 11:35, David Brown wrote: > ... >> Usually, both sub-expressions of a binary operator will be evaluated >> before the operator itself, simply because usually the results of the >> operator cannot be calculated until the sub-expression's values are >> known. But this is not a requirement of the language > > "The value computations of the operands of an operator are sequenced > before the value computation of the result of the operator." (6.5.1p3) > > - if the compiler >> can get the same results without doing so, it is free to pick a >> different order. > > Correct - but "same results" is crucial; it allows you to invoke the > "as-if" rule. Otherwise, the sequencing specified by 6.5.1p3 must be > honored. > OK. > ... >> If an implementation provides additional semantics to signed integer >> arithmetic, such as saturating or trapping overflow, then signed integer >> arithmetic operations are no longer associative. But normal C undefined >> behaviour on overflow is fully associative (as is wrapping semantics, >> for addition, subtraction and multiplication). > > I don't follow that. I believe that overflow is guaranteed for (5 + > INT_MAX) + INT_MIN, and completely avoided by 5 + (INT_MAX + INT_MIN), > which differ only by association. Are you saying they both have the > same chance of overflowing? No - I see now what you are saying. Overflow is never guaranteed to do anything, including to exist, because it is UB. So the compiler can happily treat "(5 + INT_MAX) + INT_MIN" as though you had written "5 + (INT_MAX + INT_MIN)". It can freely re-arrange an expression like this that has a potential overflow into one without risk of overflow, as long as the same results are given for all values that do not overflow. (The overflow is not part of the observable behaviour.) But it cannot re-arrange the other way unless it knows that intermediary overflows have no effect. (And the compiler usually does know this.) What I am trying to say - but described inaccurately - is that expressions can be re-arranged by the compiler without preserving overflow behaviour, but it must avoid introducing /new/ overflow risks if they can affect the results. It may, however, introduce new intermediary overflows if they do not affect the results.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-31 18:26 -0400 |
| Message-ID | <10vicjd$1iv7k$4@dont-email.me> |
| In reply to | #399566 |
On 2026-05-31 16:24, David Brown wrote: > On 31/05/2026 18:46, James Kuyper wrote: >> On 2026-05-31 11:35, David Brown wrote: ... >>> If an implementation provides additional semantics to signed integer >>> arithmetic, such as saturating or trapping overflow, then signed integer >>> arithmetic operations are no longer associative. But normal C undefined >>> behaviour on overflow is fully associative (as is wrapping semantics, >>> for addition, subtraction and multiplication). >> >> I don't follow that. I believe that overflow is guaranteed for (5 + >> INT_MAX) + INT_MIN, and completely avoided by 5 + (INT_MAX + INT_MIN), >> which differ only by association. Are you saying they both have the >> same chance of overflowing? > > No - I see now what you are saying. Overflow is never guaranteed to do > anything, including to exist, because it is UB. So the compiler can I only meant that overflow was guaranteed, and that the behavior was therefore guaranteed to be undefined. I didn't mean to imply that any particular behavior was guaranteed. > happily treat "(5 + INT_MAX) + INT_MIN" as though you had written "5 + > (INT_MAX + INT_MIN)". It can freely re-arrange an expression like this > that has a potential overflow into one without risk of overflow, as long > as the same results are given for all values that do not overflow. (The > overflow is not part of the observable behaviour.) But it cannot > re-arrange the other way unless it knows that intermediary overflows > have no effect. (And the compiler usually does know this.) That's what I was mainly concerned about - if I've carefully arranged to make sure that overflow is impossible, I'd be rather upset by a compiler which, because "normal C undefined behaviour on overflow is fully associative", rearranges the associations in my code to make overflow possible. I interpreted that comment as meaning that "whether or not the behavior is undefined is fully associative". I guess that what you actually meant was "if the behavior is undefined, the compiler is free to rearrange the associations".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 08:28 +0200 |
| Message-ID | <10vj8r5$21h40$1@dont-email.me> |
| In reply to | #399568 |
On 01/06/2026 00:26, James Kuyper wrote: > On 2026-05-31 16:24, David Brown wrote: >> On 31/05/2026 18:46, James Kuyper wrote: >>> On 2026-05-31 11:35, David Brown wrote: > ... >>>> If an implementation provides additional semantics to signed integer >>>> arithmetic, such as saturating or trapping overflow, then signed integer >>>> arithmetic operations are no longer associative. But normal C undefined >>>> behaviour on overflow is fully associative (as is wrapping semantics, >>>> for addition, subtraction and multiplication). >>> >>> I don't follow that. I believe that overflow is guaranteed for (5 + >>> INT_MAX) + INT_MIN, and completely avoided by 5 + (INT_MAX + INT_MIN), >>> which differ only by association. Are you saying they both have the >>> same chance of overflowing? >> >> No - I see now what you are saying. Overflow is never guaranteed to do >> anything, including to exist, because it is UB. So the compiler can > > I only meant that overflow was guaranteed, and that the behavior was > therefore guaranteed to be undefined. I didn't mean to imply that any > particular behavior was guaranteed. That's a useful distinction. > >> happily treat "(5 + INT_MAX) + INT_MIN" as though you had written "5 + >> (INT_MAX + INT_MIN)". It can freely re-arrange an expression like this >> that has a potential overflow into one without risk of overflow, as long >> as the same results are given for all values that do not overflow. (The >> overflow is not part of the observable behaviour.) But it cannot >> re-arrange the other way unless it knows that intermediary overflows >> have no effect. (And the compiler usually does know this.) > > That's what I was mainly concerned about - if I've carefully arranged to > make sure that overflow is impossible, I'd be rather upset by a compiler > which, because "normal C undefined behaviour on overflow is fully > associative", rearranges the associations in my code to make overflow > possible. I am quite happy for the compiler to make such re-arrangements, as long as it knows that doing so gives the same results on the target. I too would be most upset if it made these re-arrangements when I had the flag "-fsanitize=signed-overflow" (or equivalent on other compilers) in action and halted my program when it "discovered" and overflow bug. But I am quite happy for it to make these re-arrangements for the code it generates - I am always happy with more efficient object code that follows the "as if" rule. (If the expression is floating point, or the target has unusual capabilities, so that an overflow is detectable then of course such re-arrangements are not valid as they would break the "as-if" rule.) > I interpreted that comment as meaning that "whether or not the > behavior is undefined is fully associative". I guess that what you > actually meant was "if the behavior is undefined, the compiler is free > to rearrange the associations". That is better phrasing than I used. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-31 15:54 -0700 |
| Message-ID | <10vie7n$1r8io$1@kst.eternal-september.org> |
| In reply to | #399558 |
David Brown <david.brown@hesbynett.no> writes:
> On 31/05/2026 16:24, James Kuyper wrote:
>> On 2026-05-31 07:18, David Brown wrote:
[...]
>>> People might think they affect the order of evaluation, such as when you
>>> have function calls :
>>>
>>> u = foo(x) + (foo(y) + foo(z));
>>>
>>> Some people might think the use of parentheses means that "foo(y)" and
>>> "foo(z)" are called before "foo(x)", when the order of all these calls
>>> (and the additions) is unspecified. (Again, a given compiler might be
>>> influenced by the parentheses, but the language does not require it.
>>
>> You're correct with regard to the function calls, but the
>> parenthesized addition must be performed first, and the other one
>> second, which may make a difference, for the same reasons given in my
>> previous paragraph.
>
> The parentheses do not dictate the order of evaluation. But you are
> correct - and it's worth pointing out, so thank you for doing that -
> that for floating point operations, the grouping of operations can
> affect the result.
The parentheses do not dictate the order of evaluation *of the
operands*. Each "+" can be evaluated (the addition performed)
only after the values of its operands are known. But regardless
of parentheses or operator precedence, the three operands foo(x),
foo(y), and foo(z) can be evaluated in any of 6 possible orders.
(It's different when you have operations like "&&", "||", and ",",
which imposes additional sequence points.)
> If you are talking about floating point arithmetic (I was thinking of
> integer arithmetic, but did not specify), then the operations are not
> necessarily commutative or associative, and the compiler cannot then
> re-arrange the operations unless it knows that doing so does not
> affect the result.
It's not just floating-point. Signed integer overflow is also relevant.
(INT_MIN + INT_MAX) + 1 is well defined. (INT_MIN + INT_MAX) +1
is equivalent, and is also well defined. INT_MIN + (INT_MAX +1)
has undefined behavior.
> But except for specific cases, the order of evaluation - both for the
> values and side-effects - of sub-expressions is unspecified. Indeed,
> they are unsequenced - the evaluations can interleave.
>
> Usually, both sub-expressions of a binary operator will be evaluated
> before the operator itself, simply because usually the results of the
> operator cannot be calculated until the sub-expression's values are
> known. But this is not a requirement of the language - if the
> compiler can get the same results without doing so, it is free to pick
> a different order. "(a + b) * 0" does not need to evaluate "a", "b",
> or "a + b" at all unless there is a possibility of a side-effect - and
> it can perform the side-effects in any order. "a + (b + c)" can check
> "a" for a trap representation and deal with that before looking at "b"
> and "c" or the results of "b + c", even though it cannot (for floating
> point operations) re-arrange the code to do "a + b" first.
Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not
required to do so, and (INT_MAX + 1) * 0 still has undefined
behavior. Undefined behavior is determined by the rules of the
abstract machine *without* any adjustments permitted by the as-if
rule.
[...]
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 08:39 +0200 |
| Message-ID | <10vj9e7$21h40$2@dont-email.me> |
| In reply to | #399569 |
On 01/06/2026 00:54, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 31/05/2026 16:24, James Kuyper wrote: >>> On 2026-05-31 07:18, David Brown wrote: > [...] >>>> People might think they affect the order of evaluation, such as when you >>>> have function calls : >>>> >>>> u = foo(x) + (foo(y) + foo(z)); >>>> >>>> Some people might think the use of parentheses means that "foo(y)" and >>>> "foo(z)" are called before "foo(x)", when the order of all these calls >>>> (and the additions) is unspecified. (Again, a given compiler might be >>>> influenced by the parentheses, but the language does not require it. >>> >>> You're correct with regard to the function calls, but the >>> parenthesized addition must be performed first, and the other one >>> second, which may make a difference, for the same reasons given in my >>> previous paragraph. >> >> The parentheses do not dictate the order of evaluation. But you are >> correct - and it's worth pointing out, so thank you for doing that - >> that for floating point operations, the grouping of operations can >> affect the result. > > The parentheses do not dictate the order of evaluation *of the > operands*. Each "+" can be evaluated (the addition performed) > only after the values of its operands are known. But regardless > of parentheses or operator precedence, the three operands foo(x), > foo(y), and foo(z) can be evaluated in any of 6 possible orders. > (It's different when you have operations like "&&", "||", and ",", > which imposes additional sequence points.) > Yes. And I have seen code where the author believed that the parentheses /did/ affect the order of evaluation of the "foo" calls. It is definitely a misunderstanding people can make, though I of course have no idea how often people make it. >> If you are talking about floating point arithmetic (I was thinking of >> integer arithmetic, but did not specify), then the operations are not >> necessarily commutative or associative, and the compiler cannot then >> re-arrange the operations unless it knows that doing so does not >> affect the result. > > It's not just floating-point. Signed integer overflow is also relevant. > > (INT_MIN + INT_MAX) + 1 is well defined. (INT_MIN + INT_MAX) +1 > is equivalent, and is also well defined. INT_MIN + (INT_MAX +1) > has undefined behavior. Compilers can re-arrange integer arithmetic, despite new overflows, if they know the result is the same. On pretty much any current processor, a compiler generating code for integer "a + b + c" could do the additions in any order - treating the operations as commutative and fully associative. The final result will be the same in every case where the original expression did not overflow (i.e., every case with defined behaviour). If the implementation makes overflow detectable in some way (such as by "-fsanitize=signed-arithmetic-overflow"), or the hardware does something that gives different results from overflow (saturating, hardware traps), then it's an entirely different matter. > >> But except for specific cases, the order of evaluation - both for the >> values and side-effects - of sub-expressions is unspecified. Indeed, >> they are unsequenced - the evaluations can interleave. >> >> Usually, both sub-expressions of a binary operator will be evaluated >> before the operator itself, simply because usually the results of the >> operator cannot be calculated until the sub-expression's values are >> known. But this is not a requirement of the language - if the >> compiler can get the same results without doing so, it is free to pick >> a different order. "(a + b) * 0" does not need to evaluate "a", "b", >> or "a + b" at all unless there is a possibility of a side-effect - and >> it can perform the side-effects in any order. "a + (b + c)" can check >> "a" for a trap representation and deal with that before looking at "b" >> and "c" or the results of "b + c", even though it cannot (for floating >> point operations) re-arrange the code to do "a + b" first. > > Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not > required to do so, and (INT_MAX + 1) * 0 still has undefined > behavior. Undefined behavior is determined by the rules of the > abstract machine *without* any adjustments permitted by the as-if > rule. > Sure. (And it's a good point to make.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 02:33 -0700 |
| Message-ID | <10vjjlj$24d8c$1@kst.eternal-september.org> |
| In reply to | #399581 |
David Brown <david.brown@hesbynett.no> writes:
> On 01/06/2026 00:54, Keith Thompson wrote:
[...]
>> (INT_MIN + INT_MAX) + 1 is well defined. (INT_MIN + INT_MAX) +1
>> is equivalent, and is also well defined. INT_MIN + (INT_MAX +1)
>> has undefined behavior.
Oops, I forgot to delete some parentheses. I meant to write that
INT_MIN + INT_MAX + 1 is equivalent to (INT_MIN + INT_MAX) + 1.
The redundant parentheses don't impose any change in semantics.
> Compilers can re-arrange integer arithmetic, despite new overflows, if
> they know the result is the same. On pretty much any current
> processor, a compiler generating code for integer "a + b + c" could do
> the additions in any order - treating the operations as commutative
> and fully associative. The final result will be the same in every
> case where the original expression did not overflow (i.e., every case
> with defined behaviour).
Right, good point. Since (INT_MIN + INT_MAX) + 1 is well defined,
if a compiler rearranges it so it evaluates INT_MAX + 1 as an
intermediate result, that's permitted **if** the result is the same.
(It makes more sense if the operands are variables with those values
rather than constants.) A compiler can take advantage of how the
hardware works. UB applies to the C source code, not (necessarily)
to the operations that are performed by the actual machine. If it
generates code that yields the correct result by consulting a Ouija
board, that's still conforming.
[...]
--
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]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-02 11:48 +0200 |
| Message-ID | <10vm8tj$3uus7$7@dont-email.me> |
| In reply to | #399569 |
On 2026-06-01 00:54, Keith Thompson wrote: >> [...] > > Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not > required to do so, and (INT_MAX + 1) * 0 still has undefined > behavior. Undefined behavior is determined by the rules of the > abstract machine *without* any adjustments permitted by the as-if > rule. This is something I really don't get in the actual C-logic... Using constants that can be determined at compile time is UB here, despite the '* 0' mathematically indicating an IMO clear semantics, but using variables is only UB possibly at runtime? And despite all that the latter might not even get triggered because it's probably optimized away? - I can't help, this sounds really crude. Is there any rationale from the _software designer_'s perspective? Janis
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-06-02 06:37 -0400 |
| Message-ID | <10vmbot$2s1tq$1@dont-email.me> |
| In reply to | #399608 |
On 2026-06-02 05:48, Janis Papanagnou wrote: > On 2026-06-01 00:54, Keith Thompson wrote: >>> [...] >> >> Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not >> required to do so, and (INT_MAX + 1) * 0 still has undefined >> behavior. Undefined behavior is determined by the rules of the >> abstract machine *without* any adjustments permitted by the as-if >> rule. > > This is something I really don't get in the actual C-logic... > > Using constants that can be determined at compile time is UB here, > despite the '* 0' mathematically indicating an IMO clear semantics, > but using variables is only UB possibly at runtime? And despite all > that the latter might not even get triggered because it's probably > optimized away? - I can't help, this sounds really crude. > > Is there any rationale from the _software designer_'s perspective? Yes - the rationale is to keep things simple. The abstract machine has exactly the semantics specified in the standard. Whether or not a given expression has undefined behavior depends only upon the operator and it's operands, and not on the context in which it is invoked. It's only when the abstract machine has defined observable behavior when executing a program that it becomes meaningful to allow optimizations that preserve that behavior.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-02 05:06 -0700 |
| Subject | Constants and undefined behavior |
| Message-ID | <86ik81cfk5.fsf_-_@linuxsc.com> |
| In reply to | #399608 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-01 00:54, Keith Thompson wrote:
>
>>> [...]
>>
>> Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not
>> required to do so, and (INT_MAX + 1) * 0 still has undefined
>> behavior. Undefined behavior is determined by the rules of the
>> abstract machine *without* any adjustments permitted by the as-if
>> rule.
>
> This is something I really don't get in the actual C-logic...
>
> Using constants that can be determined at compile time is UB here,
> despite the '* 0' mathematically indicating an IMO clear semantics,
> but using variables is only UB possibly at runtime? [...]
There's an important distinction to make here. Consider this
program:
#include <limits.h>
int
foo(){
int zero = (INT_MAX+1)*0;
return zero;
}
int
main(){
return 0;
}
This program does not transgress the bounds of undefined behavior.
Even more than that, the program is strictly conforming, and must be
accepted by a conforming implementation.
Now let's change the program slightly:
#include <limits.h>
int
foo(){
static int zero = (INT_MAX+1)*0;
return zero;
}
int
main(){
return 0;
}
This program does transgress the bounds of undefined behavior. The
reason for the difference is that in the first program the semantics
of foo() is to evaluate the expression to be stored in 'zero' only
at runtime, whereas in the second program the semantics of foo() is
to evaluate the expression to be stored in 'zero' before program
startup (informally, "at compile time"). What matters is not
whether the offending expression /might/ be evaluated "at compile
time", but whether the offending expression /must/ be evaluated "at
compile time". Only in the second case is undefined behavior
inevitable (and thus it does not occur in the first program).
Fine point: strictly speaking, I believe the C standard allows even
the second program to complete translation phase 8 successfully, and
for any offending behavior to occur only when we actually try to run
the program. To say that another way, there is no requirement that
possible nasal demons be made manifest at any point before an actual
attempted execution. On the other hand, because that possibility is
there lurking in the background, there is no requirement that the
program be accepted, and could be rejected by a conforming compiler.
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web