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 360 — 21 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: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:37 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 16:31 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 13:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 23:49 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:04 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:10 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:50 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:20 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 12:39 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 23:15 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 18:51 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 09:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:07 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-09 01:25 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-09 18:29 -0400
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:01 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:36 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 16:49 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 15:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 18:08 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-11 16:30 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:52 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-12 02:20 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 15:47 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 16:36 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:43 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 17:41 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 10:41 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 10:49 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:15 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 18:06 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-07 22:34 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 23:05 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:19 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:12 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 14:37 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 18:30 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:55 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:32 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:47 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 08:56 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:38 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 14:05 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 15:38 -0700
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:07 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:43 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:02 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:34 +0200
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 10:58 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 12:27 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 13:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:08 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:02 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:45 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-10 15:11 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 22:44 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:19 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:50 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 16:28 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 23:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 18:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 01:54 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:37 +0200
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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 06:41 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:24 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 08:35 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-09 00:54 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:08 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 13:40 -0700
Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 14:05 -0700
Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 15:17 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 14:53 +0100
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:30 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-09 17:13 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:34 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 09:04 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-10 11:10 +0100
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:29 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 03:17 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:43 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:08 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-11 09:10 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:29 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-12 12:55 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:12 +0200
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 15:13 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 00:37 +0200
Re: Expression statements (was Re: Meaning of "expression") scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:05 +0000
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 01:18 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:41 -0700
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 20:41 -0400
Re: Expression statements (was Re: Meaning of "expression") tTh <tth@none.invalid> - 2026-06-09 19:27 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 19:19 +0100
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:22 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:22 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:56 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-07 13:37 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-07 15:09 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 00:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 12:41 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 17:37 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:05 +0200
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
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-03 22:30 +0000
Re: Parentheses Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-03 16:24 -0700
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 02:03 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 01:12 +0100
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 01:58 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 11:37 +0100
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 10:51 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 12:47 +0100
Re: Parentheses Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 14:57 +0200
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 14:31 +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) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-04 00:11 +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: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-03 13:14 +0000
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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 02:34 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 12:40 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 14:35 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 14:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:57 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 16:27 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 16:46 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 20:15 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 20:54 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 20:29 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:47 +0100
Famous (hopefully last) words [on this topic] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 00:27 +0200
Re: Famous (hopefully last) words [on this topic] Bad Post <invalid@invalid.invalid> - 2026-06-05 01:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 16:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 00:44 +0100
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 17:26 -0700
Re: this girl calls c ugly antispam@fricas.org (Waldek Hebisch) - 2026-06-05 12:58 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-05 14:27 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:47 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 00:53 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 11:04 +0100
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:34 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:44 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-06 07:39 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 15:25 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 09:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 12:39 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 15:42 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 16:50 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 20:29 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 17:23 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:47 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 19:57 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:34 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:28 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 21:58 +0000
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-06-04 23:25 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:49 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 19:47 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 21:04 +0200
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 19:13 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 10:34 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 12:11 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-04 16:33 -0400
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:02 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:54 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:49 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:01 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 11:53 -0700
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 18:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:19 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:31 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:41 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:49 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:03 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 00:18 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 03:02 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 14:04 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:49 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 15:13 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 17:53 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 11:59 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:21 +0200
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 06:38 -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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:58 -0700
Re: this girl calls c ugly dave_thompson_2@comcast.net - 2026-06-06 19:02 -0400
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 10 of 18 — ← Prev page 1 … 8 9 [10] 11 12 … 18 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-06 03:22 +0000 |
| Message-ID | <11003or$t9b$1@reader1.panix.com> |
| In reply to | #399748 |
In article <86bjdpayv0.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> [snip] >> But taking a closer look at the standard, I'm not 100% sure that the >> language requires a diagnostic, though I think that's the intent. >> The relevant constraint is: >> >> Each constant expression shall evaluate to a constant that is >> in the range of representable values for its type. >> >> If I squint really hard, I can argue that the entire expression >> has to be a constant expression, but it doesn't say that its >> subexpressions are constant expressions -- and *if* INT_MAX + >> 1 evaluates to INT_MIN in the current implementation, then >> (INT_MAX + 1) * 0 evaluates to 0 and therefore satisfies the >> constraint. > >My reasoning is as follows. > >To determine if the constraint is satisfied, the compiler must >first evaluate the expression (INT_MAX + 1) * 0. > >To evaluate the expression (INT_MAX + 1) * 0, the compiler must >first evaluate the sub-expression (INT_MAX + 1). > >Because the expression (INT_MAX + 1) overflows, the behavior is >undefined, and the compiler is free to decide that the value of >the sub-expression (INT_MAX + 1) is, let's say, 12. > >The compiler next evaluates the overall expression as 12*0, which >is 0 (an int). > >This result of the overall expression satisfies the constraint, >and so the compiler is not obliged to generate a diagnostic. The text of the standard explicitly carves this out; or, rather, it attempts to. If the result of an expression is not representable in the target type, _regardless of whether that's due to UB or not_, a diagnostic is required. But as it happens, I think I can see how your interpretation may be valid: if, as a result of UB, the expression evaluates to "0" (or 12 or something simiilar) that _is_ representable, then there _is no constraint violation_ and so no diagnostic is required. I do not believe that that is the intent. But it _is_ conformant with the text of the standard. This is a problem with the C standard: it is insufficiently precise, as the semantics of the language are not formally defined. >[snip] >I see no basis for this belief. My conclusions are based on what >the C standard actually says, rather than guesses about some >unstated "intentions". I think you would do well to reach your >conclusions based more on the actual text of the C standard, and >less on your interpretation of what the text was "intended" to >mean. The same could be said to you, as well. There exists a reading of the standard by which your `foo`-containing program is not strictly conforming . But that way lies madness; C is not a formally specified language. Given that as an objective fact, we must accept intent, consistency, and other "soft" aspects when considering its definition. That sort of sucks, but here we are. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-05 23:56 -0700 |
| Message-ID | <1100gbk$1lt8i$2@kst.eternal-september.org> |
| In reply to | #399761 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> The text of the standard explicitly carves this out; or, rather,
> it attempts to. If the result of an expression is not
> representable in the target type, _regardless of whether that's
> due to UB or not_, a diagnostic is required.
[...]
How would an expression (appearing in a context that requires an
integer constant expression) not "evaluate to a constant that is in
the range of representable values for its type" other than by UB?
I can't think of an example, but I'd be interested in seeing one.
Note in particular that UINT_MAX+1U is well defined, not an overflow.
--
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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-07 13:37 +0000 |
| Message-ID | <1103s6v$78r$1@reader1.panix.com> |
| In reply to | #399767 |
In article <1100gbk$1lt8i$2@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >[...] >> The text of the standard explicitly carves this out; or, rather, >> it attempts to. If the result of an expression is not >> representable in the target type, _regardless of whether that's >> due to UB or not_, a diagnostic is required. >[...] > >How would an expression (appearing in a context that requires an >integer constant expression) not "evaluate to a constant that is in >the range of representable values for its type" other than by UB? It wouldn't. But because it's UB, it could evaluate to anything, including something that didn't violate the constraint. >I can't think of an example, but I'd be interested in seeing one. In terms of a practical, working compiler? I doubt that one exists. >Note in particular that UINT_MAX+1U is well defined, not an overflow. Yes. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-07 15:09 -0700 |
| Message-ID | <1104q77$2qkh5$1@kst.eternal-september.org> |
| In reply to | #399783 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <1100gbk$1lt8i$2@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>[...]
>>> The text of the standard explicitly carves this out; or, rather,
>>> it attempts to. If the result of an expression is not
>>> representable in the target type, _regardless of whether that's
>>> due to UB or not_, a diagnostic is required.
>>[...]
>>
>>How would an expression (appearing in a context that requires an
>>integer constant expression) not "evaluate to a constant that is in
>>the range of representable values for its type" other than by UB?
>
> It wouldn't. But because it's UB, it could evaluate to
> anything, including something that didn't violate the
> constraint.
>
>>I can't think of an example, but I'd be interested in seeing one.
>
> In terms of a practical, working compiler? I doubt that one
> exists.
I actually meant in terms of the standard, not of any particular
compiler.
I can't think of an example, but maybe someone else can.
[...]
--
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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-08 02:33 +0000 |
| Message-ID | <11059mm$mv5$2@reader1.panix.com> |
| In reply to | #399784 |
In article <1104q77$2qkh5$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> In article <1100gbk$1lt8i$2@kst.eternal-september.org>, >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>[...] >>>> The text of the standard explicitly carves this out; or, rather, >>>> it attempts to. If the result of an expression is not >>>> representable in the target type, _regardless of whether that's >>>> due to UB or not_, a diagnostic is required. >>>[...] >>> >>>How would an expression (appearing in a context that requires an >>>integer constant expression) not "evaluate to a constant that is in >>>the range of representable values for its type" other than by UB? >> >> It wouldn't. But because it's UB, it could evaluate to >> anything, including something that didn't violate the >> constraint. >> >>>I can't think of an example, but I'd be interested in seeing one. >> >> In terms of a practical, working compiler? I doubt that one >> exists. > >I actually meant in terms of the standard, not of any particular >compiler. > >I can't think of an example, but maybe someone else can. > >[...] Oh. Well, I suppose something that relied on _IB_, like conversion from a large unsigned integer type to a smaller signed integer type that led to a trap, might fall into that category. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-08 00:16 -0700 |
| Message-ID | <8633yxa4dg.fsf@linuxsc.com> |
| In reply to | #399761 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86bjdpayv0.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> [snip] >>> But taking a closer look at the standard, I'm not 100% sure that the >>> language requires a diagnostic, though I think that's the intent. >>> The relevant constraint is: >>> >>> Each constant expression shall evaluate to a constant that is >>> in the range of representable values for its type. >>> >>> If I squint really hard, I can argue that the entire expression >>> has to be a constant expression, but it doesn't say that its >>> subexpressions are constant expressions -- and *if* INT_MAX + >>> 1 evaluates to INT_MIN in the current implementation, then >>> (INT_MAX + 1) * 0 evaluates to 0 and therefore satisfies the >>> constraint. >> >> My reasoning is as follows. >> >> To determine if the constraint is satisfied, the compiler must >> first evaluate the expression (INT_MAX + 1) * 0. >> >> To evaluate the expression (INT_MAX + 1) * 0, the compiler must >> first evaluate the sub-expression (INT_MAX + 1). >> >> Because the expression (INT_MAX + 1) overflows, the behavior is >> undefined, and the compiler is free to decide that the value of >> the sub-expression (INT_MAX + 1) is, let's say, 12. >> >> The compiler next evaluates the overall expression as 12*0, which >> is 0 (an int). >> >> This result of the overall expression satisfies the constraint, >> and so the compiler is not obliged to generate a diagnostic. > > The text of the standard explicitly carves this out; or, rather, > it attempts to. If the result of an expression is not > representable in the target type, _regardless of whether that's > due to UB or not_, a diagnostic is required. That's right. However, the key point here is that it is the implementation that determines (following the semantic rules given in the C standard) what the value is, and so whether the value is representable in the type of the expression. Because of the undefined behavior present in the expression in question, the implementation is free to choose a value that /is/ representable, and of the appropriate type, in which case no diagnostic is required. > But as it happens, I think I can see how your interpretation may > be valid: if, as a result of UB, the expression evaluates to "0" > (or 12 or something simiilar) that _is_ representable, then > there _is no constraint violation_ and so no diagnostic is > required. Right. In fact the reasoning doesn't have to be so elaborate. Just by looking at the types of the operands, a compiler can determine the result is type int. Then, just by noticing the multiplication by 0, a compiler could decide that the result is zero, because the compiler is free to assume that there was no undefined behavior in the left-hand side expression. Whether the left-hand size expression has undefined behavior doesn't even have to be checked to decide that (INT_MAX+1)*0 is 0, and so it can satisfy the constraints of an integer constant expression. > I do not believe that that is the intent. But it _is_ > conformant with the text of the standard. I think your intuition is leading you astray. The people who wrote the C standard have gone to great lengths to say (write) what they mean and mean what they say (write). I don't see any evidence to suggest that this property doesn't apply in the situation being discussed. > This is a problem with the C standard: it is insufficiently > precise, as the semantics of the language are not formally > defined. On the contrary, the C standard is quite precise: when a program construct is encountered that the Standard identifies as having undefined behavior, the Standard IMPOSES NO REQUIREMENTS on what behavior may result. That rule may not be what someone wants, but there isn't any question about what is allowed, which is anything at all. >> [snip] >> I see no basis for this belief. My conclusions are based on what >> the C standard actually says, rather than guesses about some >> unstated "intentions". I think you would do well to reach your >> conclusions based more on the actual text of the C standard, and >> less on your interpretation of what the text was "intended" to >> mean. > > The same could be said to you, as well. There exists a reading > of the standard by which your `foo`-containing program is not > strictly conforming . The difference is my reading is based on what the C standard actually says, and not on any guesses about "intent" or whether the result "makes sense". When reading the C standard it's important to develop the habit of reading the text as neutrally as one can, and not inject any subconscious ideas about what it ought to be saying. > But that way lies madness; C is not a > formally specified language. Given that as an objective fact, > we must accept intent, consistency, and other "soft" aspects > when considering its definition. The C standard is not written in formal mathematical language, but it is written in formal English. Certainly there are places in the standard where what is said does a poor job of conveying what is expected. But the particular case of (INT_MAX+1)*0 is not one of them.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-08 12:41 +0000 |
| Message-ID | <1106d97$huo$1@reader1.panix.com> |
| In reply to | #399789 |
In article <8633yxa4dg.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> [snip]
>> But as it happens, I think I can see how your interpretation may
>> be valid: if, as a result of UB, the expression evaluates to "0"
>> (or 12 or something simiilar) that _is_ representable, then
>> there _is no constraint violation_ and so no diagnostic is
>> required.
>
>Right. In fact the reasoning doesn't have to be so elaborate.
>Just by looking at the types of the operands, a compiler can
>determine the result is type int. Then, just by noticing the
>multiplication by 0, a compiler could decide that the result is
>zero, because the compiler is free to assume that there was no
>undefined behavior in the left-hand side expression. Whether the
>left-hand size expression has undefined behavior doesn't even have
>to be checked to decide that (INT_MAX+1)*0 is 0, and so it can
>satisfy the constraints of an integer constant expression.
I understand why you are saying this. The relevant part of the
syntax is,
multiplicative-expression:
...
multiplicative-expression * cast-expression
...
Since UB imposes no requirements of any kind, the translator is
free to assume that the evaluation of the
`multiplicative-expression` component is well-defined, and
then multiplication by a `cast-expression` that evaluates to 0
is just 0.
But it is a good exercise to back that up by the letter of the
standard. Recall that in this context, Keith was talking about
`case` labels.
The grammar given in the standard explicitly says that, in that
position, the expression must be a `constant-expression` (sec
6.8.2 ["Labeled statements"] para 1, "Syntax"). Constant
expressions must be evaluated in accordance with the semantic
rules of the abstract machine (sec 6.6 para 17), the rules for
which are spelled out in sec 5.1.2.4, specifically para 1, which
read, "The semantic descriptions in this document describe the
behavior of an abstract machine in which issues of optimization
are irrelevant" and para 4, which says that "all expressions
are evaluated as specified by the semantics."
Para (4) goes on to say, "an actual implementation is not
required to evaluate part of an expression if it can deduce that
its value is not used and that no needed side effects are
produced (including any caused by calling a function or through
volatile access to an object)." So a translator is free to
replace, e.g., `(2 + 2)*0)` with 0.
But that doesn't mean that the presence of UB in this context is
insignificant; in fact, this entire interpretation rests on it.
>> I do not believe that that is the intent. But it _is_
>> conformant with the text of the standard.
>
>I think your intuition is leading you astray. The people who
>wrote the C standard have gone to great lengths to say (write)
>what they mean and mean what they say (write). I don't see any
>evidence to suggest that this property doesn't apply in the
>situation being discussed.
This is not an arugment; it's an assertion, based on your own
intuition and your feelings about the text of the standard and
the level of precision you assume it takes.
In this specific context, Keith raised a valid point: how can
the constraint mentioned in sec 6.6 para 4 ever be violated
_without_ UB? And since C imposes no requirement _at all_ with
respect to how a translator assesses the behavior of evaluating
a UB-bearing expression, then how can the diagnostic requirement
for a constraint violation ever be fulfilled here?
My example is this:
constexpr int A = ~0U;
The type of the rhs is `int` and the value is not representable
in a signed int. As expected, this fails to compile, with a
diagnostic about the constraint violation:
```
term% cc -std=c23 -c constraint.c
constraint.c:1:19: error: constexpr initializer evaluates to 4294967295 which is not exactly representable in type 'const int'
1 | constexpr int A = ~0U;
| ^
1 error generated.
term%
```
Adding an `(int)` cast takes advantage of IB, but allows the
program to compile:
```
term% cat constraint.c
constexpr int A = (int)~0U;
term% clang -Werror -pedantic -std=c23 -c constraint.c
term%
```
>> This is a problem with the C standard: it is insufficiently
>> precise, as the semantics of the language are not formally
>> defined.
>
>On the contrary, the C standard is quite precise:
Consider that your definition of "precise" may not be shared.
This is an example of your own subjectivity.
>when a program
>construct is encountered that the Standard identifies as having
>undefined behavior, the Standard IMPOSES NO REQUIREMENTS on what
>behavior may result. That rule may not be what someone wants, but
>there isn't any question about what is allowed, which is anything
>at all.
My statement, that you quoted and responded to, was not limited
to undefined behavior. Rather, it was a general statement about
the imprecision of the C standard.
For whatever reason you have chosen to take that general
statement, and respond to it by posting about one thing that is
clearly defined in the standard, and that further, I believe
every participant in this discussion agrees on. But clarity and
precision on a single point does not mean that the entire
standard, taken as a whole, is similarly precise and clear.
In fact, what I have been arguing all along is exactly what you
wrote above: the standard imposes _no requirements_ on the
resultant behavior of a program when a translator encounters
a program construct (for example, something like `INT_MAX + 1`,
whether immediately multiplied by zero or not) in the course of
translating that program. The C standard does _not_ explicitly
say otherwise.
Unfortunately, the C standard is simply not a precise, formal
document. This is well-known, and it's hardly C's fault: indeed
most of the applications of formalized descriptions of PL
semantics to practical programming languages postdates C's
invention; Dana Scott didn't introduce the term, "operational
semantics" until 1970, and it didn't start to make a serious
impact on languages until later.
That you would limit that statement to UB only betrays a lack of
understanding of what you responded to. Whether that is my
fault or yours, I don't know.
[Note: I feel obliged to say that this is not the fault of the C
committee, Dennis Ritchie, Ken Thompson, Brian Kernighan, PJ
Plauger, Jean-Heyd Meneide, or anyone else; rather, it is an
unfortunate consequence of history, and one that cannot
reasonably be corrected.]
>>> [snip]
>>> I see no basis for this belief. My conclusions are based on what
>>> the C standard actually says, rather than guesses about some
>>> unstated "intentions". I think you would do well to reach your
>>> conclusions based more on the actual text of the C standard, and
>>> less on your interpretation of what the text was "intended" to
>>> mean.
>>
>> The same could be said to you, as well. There exists a reading
>> of the standard by which your `foo`-containing program is not
>> strictly conforming .
>
>The difference is my reading is based on what the C standard
>actually says, and not on any guesses about "intent" or whether
>the result "makes sense". When reading the C standard it's
>important to develop the habit of reading the text as neutrally as
>one can, and not inject any subconscious ideas about what it ought
>to be saying.
Your reading of the standard is subjective and, as far as I can
tell, based on your own intuitions and presumptions of intent.
Indeed we see direct evidence of this in the message I quoted
above, where you ascribe a certain type of formality to that
document, that is not warranted. Notice that your response to
my post about _an_ intepretation of that document is not to
point out how the text invalidates that reading, but rather, an
admonission on how to read the standard.
You would do well to take a moment and examine your own
preconceptions in how you read that document and approach the C
langauge.
>> But that way lies madness; C is not a
>> formally specified language. Given that as an objective fact,
>> we must accept intent, consistency, and other "soft" aspects
>> when considering its definition.
>
>The C standard is not written in formal mathematical language, but
>it is written in formal English.
Correct.
The C standard is written in the formal _register_; that is a
matter of voice, but is dramatically different than a formal
document with rigorously defined semantics. It is full of terms
of art, and things that are imprecisely and informally specified
in prose. The C standard strives, but sadlyfalls short in many
places.
Plenty of documents are written in a formal register and are
still ambiguous and imprecise. That is one of the problems with
trying to define something like a programming language precisely
in prose.
Gogol wrote a rather famous story about a non-existent officer
who was accidentally manifested by a missing comma. He didn't
exist, yet rose to become one of the Czar's favorites, as he
never made a mistake (since he did not exist).
Perhaps you will meditate on the implied analogy.
>Certainly there are places in
>the standard where what is said does a poor job of conveying what
>is expected. But the particular case of (INT_MAX+1)*0 is not one
>of them.
This is a strawman. You are correct that the standard is clear
as to the meaning, or more precisely lack thereof, of
`(INT_MAX + 1)*0`, when considered as an isolated expression.
What is much less clear are the implications of that when
translated.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-08 17:37 +0000 |
| Message-ID | <1106ulg$3nj$1@reader1.panix.com> |
| In reply to | #399790 |
In article <1106d97$huo$1@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>My example is this:
>
> constexpr int A = ~0U;
>
>The type of the rhs is `int` and the value is not representable
*sigh* "The type of the rhs is `unsigned int` and the value is
not representable in a `signed int`.
Perhaps,
constexpr int A = (unsigned int)INT_MAX + 1;
...is an even better example.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-09 16:05 +0200 |
| Message-ID | <11096if$1naub$2@dont-email.me> |
| In reply to | #399790 |
On 2026-06-08 14:41, Dan Cross wrote: > [...] > > Unfortunately, the C standard is simply not a precise, formal > document. This is well-known, and it's hardly C's fault: indeed > most of the applications of formalized descriptions of PL > semantics to practical programming languages postdates C's > invention; Dana Scott didn't introduce the term, "operational > semantics" until 1970, and it didn't start to make a serious > impact on languages until later. Disclaimer: I haven't read Dana Scott's source that you refer to. Myself I've heard that term at university during the early 1980's. In 1970 my "knowledge" about computers was on Star-Trek level only. I just want to point out Algol 68's formal specification (pre-1970). And provide this quote on "Operational Semantic" (from Wikipedia): "The concept of operational semantics was used for the first time in defining the semantics of Algol 68." But Algol 68 was certainly outstanding here, concerning its formal specification, compared to most other languages back these days. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-06-02 13:59 -0700 |
| Message-ID | <10vng7e$377sq$1@dont-email.me> |
| In reply to | #399569 |
On 5/31/2026 3:54 PM, 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.) > >> 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. > > [...] > 10 + 5 - 7 + 3 Oh my this is an error for the programmers logic! they forgot to do: 10 + 5 - (7 + 3) ?
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 13:05 +0000 |
| Message-ID | <10vmke4$4bm$1@reader1.panix.com> |
| In reply to | #399550 |
In article <10vh1eo$1ei50$2@dont-email.me>, Bart <bc@freeuk.com> 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. Do you have
>an example where they make no difference but people might think they do?
This is all a bit of a distraction from the original point that
David and Richard Harnden were trying to make, which seemed
clear enough to me, but perhaps should have been given with a
better example. Maybe something like:
d = a*b + c;
Is equivalent to,
d = (a*b) + c;
And in this case, the parentheses are superfluous and don't
change the order of evaluation of the expression as far as the
language is concerned. Whether a compiler rearranges it in
generated code in a way that is more convenient of faster or
whatever is another matter.
I would quibble with this idea that the compiler "removes"
parentheses. I get the intuition, but C is not Go where the
compiler "inserts" semi-colons for you, and has no analogous
concept. Rather, as I think Keith said, expressions are parsed
into some internal representation, and then transformed into
something like an abstract syntax tree, where syntactic
notations like parentheses are lost.
Both expressions above correspond to an AST like:
┌───────┐
│BinOp +│
└───────┘
╱ ╲
╱ ╲
┌───────┐ ┌───────┐
│BinOp *│ │Sym `c`│
└───────┘ └───────┘
╱ ╲
╱ ╲
┌───────┐ ┌───────┐
│Sym `a`│ │Sym `b`│
└───────┘ └───────┘
But the to get to that, it may be that the compiler uses a
different initial representation, like a parse tree that more
closely resembles the source language grammar. Here, the
two expressions might have different parsed representations.
E.g., for the first, simplifying heavily, may look something
like this:
┌──────┐
│ expr │
└──────┘
╱ │ ╲
╱ │ ╲
┌─────┐ . ┌─────┐
│term │ (+) │term │
└─────┘ ' └─────┘
╱ │ ╲ │
╱ │ ╲ │
┌─────┐ . ┌─────┐ ┌─────┐
│ident│ (*) │ident│ │ident│
└─────┘ ' └─────┘ └─────┘
│ │ │
│ │ │
.─. .─. .─.
(`a`) (`b`) (`c`)
`─' `─' `─'
While the second might add an extra `expr` node, as in:
┌──────┐
│ expr │
└──────┘
╱ │ ╲
╱ │ ╲
┌──────┐ . ┌─────┐
│ expr │ (+) │term │
└──────┘ ' └─────┘
│ │
│ │
┌─────┐ ┌─────┐
│term │ │ident│
└─────┘ └─────┘
╱ │ ╲ │
╱ │ ╲ │
┌─────┐ . ┌─────┐ .─.
│ident│ (*) │ident│ (`c`)
└─────┘ ' └─────┘ `─'
│ │
│ │
.─. .─.
(`a`) (`b`)
`─' `─'
I believe that the answer, for most compilers that parse and
then convert to an AST, the second is more likely to be created
than the first. However, given that the same AST is created
from both parse trees, this is unlikely to have an effect on the
object code ultimately output from the compiler.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-02 14:38 +0100 |
| Subject | Parentheses (was: this girl calls c ugly) |
| Message-ID | <10vmmc2$2utb2$2@dont-email.me> |
| In reply to | #399623 |
On 02/06/2026 14:05, Dan Cross wrote: > In article <10vh1eo$1ei50$2@dont-email.me>, Bart <bc@freeuk.com> 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. Do you have >> an example where they make no difference but people might think they do? > > This is all a bit of a distraction from the original point that > David and Richard Harnden were trying to make, which seemed > clear enough to me, but perhaps should have been given with a > better example. Maybe something like: > > d = a*b + c; > > Is equivalent to, > > d = (a*b) + c; > > And in this case, the parentheses are superfluous and don't > change the order of evaluation of the expression as far as the > language is concerned. Whether a compiler rearranges it in > generated code in a way that is more convenient of faster or > whatever is another matter. > > I would quibble with this idea that the compiler "removes" > parentheses. I get the intuition, but C is not Go where the > compiler "inserts" semi-colons for you, and has no analogous > concept. Rather, as I think Keith said, expressions are parsed > into some internal representation, and then transformed into > something like an abstract syntax tree, where syntactic > notations like parentheses are lost. > > Both expressions above correspond to an AST like: > > ┌───────┐ > │BinOp +│ > └───────┘ > ╱ ╲ > ╱ ╲ > ┌───────┐ ┌───────┐ > │BinOp *│ │Sym `c`│ > └───────┘ └───────┘ > ╱ ╲ > ╱ ╲ > ┌───────┐ ┌───────┐ > │Sym `a`│ │Sym `b`│ > └───────┘ └───────┘ > > But the to get to that, it may be that the compiler uses a > different initial representation, like a parse tree that more > closely resembles the source language grammar. Here, the > two expressions might have different parsed representations. > E.g., for the first, simplifying heavily, may look something > like this: > > ┌──────┐ > │ expr │ > └──────┘ > ╱ │ ╲ > ╱ │ ╲ > ┌─────┐ . ┌─────┐ > │term │ (+) │term │ > └─────┘ ' └─────┘ > ╱ │ ╲ │ > ╱ │ ╲ │ > ┌─────┐ . ┌─────┐ ┌─────┐ > │ident│ (*) │ident│ │ident│ > └─────┘ ' └─────┘ └─────┘ > │ │ │ > │ │ │ > .─. .─. .─. > (`a`) (`b`) (`c`) > `─' `─' `─' > > While the second might add an extra `expr` node, as in: > > ┌──────┐ > │ expr │ > └──────┘ > ╱ │ ╲ > ╱ │ ╲ > ┌──────┐ . ┌─────┐ > │ expr │ (+) │term │ > └──────┘ ' └─────┘ > │ │ > │ │ > ┌─────┐ ┌─────┐ > │term │ │ident│ > └─────┘ └─────┘ > ╱ │ ╲ │ > ╱ │ ╲ │ > ┌─────┐ . ┌─────┐ .─. > │ident│ (*) │ident│ (`c`) > └─────┘ ' └─────┘ `─' > │ │ > │ │ > .─. .─. > (`a`) (`b`) > `─' `─' > > I believe that the answer, for most compilers that parse and > then convert to an AST, the second is more likely to be created > than the first. However, given that the same AST is created > from both parse trees, this is unlikely to have an effect on the > object code ultimately output from the compiler. You're describing a 'Concrete Syntax Tree' or CST, versus AST. Although in that case, I expect to see a discrete node for bracketed expressions (ie. parenthesised), as those would also have a distinct production in any formal grammar. Personally I don't have much use for CSTs for a normal compiler, but they might be useful for source-to-source translators, or programs that do source refactoring, where you want to preserve extras such as parentheses even if they're not strictly needed. (Injecting the right parentheses for examples like `(a + b) * c' which would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to just follow the original source! In any case, that still wouldnt't turn ((a+b)) back into the original; you'd need a suitable CST.)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 15:19 +0000 |
| Subject | Re: Parentheses (was: this girl calls c ugly) |
| Message-ID | <10vms98$cev$2@reader1.panix.com> |
| In reply to | #399626 |
In article <10vmmc2$2utb2$2@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 02/06/2026 14:05, Dan Cross wrote: >You're describing a 'Concrete Syntax Tree' or CST, versus AST. Yes. "Concrete Syntax Tree" is another name for "Parse Tree". >Although in that case, I expect to see a discrete node for bracketed >expressions (ie. parenthesised), as those would also have a distinct >production in any formal grammar. Was that not in the second parse tree diagram I presented? Granted, I called it "expr", but as I noted, I was simplifying heavily, mostly for space. >Personally I don't have much use for CSTs for a normal compiler, but >they might be useful for source-to-source translators, or programs that >do source refactoring, where you want to preserve extras such as >parentheses even if they're not strictly needed. I think you're missing the point, here. The question was whether, given some compiler, `a*b + c` generates different code from `(a*b) + c`, and what it means for the compiler to "remove the parentheses." I submit that, with respect to the former, the answer is "very very unlikely" and with respect to the latter, the question is a category error. >(Injecting the right parentheses for examples like `(a + b) * c' which >would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to >just follow the original source! > >In any case, that still wouldnt't turn ((a+b)) back into the original; >you'd need a suitable CST.) That's not related to what I was trying to convey. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-03 22:30 +0000 |
| Subject | Re: Parentheses |
| Message-ID | <10vq9u1$2frot$1@paganini.bofh.team> |
| In reply to | #399626 |
Bart <bc@freeuk.com> wrote:
>
> Personally I don't have much use for CSTs for a normal compiler, but
> they might be useful for source-to-source translators, or programs that
> do source refactoring, where you want to preserve extras such as
> parentheses even if they're not strictly needed.
>
> (Injecting the right parentheses for examples like `(a + b) * c' which
> would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to
> just follow the original source!
You probably mean some more complicated example. This one is
easy:
(10) -> parse("(a + b) * c")
(10) (* (+ a b) c)
(11) -> unparse(parse("(a + b) * c"))
(11) "(a+b)*c"
(12) -> parse("a + b * c")
(12) (+ a (* b c))
(13) -> unparse(parse("a + b * c"))
(13) "a+b*c"
You just need to track priorities of subexpressions to produce the
above: '+' has lower priority than '*' so subexpression needs
parentheses, '*' has higher priority, so there is no need for
parentheses.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-03 16:24 -0700 |
| Subject | Re: Parentheses |
| Message-ID | <10vqd34$1qmp$1@kst.eternal-september.org> |
| In reply to | #399665 |
antispam@fricas.org (Waldek Hebisch) writes:
> Bart <bc@freeuk.com> wrote:
>> Personally I don't have much use for CSTs for a normal compiler, but
>> they might be useful for source-to-source translators, or programs that
>> do source refactoring, where you want to preserve extras such as
>> parentheses even if they're not strictly needed.
>>
>> (Injecting the right parentheses for examples like `(a + b) * c' which
>> would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to
>> just follow the original source!
>
> You probably mean some more complicated example. This one is
> easy:
>
> (10) -> parse("(a + b) * c")
>
> (10) (* (+ a b) c)
>
> (11) -> unparse(parse("(a + b) * c"))
>
> (11) "(a+b)*c"
[snip]
What tool are you using?
[...]
--
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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-04 02:03 +0000 |
| Subject | Re: Parentheses |
| Message-ID | <10vqmeb$2lqgp$2@paganini.bofh.team> |
| In reply to | #399667 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>> Bart <bc@freeuk.com> wrote:
>>> Personally I don't have much use for CSTs for a normal compiler, but
>>> they might be useful for source-to-source translators, or programs that
>>> do source refactoring, where you want to preserve extras such as
>>> parentheses even if they're not strictly needed.
>>>
>>> (Injecting the right parentheses for examples like `(a + b) * c' which
>>> would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to
>>> just follow the original source!
>>
>> You probably mean some more complicated example. This one is
>> easy:
>>
>> (10) -> parse("(a + b) * c")
>>
>> (10) (* (+ a b) c)
>>
>> (11) -> unparse(parse("(a + b) * c"))
>>
>> (11) "(a+b)*c"
> [snip]
>
> What tool are you using?
The output if from FriCAS which is largish program which except for
containing about 50000 lines of C code have almost nothing to do with C.
'unparse' is tiny part.
Expressions have different syntax, fortunately precendence of
basic arithmetic operators is the same as in C.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-04 01:12 +0100 |
| Subject | Re: Parentheses |
| Message-ID | <10vqftg$2d72$1@dont-email.me> |
| In reply to | #399665 |
On 03/06/2026 23:30, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>>
>> Personally I don't have much use for CSTs for a normal compiler, but
>> they might be useful for source-to-source translators, or programs that
>> do source refactoring, where you want to preserve extras such as
>> parentheses even if they're not strictly needed.
>>
>> (Injecting the right parentheses for examples like `(a + b) * c' which
>> would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to
>> just follow the original source!
>
> You probably mean some more complicated example. This one is
> easy:
>
> (10) -> parse("(a + b) * c")
>
> (10) (* (+ a b) c)
>
> (11) -> unparse(parse("(a + b) * c"))
>
> (11) "(a+b)*c"
>
> (12) -> parse("a + b * c")
>
> (12) (+ a (* b c))
>
> (13) -> unparse(parse("a + b * c"))
>
> (13) "a+b*c"
>
>
> You just need to track priorities of subexpressions to produce the
> above: '+' has lower priority than '*' so subexpression needs
> parentheses, '*' has higher priority, so there is no need for
> parentheses.
I seem to remember one problem was with minus, for example original expr is:
a - (b - c)
The AST is (- a (- b c)), but a simplistic approach would generate, from
either that or (- (- a b) c), the same output:
a - b - c
No parentheses because the the two "-" have the same precedence. The
example might have been 'a + (b - c)'; same thing.
It just seemed more trouble than it was worth.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-06-04 01:58 +0000 |
| Subject | Re: Parentheses |
| Message-ID | <10vqm3g$2lqgp$1@paganini.bofh.team> |
| In reply to | #399670 |
Bart <bc@freeuk.com> wrote:
> On 03/06/2026 23:30, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>>
>>> Personally I don't have much use for CSTs for a normal compiler, but
>>> they might be useful for source-to-source translators, or programs that
>>> do source refactoring, where you want to preserve extras such as
>>> parentheses even if they're not strictly needed.
>>>
>>> (Injecting the right parentheses for examples like `(a + b) * c' which
>>> would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to
>>> just follow the original source!
>>
>> You probably mean some more complicated example. This one is
>> easy:
>>
>> (10) -> parse("(a + b) * c")
>>
>> (10) (* (+ a b) c)
>>
>> (11) -> unparse(parse("(a + b) * c"))
>>
>> (11) "(a+b)*c"
>>
>> (12) -> parse("a + b * c")
>>
>> (12) (+ a (* b c))
>>
>> (13) -> unparse(parse("a + b * c"))
>>
>> (13) "a+b*c"
>>
>>
>> You just need to track priorities of subexpressions to produce the
>> above: '+' has lower priority than '*' so subexpression needs
>> parentheses, '*' has higher priority, so there is no need for
>> parentheses.
>
> I seem to remember one problem was with minus, for example original expr is:
>
> a - (b - c)
>
> The AST is (- a (- b c)), but a simplistic approach would generate, from
> either that or (- (- a b) c), the same output:
>
> a - b - c
>
> No parentheses because the the two "-" have the same precedence. The
> example might have been 'a + (b - c)'; same thing.
>
> It just seemed more trouble than it was worth.
Well,
(7) -> parse("a - (b - c)")
(7) (- a (- b c))
(8) -> unparse(parse("a - (b - c)"))
(8) "a-(b-c)"
(9) -> parse("a - b - c")
(9) (- (- a b) c)
(10) -> unparse(parse("a - b - c"))
(10) "a-b-c"
(11) -> parse("a + (b + c)")
(11) (+ a (+ b c))
(12) -> unparse(parse("a + (b + c)"))
(12) "a+(b+c)"
(13) -> parse("a + b + c")
(13) (+ (+ a b) c)
(14) -> unparse(parse("a + b + c"))
(14) "a+b+c"
Note: the approach builds string from the parse tree so that
parsing gives back original tree. That is why (12) has
parentheses: without them parsing gives different tree.
Implementation is simple, but there are little subtleties, for
example left and right arguments do not have symmetric role
even for commutative operators.
The code is not in C, but rough translation of part of 'unparse'
handling arithmetic to C could look like:
char *
unparse(node * t) {
return sum_or_paren(t);
}
char *
sum_or_paren(node * t) {
if (is_binary(t)) {
char op = get_op(t);
node * t1 = get_left(t);
node * t2 = get_right(t);
if (op == '+') {
return concat(sum_or_paren(t1), "+", product_or_paren(t2));
}
if (op == '-') {
return concat(sum_or_paren(t1), "-", product_or_paren(t2));
return product_or_paren(t);
}
return product_or_paren(t);
}
char *
product_or_paren(node * t) {
if (is_binary(t)) {
char op = get_op(t);
node * t1 = get_left(t);
node * t2 = get_right(t);
if (op == '*') {
return concat(product_or_paren(t1), "*", app_or_paren(t2));
}
return app_or_paren(t);
}
return app_or_paren(t);
}
char *
app_or_paren(node * t) {
if (is_var(t)) {
return get_name(t);
}
....
return concat("(", sum_or_paren(t), ")");
}
I skipped handling of several other operators, from the fragment
above principle should be clear.
Note: 'node' must be type representing node of parse tree
(appropriate union of structs) and you need operations to test
for kind of node and to extract components.
Note: orignal depends on garbage collection, simple implementation
of 'concat' in C will leak memory (it needs to 'malloc' result,
but can not free arguments). That is solvable (say using Boehm
garbages collector), but solution would distract from the principle.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-04 11:37 +0100 |
| Subject | Re: Parentheses |
| Message-ID | <10vrkha$a9jd$1@dont-email.me> |
| In reply to | #399671 |
On 04/06/2026 02:58, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>> On 03/06/2026 23:30, Waldek Hebisch wrote:
>>> Bart <bc@freeuk.com> wrote:
>>>>
>>>> Personally I don't have much use for CSTs for a normal compiler, but
>>>> they might be useful for source-to-source translators, or programs that
>>>> do source refactoring, where you want to preserve extras such as
>>>> parentheses even if they're not strictly needed.
>>>>
>>>> (Injecting the right parentheses for examples like `(a + b) * c' which
>>>> would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to
>>>> just follow the original source!
>>>
>>> You probably mean some more complicated example. This one is
>>> easy:
>>>
>>> (10) -> parse("(a + b) * c")
>>>
>>> (10) (* (+ a b) c)
>>>
>>> (11) -> unparse(parse("(a + b) * c"))
>>>
>>> (11) "(a+b)*c"
>>>
>>> (12) -> parse("a + b * c")
>>>
>>> (12) (+ a (* b c))
>>>
>>> (13) -> unparse(parse("a + b * c"))
>>>
>>> (13) "a+b*c"
>>>
>>>
>>> You just need to track priorities of subexpressions to produce the
>>> above: '+' has lower priority than '*' so subexpression needs
>>> parentheses, '*' has higher priority, so there is no need for
>>> parentheses.
>>
>> I seem to remember one problem was with minus, for example original expr is:
>>
>> a - (b - c)
>>
>> The AST is (- a (- b c)), but a simplistic approach would generate, from
>> either that or (- (- a b) c), the same output:
>>
>> a - b - c
>>
>> No parentheses because the the two "-" have the same precedence. The
>> example might have been 'a + (b - c)'; same thing.
>>
>> It just seemed more trouble than it was worth.
>
> Well,
>
> (7) -> parse("a - (b - c)")
>
> (7) (- a (- b c))
>
> (8) -> unparse(parse("a - (b - c)"))
>
> (8) "a-(b-c)"
>
> (9) -> parse("a - b - c")
>
> (9) (- (- a b) c)
>
> (10) -> unparse(parse("a - b - c"))
>
> (10) "a-b-c"
>
> (11) -> parse("a + (b + c)")
>
> (11) (+ a (+ b c))
>
> (12) -> unparse(parse("a + (b + c)"))
>
> (12) "a+(b+c)"
>
> (13) -> parse("a + b + c")
>
> (13) (+ (+ a b) c)
>
> (14) -> unparse(parse("a + b + c"))
>
> (14) "a+b+c"
>
> Note: the approach builds string from the parse tree so that
> parsing gives back original tree. That is why (12) has
> parentheses: without them parsing gives different tree.
>
> Implementation is simple, but there are little subtleties, for
> example left and right arguments do not have symmetric role
> even for commutative operators.
>
> The code is not in C, but rough translation of part of 'unparse'
> handling arithmetic to C could look like:
> ...
OK, I'll have a play with it, although you could have just posted
pseudo-code.
Note that I just said it was 'surprisingly tricky'. It doesn't only
depend on precedence levels.
And it is still more elaborate than simply putting parentheses around
every binary term.
(My point had been that a CST rather then AST would make this nearly as
simple.)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-04 10:51 +0000 |
| Subject | Re: Parentheses |
| Message-ID | <10vrlbp$64e$1@reader1.panix.com> |
| In reply to | #399670 |
In article <10vqftg$2d72$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 03/06/2026 23:30, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>>
>>> Personally I don't have much use for CSTs for a normal compiler, but
>>> they might be useful for source-to-source translators, or programs that
>>> do source refactoring, where you want to preserve extras such as
>>> parentheses even if they're not strictly needed.
>>>
>>> (Injecting the right parentheses for examples like `(a + b) * c' which
>>> would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to
>>> just follow the original source!
>>
>> You probably mean some more complicated example. This one is
>> easy:
>>
>> (10) -> parse("(a + b) * c")
>>
>> (10) (* (+ a b) c)
>>
>> (11) -> unparse(parse("(a + b) * c"))
>>
>> (11) "(a+b)*c"
>>
>> (12) -> parse("a + b * c")
>>
>> (12) (+ a (* b c))
>>
>> (13) -> unparse(parse("a + b * c"))
>>
>> (13) "a+b*c"
>>
>>
>> You just need to track priorities of subexpressions to produce the
>> above: '+' has lower priority than '*' so subexpression needs
>> parentheses, '*' has higher priority, so there is no need for
>> parentheses.
>
>I seem to remember one problem was with minus, for example original expr is:
>
> a - (b - c)
>
>The AST is (- a (- b c)), but a simplistic approach would generate, from
>either that or (- (- a b) c), the same output:
>
> a - b - c
>
>No parentheses because the the two "-" have the same precedence. The
>example might have been 'a + (b - c)'; same thing.
>
>It just seemed more trouble than it was worth.
What? I don't understand what you're saying at all.
Subtraction is not associative, and the two expresions,
`a - b - c` and `a - (b - c)`, are not at all the same thing,
either in C or in regular arithmetic. The former is
`(a - b) - c`, and the subtraction distributes over the
parenthesized subexpression, so the latter is equivalent to
`a - b + c = (a - b) + c`.
term% cat wha.c
#include <stdio.h>
int
main(void)
{
int a = 5, b = 4, c = 3;
printf("a - b - c = %d\n", a - b - c);
printf("(a - b) - c = %d\n", (a - b) - c);
printf("a - (b - c) = %d\n", a - (b - c));
return 0;
}
term% make wha
cc -O2 -pipe -o wha wha.c
term% ./wha
a - b - c = -2
(a - b) - c = -2
a - (b - c) = 4
term%
- Dan C.
[toc] | [prev] | [next] | [standalone]
Page 10 of 18 — ← Prev page 1 … 8 9 [10] 11 12 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web