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 301 — 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 antispam@fricas.org (Waldek Hebisch) - 2026-06-09 01:25 +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: 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: 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 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 18:10 +0200 |
| Message-ID | <10vcdpr$3uus8$3@dont-email.me> |
| In reply to | #399490 |
On 2026-05-29 13:19, Bart wrote:
> How about:
Generally; if in doubt you can always inspect the precedence
table that you find in K&R and elsewhere. Below some hints to
hopefully reduce your confusion...
>
> * What is the order here: a ^ b | c
Personally I don't think that there's a prevalent definition
how these should be ordered. - But note the history of these
operators, which was BTW why they are in "C" at the positions
that they are; their (potential) use as boolean sets.
To memorize the bit-value operations you can associate them
with the glyphs for the boolean operations; per convention
AND (&&) comes before OR (||), and insert the bitwise xor in
between. - As said; there's a rationale for the choice, and
a historic explanation (that makes sense), but you can in
case of doubt or to make things clearer also use parentheses.
>
> * Why do bitwise & | ^ need their own level anyway
For historic reasons of potential use. (As said above.)
>
> * What is most intuitive precedence here: a << 3 + b, and what
> is it in C
What it is in "C" you should look up in the precedence table.
What it is intuitively depends on what the programmer wanted to
express. As it is written a shift by a calculated expression
seems have been the intention, and that's also how "C" handles
that.
Why would one who intends to say: make space for three bits in
'a' to put there the bit-pattern stored in 'b'? If I'd wanted to
express that I'd use a binary '|', and because or the well known
precedence I'd have no parenthesis around, as in a << 3 | b .
Of course there's also the potential semantics that you have a
'b' that exceeds three bit and you want to have that added to the
shifted value of 'a'. But then I'd not use bit-value operations
to express that but the clear and more appropriate a * 8 + b .
Both semantics bit-op and int-arithmetic don't need parenthesis
in "C" because of its clear and sensible precedence.
You are mixing bit-ops and arithmetic unnecessarily, but you are
also too lazy to write parenthesis to clear up your dirty code?
>
> * Why do << >> have their own level anyway
As you have been told so many times; to not require parentheses
unnecessarily, to be able to omit them and not pollute the code
with parentheses in a language that is already full of all sorts
of { } [ ] ( ) and other punctuation characters.
>
> * Why do == != have a difference precendence from < <= >= >
I've explained that already twice in the past.
>
> Further, here: 'a * b + c' the multplication is done first, but here:
>
> a *= b += c
>
> It is done second.
You understand that '=', '*=', and '*' are three different things,
don't you?
I hope you understand that '=' should have low precedence. And that
it makes sense to evaluate that from right to left. Do you follow?
"C" obviously decided to have them all, =, +=, *=, etc. in a single
group, and thus evaluated from right to left. - Easy rule, easy to
memorize. - And that is actually what you are demanding from many
other operators, to put them in a single group. - But here you are
complaining about it!
Of course the rules for those combined (sort of two-address) operators
could have been defined differently, in an own group with other rules.
(Algol 68 had done that, actually; the semantics are like "apply these
operations from left to right, indicating an incremental modification
of the underlying value.)
If "C" would have separated these operators from the assignment and
created another own group with different evaluation rules you'd also
have complained.
>
> The issue I have is whether augmented assignments should return a value
> at all. It's just generally too confusing especially with mixed types.
If you're confused about something either try to understand the rule,
or just learn it without understanding it, or look it up, a or write
your programs in a way that you understand; use parentheses, separate
complex expressions to simpler ones, etc.
> It's confusing enough with assignments returning a value:
>
> a = b = x;
If it hurts/confuses you then don't use that feature.
>
> Here, assuming x has no side-effects, you might expect this to mean the
> same as:
>
> b = x;
> a = x;
I cannot tell what your brain makes you expect one semantic or another.
The semantics are clearly defined. Your interpretation here is wrong.
All I can suggest is what I've written above already; and to spare you
a search, it was:
If you're confused about something either try to understand the rule,
or just learn it without understanding it, or look it up, a or write
your programs in a way that you understand; use parentheses, separate
complex expressions to simpler ones, etc.
>
> In fact it's more like: 'b = x; a = b;'. Example:
>
> double a;
> float b;
>
> a = b = 3.14159265358979323846;
>
> Here, 'a' will be assigned the less precise 32-bit version of the RHS.
And why are you composing such stupid examples (if not only for sake
of an argument)? - An experienced programmer wouldn't write such an
expression with mixed types if he intends clear and non-dubious code.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 19:18 +0100 |
| Message-ID | <10vcl99$aquo$3@dont-email.me> |
| In reply to | #399499 |
On 29/05/2026 17:10, Janis Papanagnou wrote:
> On 2026-05-29 13:19, Bart wrote:
>> Further, here: 'a * b + c' the multplication is done first, but here:
>>
>> a *= b += c
>>
>> It is done second.
>
> You understand that '=', '*=', and '*' are three different things,
> don't you?
>
> I hope you understand that '=' should have low precedence. And that
> it makes sense to evaluate that from right to left. Do you follow?
>
> "C" obviously decided to have them all, =, +=, *=, etc. in a single
> group, and thus evaluated from right to left. - Easy rule, easy to
> memorize. - And that is actually what you are demanding from many
> other operators, to put them in a single group. - But here you are
> complaining about it!
>
> Of course the rules for those combined (sort of two-address) operators
> could have been defined differently, in an own group with other rules.
> (Algol 68 had done that, actually; the semantics are like "apply these
> operations from left to right, indicating an incremental modification
> of the underlying value.)
For those who don't know, the behaviour of this C code:
a += b += c += d
is very different from the equivalent Algol68:
a +:= b +:= c +:= d
This only modifies 'a'.
>> In fact it's more like: 'b = x; a = b;'. Example:
>>
>> double a;
>> float b;
>>
>> a = b = 3.14159265358979323846;
>>
>> Here, 'a' will be assigned the less precise 32-bit version of the RHS.
>
> And why are you composing such stupid examples (if not only for sake
> of an argument)? - An experienced programmer wouldn't write such an
> expression with mixed types if he intends clear and non-dubious code.
Maybe the code started off as:
a = x;
b = x;
and somebody decided to refactor it. Or it was 'a = b = x' all along but
a, b started off as the same type but then one was changed.
These things happen. When discussing language design we have to consider
what thousands or millions of programmers might think or assume.
You seem to like making it 100% about me. How about stopping making it
always so personal.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 22:17 +0200 |
| Message-ID | <10vcs9i$3uus7$6@dont-email.me> |
| In reply to | #399507 |
On 2026-05-29 20:18, Bart wrote: > On 29/05/2026 17:10, Janis Papanagnou wrote: >> On 2026-05-29 13:19, Bart wrote: > >>> Further, here: 'a * b + c' the multplication is done first, but here: >>> >>> a *= b += c >>> >>> It is done second. >> >> You understand that '=', '*=', and '*' are three different things, >> don't you? >> >> I hope you understand that '=' should have low precedence. And that >> it makes sense to evaluate that from right to left. Do you follow? >> >> "C" obviously decided to have them all, =, +=, *=, etc. in a single >> group, and thus evaluated from right to left. - Easy rule, easy to >> memorize. - And that is actually what you are demanding from many >> other operators, to put them in a single group. - But here you are >> complaining about it! >> >> Of course the rules for those combined (sort of two-address) operators >> could have been defined differently, in an own group with other rules. >> (Algol 68 had done that, actually; the semantics are like "apply these >> operations from left to right, indicating an incremental modification >> of the underlying value.) > > For those who don't know, the behaviour of this C code: Those you have read my post already know that, since that was what I explained as a possible alternative rule for these sorts of operators. (It's still quoted above.) Folks here are capable of understanding that without your echoing post. > > a += b += c += d > > is very different from the equivalent Algol68: > > a +:= b +:= c +:= d > > This only modifies 'a'. I explained already in my post that there's a difference. (Are you so proud of having understood that that you want to repeat it? - "Look Ma, no hands!") (And neither is "perfect"; both are sensible choices. - Not sure you understand that.) > [...] > > You seem to like making it 100% about me. How about stopping making it > always so personal. What you expose here (about your personality) is nothing new, and it's about your personality; you obviously aren't really interested to know or understand or learn the facts. You had asked, even insisted for answers to your samples because you obviously weren't intellectually capable of understanding the topic, and all you posted is this reply! - Pathetic! Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 21:47 +0100 |
| Message-ID | <10vcu1a$dhga$1@dont-email.me> |
| In reply to | #399515 |
On 29/05/2026 21:17, Janis Papanagnou wrote: > On 2026-05-29 20:18, Bart wrote: > (Are you > so proud of having understood that that you want to repeat it? - > "Look Ma, no hands!") > What you expose here (about your personality) is nothing new, and > it's about your personality; you obviously aren't really interested > to know or understand or learn the facts. > you obviously weren't intellectually capable of understanding the > topic, and all you posted is this reply! > - Pathetic! It doesn't look like a civil discussion is possible here, so long as you keep up the personal insults. I thank you for those replies but there doesn't seem any point in taking this further.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-29 15:57 -0400 |
| Message-ID | <10vcr2j$cnak$1@dont-email.me> |
| In reply to | #399499 |
On 2026-05-29 12:10, Janis Papanagnou wrote: > On 2026-05-29 13:19, Bart wrote: ... >> * What is the order here: a ^ b | c (a^b)|c > Personally I don't think that there's a prevalent definition > how these should be ordered. I'm not sure what you mean by "prevalent definition". Ordinarily, I'd expect the C standard to qualify - it definitely defines the order, and the very purpose of a language standard is to prevail over non-standard alternatives. However, I'm sure you're aware of the C standard, and made that comment anyway, so I presume you mean something different by it.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 22:34 +0200 |
| Message-ID | <10vct80$3uus8$7@dont-email.me> |
| In reply to | #399511 |
On 2026-05-29 21:57, James Kuyper wrote:
> On 2026-05-29 12:10, Janis Papanagnou wrote:
>> On 2026-05-29 13:19, Bart wrote:
> ...
>>> * What is the order here: a ^ b | c
>
> (a^b)|c
>
>> Personally I don't think that there's a prevalent definition
>> how these should be ordered.
>
> I'm not sure what you mean by "prevalent definition". Ordinarily, I'd
> expect the C standard to qualify - it definitely defines the order, and
> the very purpose of a language standard is to prevail over non-standard
> alternatives. However, I'm sure you're aware of the C standard, and made
> that comment anyway, so I presume you mean something different by it.
It was about Bart's confusion; he seems to be looking for something
"naturally" understandable, like the common * and / have precedence
over + and - , which is known by most non-IT people from basic math.
There is no such commonly know ("prevalent") definition for the bit
operations. So we need to look that up in appropriate documents to
get to know their evaluation order. - That was what I intended to
express.
Sorry if that was unclear, and thanks for asking to clarify that.
How "C" defines their precedence can of course be read in any book
about "C", there's not even a "C Standard" document necessary.
In addition I gave an explanation why they decided to have these
operators in three separated precedence groups, and hinted on what
was the rationale for the same order as the boolean && and || .
Janis
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-29 23:18 +0000 |
| Message-ID | <10vd6si$g0t9$1@dont-email.me> |
| In reply to | #399490 |
On Fri, 29 May 2026 12:19:04 +0100, Bart wrote: > * Why do bitwise & | ^ need their own level anyway So that you can do shifting and masking with minimal parentheses. > * Why do << >> have their own level anyway So that shift expressions can use common arithmetic operators with minimal parentheses. > Further, here: 'a * b + c' the multplication is done first, but > here: > > a *= b += c > > It is done second. That kind of thing is disallowed in Python, for some reason.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-30 01:26 +0100 |
| Message-ID | <10vdas7$gtcd$1@dont-email.me> |
| In reply to | #399522 |
On 30/05/2026 00:18, Lawrence D’Oliveiro wrote: > On Fri, 29 May 2026 12:19:04 +0100, Bart wrote: > >> * Why do bitwise & | ^ need their own level anyway > > So that you can do shifting and masking with minimal parentheses. Can you give examples? Because you can do 'a << b & c' without << >> needing their own private level; it only needs to be lower than bitwise ops. For example they could have the same level as * and / as they essentially do the same thing. >> * Why do << >> have their own level anyway > > So that shift expressions can use common arithmetic operators with > minimal parentheses. Again, examples? > >> Further, here: 'a * b + c' the multplication is done first, but >> here: >> >> a *= b += c >> >> It is done second. > > That kind of thing is disallowed in Python, for some reason. I disallow it too (in my stuff). It's too confusing, no matter that is 100% unambiguous according to some arcane language rules.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-30 04:25 +0000 |
| Message-ID | <10vdorr$jvkg$1@dont-email.me> |
| In reply to | #399524 |
On Sat, 30 May 2026 01:26:47 +0100, Bart wrote:
> On 30/05/2026 00:18, Lawrence D’Oliveiro wrote:
>>
>> On Fri, 29 May 2026 12:19:04 +0100, Bart wrote:
>>
>>> * Why do bitwise & | ^ need their own level anyway
>>
>> So that you can do shifting and masking with minimal parentheses.
>
> Can you give examples?
You haven’t done much bit manipulation, have you?
Extracting RGB components from a pixel:
const unsigned int
r = pixel >> 16 & 255,
g = pixel >> 8 & 255,
b = pixel & 255;
Combining RGBA components into a pixel:
colors[i] =
channel[0] << 24
|
channel[1] << 16
|
channel[2] << 8
|
channel[3];
>>> * Why do << >> have their own level anyway
>>
>> So that shift expressions can use common arithmetic operators with
>> minimal parentheses.
>
> Again, examples?
From the same code module, putting together a subpicture image
consisting of 2 bits per pixel:
pixbuf[bufpixels / 4] |= histogram[histindex].index << bufpixels % 4 * 2;
<https://bitbucket.org/ldo17/dvd_menu_animator/src/master/spuhelper.c>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-30 12:01 +0100 |
| Message-ID | <10veg28$ps93$1@dont-email.me> |
| In reply to | #399529 |
On 30/05/2026 05:25, Lawrence D’Oliveiro wrote:
> On Sat, 30 May 2026 01:26:47 +0100, Bart wrote:
>
>> On 30/05/2026 00:18, Lawrence D’Oliveiro wrote:
>>>
>>> On Fri, 29 May 2026 12:19:04 +0100, Bart wrote:
>>>
>>>> * Why do bitwise & | ^ need their own level anyway
>>>
>>> So that you can do shifting and masking with minimal parentheses.
>>
>> Can you give examples?
>
> You haven’t done much bit manipulation, have you?
>
> Extracting RGB components from a pixel:
>
> const unsigned int
> r = pixel >> 16 & 255,
> g = pixel >> 8 & 255,
> b = pixel & 255;
This merely requires <<'s precendence to be lower than &.
It doesn't need & | ^ to be distinct (only one is used here anyway).
It doesn't beed << >> to be in a distinct group from multiply or add groups.
> Combining RGBA components into a pixel:
>
> colors[i] =
> channel[0] << 24
> |
> channel[1] << 16
> |
> channel[2] << 8
> |
> channel[3];
Exactly the same applies here. But if one of those | was & or ^, then
you might start needing parentheses.
>>>> * Why do << >> have their own level anyway
>>>
>>> So that shift expressions can use common arithmetic operators with
>>> minimal parentheses.
>>
>> Again, examples?
>
> From the same code module, putting together a subpicture image
> consisting of 2 bits per pixel:
>
pixbuf[bufpixels / 4] |= histogram[histindex].index << bufpixels
% 4 * 2;
This is a better example, as is this from your link:
pixbuf[nr_buf_pixels] = colors[srcpix >> src_pix_index * 2 & 3];
This can indeed be written with fewer parentheses given the priority of
<< relative to * and &.
But it is also not clear because the part after >> is sprawling. You'd
want it like this:
pixbuf[nr_buf_pixels] = colors[srcpix >> (src_pix_index * 2) & 3];
Now there is less analysis to do to establish the span of the shift-count.
These are examples from MZLIB:
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b >> 4)];
C's precedence rules say that many of those parentheses are not strictly
needed, which means the following are exactly equivalent:
crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b >> 4];
So why were they added? Could it be that they make things clearer?
Remove ambiguity in the mind of the reader? Leader to fewer surprises
when a new term needs to be added?
With the original, NOBODY NEEDS TO CARE what the hell the precedences of
>> ^ & with respect to each other. Port the fragment to a language with
slightly different rules and it it would still work.
Post that fragment somewhere, and people will know what it means
*without needing to know which exact language it is*.
This is why I think it is pointless to devote 4 dedicated levels to <<
>> & | ^, and poor to rely on them for the meaning of your code.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-31 00:29 +0000 |
| Message-ID | <10vfvdj$176f7$1@dont-email.me> |
| In reply to | #399532 |
On Sat, 30 May 2026 12:01:27 +0100, Bart wrote: > It doesn't beed << >> to be in a distinct group from multiply or add > groups. > > But it is also not clear because the part after >> is sprawling. It’s a counterexample to your claim that “<< >> [don’t need] to be in a distinct group”, isn’t it? > You'd want it like this: Because they are in a distinct group, you don’t need it like this. > Remove ambiguity in the mind of the reader? Leader to fewer > surprises when a new term needs to be added? The new terms will most likely fit into the existing ones in the natural way.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-31 10:59 +0100 |
| Message-ID | <10vh0qe$1ei50$1@dont-email.me> |
| In reply to | #399542 |
On 31/05/2026 01:29, Lawrence D’Oliveiro wrote:
> On Sat, 30 May 2026 12:01:27 +0100, Bart wrote:
>
>> It doesn't beed << >> to be in a distinct group from multiply or add
>> groups.
>>
>> But it is also not clear because the part after >> is sprawling.
>
> It’s a counterexample to your claim that “<< >> [don’t need] to be in
> a distinct group”, isn’t it?
Sure, when an expression exactly suits how its current level works, such as:
a << b + c
WHEN you intend it to be 'a << (b + c)'. How about when you intend it to
be: '(a << b) + c'?
This is arguably more intuitive since << scales numbers in the same way
as '*'. As it is:
a << 3 + b means a << (3+b)
a * 3 + b means (a*3) + b
And also
a << 3 | b means (a<<3) | b
a << 3 + b means a << (3+b)
Both examples have a similar function but thanks to the odd priorities
are quite different when choosing between << and *, or | and +.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-01 00:33 +0000 |
| Message-ID | <10vijvv$1sqp1$5@dont-email.me> |
| In reply to | #399549 |
On Sun, 31 May 2026 10:59:42 +0100, Bart wrote: > How about when you intend it to be: '(a << b) + c'? I gave real-world examples of the usage that you asked for, how about you do the same?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-01 02:26 +0100 |
| Message-ID | <10vin3p$1tr7v$1@dont-email.me> |
| In reply to | #399576 |
On 01/06/2026 01:33, Lawrence D’Oliveiro wrote:
> On Sun, 31 May 2026 10:59:42 +0100, Bart wrote:
>
>> How about when you intend it to be: '(a << b) + c'?
>
> I gave real-world examples of the usage that you asked for, how about
> you do the same?
Can do, but they wouldn't be in C. The problems are when I port to C or
port from C or simply try to understand it.
Examples:
hsum := hsum << 4 - hsum + c
lxvalue := lxvalue << 8 + (pstart+i-1)^
macro makemodrm(mode, opc, rm) = mode<<6 + opc<<3 + rm
genxrm(0xD9 + mf << 1, code, a)
am.sib := scaletable[scale]<<6 + index<<3 + base
p++^ := r>>5<<5 + g>>5<<2 + b>>6
scale := (sib>>6 + 1| 1, 2, 4, 8 |0)
hdr.usedc[i+1] := t>>4 + 1
index := r<<5 + g<<2 + b
rgb := b<<16 + g<<8 + r
shortopc := ttt<<3 + rmopc
Here, '<< >>' have same precedence as '* /'.
Notice I like to use '+' rather than '|', which in my syntax is 'ior'.
But '+ -' and 'iand ior ixor' all have the same precedence so I'd never
have to worry about it anyway
In C, '+ -' and '& | ^' are on opposite sides of '<< >>'.
And yes sometime I need to use parentheses to override; it is no big deal.
Generally, C seems to need at least 20% more parentheses (as a
proportion of all tokens) than code written in my syntax despite all
these extra levels to help you write fewer.
Bear in mind that C uses {...} to enclose data where I'd need to use
(...), but those {} aren't counted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-31 13:24 +0200 |
| Message-ID | <10vh5oj$1g1ke$2@dont-email.me> |
| In reply to | #399542 |
On 31/05/2026 02:29, Lawrence D’Oliveiro wrote: > On Sat, 30 May 2026 12:01:27 +0100, Bart wrote: > >> It doesn't beed << >> to be in a distinct group from multiply or add >> groups. >> >> But it is also not clear because the part after >> is sprawling. > > It’s a counterexample to your claim that “<< >> [don’t need] to be in > a distinct group”, isn’t it? > No, it is not. If << and >> had been in the same group as multiplication and division, your code (the snippets that Bart referenced) would have had the same semantics. Other code might have different semantics, but Bart was entirely correct in this case.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-05-29 08:09 +0200 |
| Message-ID | <10vbajh$3v25m$1@raubtier-asyl.eternal-september.org> |
| In reply to | #399477 |
Am 28.05.2026 um 21:07 schrieb BGB: > Both C++ and BS2 had exceptions, but in both cases, enabling them has > non-zero overhead. Table-driven exception handling isn't very old but currently it applies for every 64 bit platform; under Windows / x86 concatenated stackframes are used. With table-driven EH the additional overhead is zero. And with the older concatenated stackframes the overhad is very low. > And, then I lose incentive as I don't really use C++, and (unlike C > land) the C++ people tend to chase after the newest features, rather > than stick to an older and more conservative subset. There's no language where the users are so detail focussed and open to new features. But this new features raise the productivity a lot and it was far beyond C even with C++98. With C you've to flip every bit ourself over and over and C++ does replace that with standard components. This has been emphasized through a lot of C++-channels on YouTube; I personally prefer the CppCon vids or the vids of Jason Turner. And there are a lot of good books like these of Rainer Grimm and Nicolai Josuttis.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-05-29 04:15 -0500 |
| Message-ID | <10vblfv$1ui7$1@dont-email.me> |
| In reply to | #399484 |
On 5/29/2026 1:09 AM, Bonita Montero wrote:
> Am 28.05.2026 um 21:07 schrieb BGB:
>
>> Both C++ and BS2 had exceptions, but in both cases, enabling them has
>> non-zero overhead.
>
> Table-driven exception handling isn't very old but currently it applies
> for every 64 bit platform; under Windows / x86 concatenated stackframes
> are used. With table-driven EH the additional overhead is zero. And with
> the older concatenated stackframes the overhad is very low.
>
IME, it is not quite zero, but it is the least-overhead option I am
aware of.
Arguably it is less overhead than doing state-capture and adding
exception-frames to a linked list, but, ...
It is also less bloated than needing to drag around DWARF debug-info.
Looks it up in my specs for the PE/COFF variant I am using for my own
target, the entry is 64 bits per entry:
32 bits: Func Base RVA
32 bits: Packed Lengths
( 7: 0): Length of prolog in instruction words;
(29: 8): Length of function in instruction words.
( 30): Selector for instruction word size (*1).
( 31): Set to indicated whether a catch handler exists.
These go into ".pdata" which is basically an array of these entries.
*1: Relevant for ISA's that can have 16 or 32 bit instruction words, but
a given function might only use 32-bit words despite 16 being available.
Say, for example, RV64GC but only using RV64G for a given function.
Set to indicate only 32-bit instructions were used.
Currently unused.
Looking at it again, I had forgot the mechanism:
The basic handler does some trickery with the saved link register and
then branches to the epilog, which then does any cleanup and returns
control back to the unwind code (the original LR is put into an area the
unwind logic can use for the next step).
If catch handlers exists, they will check the unwinding RVA against the
RVA ranges for the try blocks, and if there is a hit, it can check if
the exception object matches the class. This part is handled by code
generated by the compiler. If no hit, it goes through the epilog which
then hands it back to the unwinder.
So, minimum-case cost is:
8 bytes of ".pdata" + 4 instruction words
Or around 24 bytes.
Say, for example, one has a program with 1200 functions, and an
average-length function of 276 bytes.
This adds 19K vs 331K to ".text", expanding the overall size of ".text"
by around 6% (plus ~ 10 of ".pdata").
Granted, this is vs, say:
23K used for string literals;
144K for the initial contents of ".data";
...
It is possible some special case could be defined that changes the size
layout, say, top bits as tag:
Tag=00: Same as present
Tag=01
( 7: 0): Size of stack frame in QWORDs;
(21: 8): Length of function in instruction words.
(29:22): Length of Epilog in instruction words
(31:30): Tag (01)
Tag=10: Reserved
Tag=11
( 7: 0): Length of prolog in instruction words;
(29: 8): Length of function in instruction words.
(31:30): Tag (11)
with the 01 case able to trim off a few instructions.
Note that a lot of this stuff uses RVAs, where locations within the
larger VAS are expressed as 32-bit offsets relative to the base address
of the PE/COFF image. Some metadata structures effectively hold
Self-RVA's as a trick to allow finding the image base address for other
RVAs (rather than using full 64-bit pointers; also RVAs don't need
base-relocs).
Well, contrast ELF64 which uses 64-bit values for everything and
needlessly so bloats the metadata.
Can't really go much smaller than RVAs though.
Well, except base relocs, which typically use a 16-bit format.
(11: 0): Base offset of relocated field within current 4K page
(15:12): Type of Base-Reloc to apply
Traditional PE/COFF base relocs had 8B per page:
Page RVA, Count
I was able to get rid of this cost though, and instead switched to
mostly using an all-16-bit format; Where Reloc Type 0 is used to encode
a page-advance and similar. This could also save a bit of space for
".reloc" by blobbing all of the relocs together per-section rather than
per-page.
>> And, then I lose incentive as I don't really use C++, and (unlike C
>> land) the C++ people tend to chase after the newest features, rather
>> than stick to an older and more conservative subset.
>
> There's no language where the users are so detail focussed and open
> to new features. But this new features raise the productivity a lot
> and it was far beyond C even with C++98. With C you've to flip every
> bit ourself over and over and C++ does replace that with standard
> components.
> This has been emphasized through a lot of C++-channels on YouTube;
> I personally prefer the CppCon vids or the vids of Jason Turner.
> And there are a lot of good books like these of Rainer Grimm and
> Nicolai Josuttis.
The issue is not whether they save effort, but rather the how they can
effect build times and binary sizes.
Like, if one doesn't care that the compiler takes a long time to run and
the EXE is needlessly large, maybe OK, not great if one does care...
Having to spend minutes or more waiting for the compiler would seriously
hurt momentum for many tasks.
Well, and I have not seen much evidence that moderate-sized C++
codebases (using modern features) can have sub-minute build times.
In some cases, one might be looking at things to try to trim to keep
sizes modest.
Say, for example, if the Boot ROM requires keeping everything under 32K.
Or they ideally don't want the OS kernel going over 500K.
Like, code footprint doesn't always matter, but is not always free.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-05-29 14:58 +0200 |
| Message-ID | <10vc2ho$5hhm$1@raubtier-asyl.eternal-september.org> |
| In reply to | #399488 |
Am 29.05.2026 um 11:15 schrieb BGB: > Like, if one doesn't care that the compiler takes a long time to run > and the EXE is needlessly large, maybe OK, not great if one does care... Binary size doesn't matter with Windows. > Having to spend minutes or more waiting for the compiler would seriously > hurt momentum for many tasks. Use C++20 modules and parallel builds. > Say, for example, if the Boot ROM requires keeping everything under 32K. C++ was designed for large scale program development. With 32K-systems you can stick with C.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-05-30 01:04 -0500 |
| Message-ID | <10vdul4$l4rm$1@dont-email.me> |
| In reply to | #399493 |
On 5/29/2026 7:58 AM, Bonita Montero wrote:
> Am 29.05.2026 um 11:15 schrieb BGB:
>
>> Like, if one doesn't care that the compiler takes a long time to run
>> and the EXE is needlessly large, maybe OK, not great if one does care...
>
> Binary size doesn't matter with Windows.
>
On a typical modern desktop PC...
Does still get annoying if it is needlessly large for no good reason.
Even if, yeah, modern PC will not care much about loading a 50 or 100MB
EXE file...
>> Having to spend minutes or more waiting for the compiler would
>> seriously hurt momentum for many tasks.
>
> Use C++20 modules and parallel builds.
>
Possibly, I have my reasons, and not all of my current development is
limited to PC class systems.
>> Say, for example, if the Boot ROM requires keeping everything under 32K.
>
> C++ was designed for large scale program development.
> With 32K-systems you can stick with C.
>
There are intermediate options, where ones' RAM is measured in MB.
Or, basically, say imagine writing software on something where CPU
speeds and RAM sizes are basically similar to what things were like in
the 1990s.
Comparably, a desktop PC is much faster, and with almost limitless RAM.
Well, and one thing I am often messing with:
Well, I am using a PE/COFF variant...
But, the OS is not on Windows, and the ISA is not x86 based, ...
Still has EXE's and DLL's though.
Can't use C++ there, because no (native) C++ compiler exists.
Well, except if using GCC to generate RV64G; can run RV64G on it;
But, RV64G's performance is lacking, and the ELF files are bloated.
Kinda sucks when a significant part of the binary is just metadata.
Then again, the PE variant is non-standard:
No MZ stub;
LZ4 compression;
Mostly using 64-byte section alignment;
And a FileOffset==RVA constraint, ...
Various structures have been tweaked;
...
Well, and the format is itself an offshoot of a WinCE variant of the
format rather than from mainline Windows. Well, imagine an OS that sort
of took design inspiration both from WinCE and the Unix family OS's.
And ended up with a CLI experience kinda similar to Cygwin. And a very
crap attempt at making a GUI (that mostly just launches with a terminal
window that can be used to start other programs).
Well, a basic view of my crappy GUI can be seen here:
https://www.youtube.com/watch?v=HAyMDRzxYzY
Though, the point of this video was more Doom but with the musical notes
replaced with DTMF-like tones (but still having octaves and similar so
it at least sorta sounds like music). As sort of a bit of hackery with
the MIDI playback code (tweaking out the FM synthesis to to play DTMF
tones rather than the normal FM instruments).
Well, that and another recent-ish video of Doom modified to sorta
resemble the monochrome style of "Return of the Obra Dinn" (well, and
also this Doom port also has a 3D glasses mod, and 3D+Obra which
actually works pretty OK, ...).
...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-29 23:20 +0000 |
| Message-ID | <10vd70h$g0t9$2@dont-email.me> |
| In reply to | #399484 |
On Fri, 29 May 2026 08:09:53 +0200, Bonita Montero wrote: > There's no language where the users are so detail focussed and open > to new features [than C++]. But they still don’t have “try-finally”.
[toc] | [prev] | [next] | [standalone]
Page 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web