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 240 — 20 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: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
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 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 "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 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 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 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 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 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 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-05-31 13:25 -0500 |
| Message-ID | <10vhufg$1nid7$1@dont-email.me> |
| In reply to | #399546 |
On 5/31/2026 4:14 AM, David Brown wrote:
> On 30/05/2026 22:48, BGB wrote:
>> On 5/30/2026 6:52 AM, David Brown wrote:
>>> On 29/05/2026 22:16, BGB wrote:
>>>> On 5/29/2026 6:22 AM, David Brown wrote:
>>>>> On 29/05/2026 12:20, BGB wrote:
>>>>>> On 5/29/2026 2:52 AM, Janis Papanagnou wrote:
>>>>>>> On 2026-05-28 11:57, BGB wrote:
>>>>>>>> On 5/28/2026 2:18 AM, Janis Papanagnou wrote:
>>>>>>>>> On 2026-05-28 01:49, BGB wrote:
>>>>>>> [...]
>>>>>
>>>>>>>>
>>>>>>>> But, not really an "easy" way to avoid bloat, other than to
>>>>>>>> write code specifically for what cases are relevant; while also
>>>>>>>> avoiding needless duplication and copy paste (where, overuse of
>>>>>>>> copy/paste can also lead to bloat; along with turning the code
>>>>>>>> into an ugly mess).
>>>>>>>
>>>>>>> Hmm.. - as said, the during very early days there were issues; I
>>>>>>> recall on one platform duplication of template code in more that
>>>>>>> one source unit. And/or some environmental hacks (of the compiler)
>>>>>>> to deposit template code for linking. In the later days I've not
>>>>>>> seen such immature things anymore.
>>>>>>>
>>>>>>
>>>>>> Possibly, a lot could depend on how one is counting things as well.
>>>>>>
>>>>>>
>>>>>> In a lot of cases when using GCC, I end up using:
>>>>>> -ffunction-sections -fdata-sections -Wl,-gc-sections
>>>>>
>>>>> On many targets, "-fdata-sections" can lead to noticeably larger
>>>>> and slower code because it effectively eliminates section anchor
>>>>> optimisations. It does not negatively affect x86 AFAICS, because
>>>>> x86 does not use section anchors.
>>>>>
>>>>> <https://godbolt.org/z/zeoq41Y7d>
>>>>>
>>>>> With -fsection-anchors (enabled with optimisation on targets that
>>>>> support it - generally RISCy load/store architectures), program-
>>>>> lifetime variables are kept together in a lump (as though they were
>>>>> in a struct) and often addressed by a pointer to that pretend
>>>>> struct. Thus if a function accesses two variables "a" and "b",
>>>>> instead of having to load the addresses of each of "a" and "b" into
>>>>> separate registers, it loads an "anchor" into one register and
>>>>> accesses the variables with reg+offset addressing.
>>>>>
>>>>> I've seen "-fdata-sections" used regularly in embedded systems - it
>>>>> is almost always a bad idea.
>>>>>
>>>>> ("-ffunction-sections" is often very helpful to reduce code image
>>>>> size, so keep that one.)
>>>>>
>>>>
>>>> Both seem to help on x86, x86-64, and also on RISC-V, at making
>>>> GCC's output at least sorta space-comparable to my own compilers.
>>>>
>>>> The merit of "-fdata-sections" is mostly that it eliminates unused
>>>> global variables; whereas "-ffunction-sections" eliminates
>>>> unreachable functions.
>>>
>>> That is the point of them, yes. "-ffunction-sections" can be useful
>>> at removing unused code from more general code. For
>>> microcontrollers, SDK's and manufacturers' driver code will normally
>>> contain a large number of functions that can be eliminated in this
>>> way, saving a lot of code space.
>>>
>>> However, in practice, "-fdata-sections" rarely eliminates a
>>> significant amount - most programs do not have large amounts of
>>> statically-allocated data that is not used. Gcc, and I think most
>>> other compilers, put the static lifetime data for each translation
>>> unit in its own section, so if no data from a translation unit is
>>> used it will be eliminated at link time even with -fno-data-
>>> sections. And of course it makes no difference for heap data or
>>> stack data.
>>>
>>
>> The main place it makes a difference is global arrays from a
>> translation unit that is included, but for functions that are not
>> included.
>>
>> Also functions with large static arrays.
>>
>>
>> void SomeFunc()
>> {
>> static char buf[4096];
>> ...
>> }
>>
>> Where, say, eliminating SomeFunc does not necessarily eliminate buf.
>
> Yes, if you have such code but want to eliminate it, then -fdata-
> sections would definitely benefit. I have not seen such code in
> practice (at least not with very big static arrays, and that also was
> not an essential part of the program). But of course I have only seen a
> microscopic part of all C code written - if you come across this sort of
> thing, then I appreciate your point.
>
> (There are several ways to make this more "friendly" to builds that need
> to be compact, such as putting the buffer and/or SomeFunc in a separate
> file or giving it a specific section of its own.)
>
I have seen this pattern sometimes, though usually in "medium old" code,
with newer code more often assuming that the stack is really big and so
can handle putting 1MB or more in a local array. Though, this is not
great on a target which doesn't have a huge stack.
In my case, I usually had 128K as the default stack size in my project.
>>
>>
>>> In my testing, "-ffunction-sections" is absolutely worth using (on
>>> targets where code space is relevant - there's no need for PC
>>> software). On some targets, it may mean a few lost opportunities
>>> for shorter jump/call instructions between functions in the same
>>> translation unit, but the cost is rarely anything more than a
>>> slightly longer link time. But "-fdata-sections" typically gives
>>> almost no ram space savings, and makes code bigger and slower.
>>>
>>> As I noted, gcc on x86 does not support section anchors, so there is
>>> not likely to be much code cost for -ffdata-sections.
>>>
>>> Where section anchors shine - and where -fdata-sections therefore has
>>> cost - is when a function needs to access more than one piece of
>>> static lifetime data defined in the same translation unit (or another
>>> translation unit if you are using LTO). That happens a lot in
>>> embedded ARM programming at least. I don't know about RISC-V. If
>>> the target normally uses a "small data section" for ram (I know this
>>> is common on PowerPC), then there is, in effect, a program-wide
>>> section anchor already. So it is possible that it relatively few
>>> targets have section anchors - but the 32-bit ARM on gcc is a vastly
>>> popular choice in the embedded world, so it is important to
>>> understand the cost of this compiler flag for that target at least.
>>>
>>
>> It depends on the way it is built.
>>
>>
>> A lot of times though (for non-relocatable static-linked binaries) it
>> mostly tends to use AUIPC+LD or AUIPC+ST pairs to access global
>> variables. There is a Global Pointer that needs to be loaded when the
>> binary is started, unclear what it is used for exactly.
>>
>
> If you have a global pointer, then it will probably be used for
> gp+offset access to global data, eliminating the need for section anchors.
>
> I have not used RISC-V, and am not familiar with its details. I can see
> from godbolt that when -fdata-sections is in action and you are loading
> from static lifetime variables, the compiler generates instructions like
>
> lw a5, a_variable
> lw a4, b_variable
> lw a0, c_variable
>
> When you do not have "-fdata-sections", it uses anchors :
>
> lla a4, .LANCHOR0
> lw a5, 0(a4)
> lw a3, 4(a4)
> lw a0, 8(a4)
>
> From my (limited) understanding, RISC-V cannot use 32-bit absolute
> addressing. So the "lw a5, a_variable" must be a pseudo-instruction -
> using register + offset addressing. If there is a global pointer, then
> presumably that is used here. Alternatively, the pseudo instruction
> might assemble to two real instruction to support the 32-bit address. I
> know both techniques are used in some targets, but don't know about RISC-V.
>
It can use one of two strategies for these (after breaking up
pseudo-instructions):
LUI a5, HiAddr //Abs32, Low 2GB only
LW a5, LoAddr(a5)
Or:
AUIPC a5, HiAddr //PC-Rel
LW a5, LoAddr(a5)
IIRC, LLA is similar, just using an ADDI as the second instruction.
But, yeah, the latter sequence would be more efficient.
I would expect something different if building with -fPIC or -fPIE, but
this depends on if it is a version of GCC built with support for these
(if using a version of GCC built for non-hosted targets, it ignores
these). Where, one effectively needs different GCC builds for bare-metal
(like OS kernels) and for hosted Linux development, for whatever bizarre
reason...
> Certainly it would surprise me if the "lw a5, a_variable" version were
> more efficient than using anchors - otherwise why would gcc generate
> code with anchors when given a free choice? (Perhaps gcc is not well
> tuned for RISC-V code generation - I am wary of making too many
> assumptions about the processor just from some simple compiler outputs.)
>
It is not, it is a 2-op sequence usually.
Plain RISC-V has a bigger problem with 64-bit constants though,
generally needs to either load these from memory (more typical in GCC)
or build them in-place (which needs roughly 6 instructions in RISC-V).
Say (possible, but GCC doesn't do this):
LUI t0, ValHiA
LUI t1, valHiB
ADDI t0, t0, valLoA
ADDI t1, t1, valLoB
SLLI t1, t1, 32
ADD a0, t0, t1
In my case, I have extensions for RV that can turn a lot of this stuff
into single instructions (albeit with larger 8 and 12 byte encodings).
In some cases, it can save bytes, for example:
LW a1, Disp33s(a0)
As a 64-bit / 8-byte encoding, vs:
LUI t0, DispHi
ADD t0, t0, a0
LW a1, DispLo(a0)
Needing 12 bytes.
My own (more drastic) extensions can save more, by having a few Disp16
instructions, which can access 256K or 512K past GP within a single
32-bit instruction.
But, if/when any of this would end up in mainline RISC-V is uncertain.
Weirdly, there is a lot more emphasis there on big/fancy features (with
niche applicability), rather than on smaller things that can improve the
properties of the base ISA (and that could more generally benefit nearly
all code built for the ISA).
> (clang does not, apparently, support section anchors as an optimisation
> technique. Both with and without -fdata-sections, on RISC-V it first
> uses two instructions to load ".L_MergedGlobals" into a register and
> then uses that register plus offset to access data.)
>
Yeah.
As noted, BGBCC mostly use the GP register to access globals for RV
based targets; sorting them out so that the most common ones come first
and so are typically a single instruction.
This is one merit though of not using separate compilation.
However, the approach used by my compiler is much more memory intensive.
>
>>>
>>> I don't tend to think of MSVC as a highly optimising compiler - but
>>> it is not a tool I have much use for, as it does not handle the
>>> targets I need. When I have sometimes looked at the generated code
>>> on godbolt, it has not impressed me at all. So it could well fall
>>> into the "helpful when using a weaker compiler" category.
>>>
>>
>> Depends on what target I am building for:
>> Windows Native: Typically MSVC
>> WSL: Usually GCC or Clang
>> Seems to have: GCC 13.2.0; Clang 18.1.3
>> RISC-V GCC: Also 13.2.0 (also via WSL)
>> Linux: Typically GCC
>>
>> I rarely much use Cygwin anymore, as it was mostly rendered obsolete
>> by WSL (on Win10 or similar).
>> Though, Cygwin may still be relevant on Win7 or WinXP systems.
>>
>
> Cygwin has its own wide range of complications. If you want to use gcc
> targeting native Windows, msys2 and mingw-64 are probably your best bet,
> either compiled natively under msys2 or as a cross-compile from Linux.
> But don't place too much emphasis on my advice, as I very rarely compile
> C or C++ code for Windows - most of my PC target (Linux or Windows)
> coding is in Python.
>
Yes, I had used MinGW for a while, before mostly moving over to MSVC for
native Windows.
The tradeoff is mostly:
MinGW is closer to native for Windows;
Cygwin could give a closer approximation of Linux on Windows, so one can
build a lot of Linux software and use "./configure" scripts and similar.
But, as noted, Cygwin's role was mostly displaced by WSL, which
effectively runs a Linux userland on Windows.
There was WSL1, which basically mapped Linux syscalls over to the
Windows kernel, and WSL2, which runs the Linux kernel in a VM.
Though, in my case I was using WSL1 as seemingly MS had decided that my
PC can't do virtualization (and sees it as necessary for WSL2), even
despite having a CPU that can do so, and it is enabled in the BIOS.
>> For BGBCC, it can build both on native Windows and on Linux/WSL
>> (though recently noted that this build was broken, mostly by GCC and
>> Clang being more pedantic about missing prototypes, and a few
>> prototypes were being missed by my function-prototype mining tool).
>> Went and fixed this, but haven't posted this yet.
>>
>>
>> As for optimizing in MSVC, yeah, it is in the area of not terrible,
>> but not super clever either.
>>
>> If one expects the sort of high-level code-rewriting cleverness that
>> GCC or Clang often does, one will be disappointed.
>>
>> But, sometimes, the main "heavy hitter" optimizations are things like
>> constant-folding and register allocation, which it does do effectively.
>>
>> Though, both MSVC and BGBCC seem to use one sort of strategy for
>> register allocation:
>>
>>
>> Static assign things to callee-save registers and use remaining
>> registers for dynamic allocation within basic-blocks. Variables with
>> finite non-overlapping lifetimes (that do not cross basic-block
>> boundaries) may potentially share a register (this more generally
>> applies to things like temporaries).
>>
>> And, GCC and Clang use another: Assign dynamically but carry values
>> across basic-block boundaries along control-flow paths.
>>
>> Both tend to give different patterns though, and seem to favor
>> different types of code.
>>
>
> [...]
>
>>>
>>> (I could also note that I make heavy use of templates in C++ code -
>>> it often leads to smaller and faster results.)
>>>
>> Curious...
>>
>>
>> I had tended to use the "write everything one off for the task at
>> hand" approach, but this is a higher-effort approach.
>>
>
> A lot of code tends to fall into the category of shuffling data around
> or doing simple checks or conversions. It's also common to have wrapper
> functions for libraries to get something nicer, safer and more
> convenient than some API that belongs in the early 1990's. Good C++
> templates (and sometimes even good macros in C) can make the use of
> these things far nicer, and most of the code that the templates appear
> to generate inline in the caller disappears in optimisation.
>
OK.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-31 22:14 +0200 |
| Message-ID | <10vi4ro$1p77r$1@dont-email.me> |
| In reply to | #399562 |
On 31/05/2026 20:25, BGB wrote:
> On 5/31/2026 4:14 AM, David Brown wrote:
>> On 30/05/2026 22:48, BGB wrote:
>>> On 5/30/2026 6:52 AM, David Brown wrote:
>>>> On 29/05/2026 22:16, BGB wrote:
>>>>> On 5/29/2026 6:22 AM, David Brown wrote:
>>>>>> On 29/05/2026 12:20, BGB wrote:
>>>>>>> On 5/29/2026 2:52 AM, Janis Papanagnou wrote:
>>>>>>>> On 2026-05-28 11:57, BGB wrote:
>>>>>>>>> On 5/28/2026 2:18 AM, Janis Papanagnou wrote:
>>>>>>>>>> On 2026-05-28 01:49, BGB wrote:
>>>>>>>> [...]
>>> Also functions with large static arrays.
>>>
>>>
>>> void SomeFunc()
>>> {
>>> static char buf[4096];
>>> ...
>>> }
>>>
>>> Where, say, eliminating SomeFunc does not necessarily eliminate buf.
>>
>> Yes, if you have such code but want to eliminate it, then -fdata-
>> sections would definitely benefit. I have not seen such code in
>> practice (at least not with very big static arrays, and that also was
>> not an essential part of the program). But of course I have only seen
>> a microscopic part of all C code written - if you come across this
>> sort of thing, then I appreciate your point.
>>
>> (There are several ways to make this more "friendly" to builds that
>> need to be compact, such as putting the buffer and/or SomeFunc in a
>> separate file or giving it a specific section of its own.)
>>
>
> I have seen this pattern sometimes, though usually in "medium old" code,
> with newer code more often assuming that the stack is really big and so
> can handle putting 1MB or more in a local array. Though, this is not
> great on a target which doesn't have a huge stack.
>
> In my case, I usually had 128K as the default stack size in my project.
>
OK. My code typically has a stack of 1 KB or less per thread. It is
not inconceivable that I would have a static array like this, but it
would not be in code that is likely to be unused.
>>>>
>>>> Where section anchors shine - and where -fdata-sections therefore
>>>> has cost - is when a function needs to access more than one piece of
>>>> static lifetime data defined in the same translation unit (or
>>>> another translation unit if you are using LTO). That happens a lot
>>>> in embedded ARM programming at least. I don't know about RISC-V.
>>>> If the target normally uses a "small data section" for ram (I know
>>>> this is common on PowerPC), then there is, in effect, a program-wide
>>>> section anchor already. So it is possible that it relatively few
>>>> targets have section anchors - but the 32-bit ARM on gcc is a vastly
>>>> popular choice in the embedded world, so it is important to
>>>> understand the cost of this compiler flag for that target at least.
>>>>
>>>
>>> It depends on the way it is built.
>>>
>>>
>>> A lot of times though (for non-relocatable static-linked binaries) it
>>> mostly tends to use AUIPC+LD or AUIPC+ST pairs to access global
>>> variables. There is a Global Pointer that needs to be loaded when the
>>> binary is started, unclear what it is used for exactly.
>>>
>>
>> If you have a global pointer, then it will probably be used for
>> gp+offset access to global data, eliminating the need for section
>> anchors.
>>
>> I have not used RISC-V, and am not familiar with its details. I can
>> see from godbolt that when -fdata-sections is in action and you are
>> loading from static lifetime variables, the compiler generates
>> instructions like
>>
>> lw a5, a_variable
>> lw a4, b_variable
>> lw a0, c_variable
>>
>> When you do not have "-fdata-sections", it uses anchors :
>>
>> lla a4, .LANCHOR0
>> lw a5, 0(a4)
>> lw a3, 4(a4)
>> lw a0, 8(a4)
>>
>> From my (limited) understanding, RISC-V cannot use 32-bit absolute
>> addressing. So the "lw a5, a_variable" must be a pseudo-instruction -
>> using register + offset addressing. If there is a global pointer,
>> then presumably that is used here. Alternatively, the pseudo
>> instruction might assemble to two real instruction to support the 32-
>> bit address. I know both techniques are used in some targets, but
>> don't know about RISC-V.
>>
>
> It can use one of two strategies for these (after breaking up pseudo-
> instructions):
> LUI a5, HiAddr //Abs32, Low 2GB only
> LW a5, LoAddr(a5)
> Or:
> AUIPC a5, HiAddr //PC-Rel
> LW a5, LoAddr(a5)
>
> IIRC, LLA is similar, just using an ADDI as the second instruction.
> But, yeah, the latter sequence would be more efficient.
>
Thanks. That clears things up for me. And in particular, it shows that
section anchors (and therefore no "-fdata-sections") can make a
significant difference to gcc code for RISC-V.
>
> I would expect something different if building with -fPIC or -fPIE, but
> this depends on if it is a version of GCC built with support for these
> (if using a version of GCC built for non-hosted targets, it ignores
> these). Where, one effectively needs different GCC builds for bare-metal
> (like OS kernels) and for hosted Linux development, for whatever bizarre
> reason...
>
>
>> Certainly it would surprise me if the "lw a5, a_variable" version were
>> more efficient than using anchors - otherwise why would gcc generate
>> code with anchors when given a free choice? (Perhaps gcc is not well
>> tuned for RISC-V code generation - I am wary of making too many
>> assumptions about the processor just from some simple compiler outputs.)
>>
>
> It is not, it is a 2-op sequence usually.
>
> Plain RISC-V has a bigger problem with 64-bit constants though,
> generally needs to either load these from memory (more typical in GCC)
> or build them in-place (which needs roughly 6 instructions in RISC-V).
>
> Say (possible, but GCC doesn't do this):
> LUI t0, ValHiA
> LUI t1, valHiB
> ADDI t0, t0, valLoA
> ADDI t1, t1, valLoB
> SLLI t1, t1, 32
> ADD a0, t0, t1
>
>
> In my case, I have extensions for RV that can turn a lot of this stuff
> into single instructions (albeit with larger 8 and 12 byte encodings).
>
> In some cases, it can save bytes, for example:
> LW a1, Disp33s(a0)
> As a 64-bit / 8-byte encoding, vs:
> LUI t0, DispHi
> ADD t0, t0, a0
> LW a1, DispLo(a0)
> Needing 12 bytes.
>
>
> My own (more drastic) extensions can save more, by having a few Disp16
> instructions, which can access 256K or 512K past GP within a single 32-
> bit instruction.
>
>
> But, if/when any of this would end up in mainline RISC-V is uncertain.
> Weirdly, there is a lot more emphasis there on big/fancy features (with
> niche applicability), rather than on smaller things that can improve the
> properties of the base ISA (and that could more generally benefit nearly
> all code built for the ISA).
>
>
[...]
>>
>> Cygwin has its own wide range of complications. If you want to use
>> gcc targeting native Windows, msys2 and mingw-64 are probably your
>> best bet, either compiled natively under msys2 or as a cross-compile
>> from Linux. But don't place too much emphasis on my advice, as I very
>> rarely compile C or C++ code for Windows - most of my PC target (Linux
>> or Windows) coding is in Python.
>>
>
> Yes, I had used MinGW for a while, before mostly moving over to MSVC for
> native Windows.
>
> The tradeoff is mostly:
> MinGW is closer to native for Windows;
> Cygwin could give a closer approximation of Linux on Windows, so one can
> build a lot of Linux software and use "./configure" scripts and similar.
>
Note that MinGW and Mingw-w64 are very, very different. (And the
corresponding environments and utility collections, msys and msys2, are
equally different.) Mingw-w64, as I understand it, is somewhat of a
balance between old MinGW and Cygwin in being close to native for most
purposes, but providing more POSIX compliance than MinGW. It is also
much newer, much better maintained, with modern language support in its
tools (last I heard, with MinGW you did not even get C99 support in the
standard library). And of course it has 64-bit support.
You may well find WSL or MSVC to be a better choice for your
requirements, but don't mistake Mingw-w64 for MinGW.
>
> But, as noted, Cygwin's role was mostly displaced by WSL, which
> effectively runs a Linux userland on Windows.
>
>
> There was WSL1, which basically mapped Linux syscalls over to the
> Windows kernel, and WSL2, which runs the Linux kernel in a VM.
>
>
> Though, in my case I was using WSL1 as seemingly MS had decided that my
> PC can't do virtualization (and sees it as necessary for WSL2), even
> despite having a CPU that can do so, and it is enabled in the BIOS.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 15:22 +0200 |
| Message-ID | <10vc3us$3uus8$2@dont-email.me> |
| In reply to | #399489 |
On 2026-05-29 12:20, BGB wrote: > On 5/29/2026 2:52 AM, Janis Papanagnou wrote: >> On 2026-05-28 11:57, BGB wrote: >>> On 5/28/2026 2:18 AM, Janis Papanagnou wrote: >>>> On 2026-05-28 01:49, BGB wrote: >> [...] >>>> I'm a big fan of abstractions. - So many things beyond "C" are fine! >>> >>> I am not saying that abstractions are bad, but I haven't usually >>> found them to be worth the costs IME. >> >> Wow! - That's completely different from my experience and practice. >> >> It's what makes usage simple, fast, reliable. Not wasting time for >> details, or fixing technical bugs that should be prevented by the >> language. > > Possibly. > > But, it is also possible I approach programming in a different way. If you're doing your own personal stuff that doesn't surprise me. >> [...] > > Possibly, a lot could depend on how one is counting things as well. > > In a lot of cases when using GCC, I end up using: > -ffunction-sections -fdata-sections -Wl,-gc-sections Well, you mentioned gcc now repeatedly. Myself I had been using gcc mainly in private context only. Professionally we (mostly) used the tools that came with the vendors on commercial (often Unix) systems. I really cannot tell about Windows environments, Cygwin, or using (maybe older?) gcc versions for large scale software development. For newer systems and versions I'd certainly not expect problems as you seem to have encountered. > [...] >> [...] > > To be excluded from being syntactic sugar, it needs to be something that > is not generally possible to express within the base language. > > So, for example: > Things like operator overloading or classes are syntactic sugar IMO, as > what they do can be expressed in C, even if a lot less pretty (or far > from an idiomatic style). > > I would not consider exceptions or RTTI as syntactic sugar, because > these involve things that do not map to native C. > > Using longjmp, pointer-tagging, etc, could be considered as analogous, > but not functionally equivalent, to what C++ is doing in these cases. Thanks for explaining your view on "syntactic sugar". > [...] > >> We avoided macros if possible. > > They are de-facto for constants and similar, but for longer stuff is > better avoided. We've been talking about C++; for constants I regularly use constants. In "C", frankly, it appears to me less important; I used to use Cpp names for constant items or expressions, mainly because that's "how it is done in C". - OTOH, if I can give an item a type, why should I use a primitive mechanism. Because it's faster? No memory wasted? In our C++ projects we used Cpp features certainly not for constant literals. We used them for tags (prevent double inclusion of h-files), conditionals, and some such. Rarely for more tricky things involving tasks to circumvent limitations of the "C" language in cases where we wrote code that should work with both of these languages. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-30 03:49 +0000 |
| Message-ID | <10vdmoo$ji08$1@dont-email.me> |
| In reply to | #399489 |
On Fri, 29 May 2026 05:20:20 -0500, BGB wrote: > To be excluded from being syntactic sugar, it needs to be something > that is not generally possible to express within the base language. > > So, for example: Things like operator overloading or classes are > syntactic sugar IMO, as what they do can be expressed in C, even if > a lot less pretty (or far from an idiomatic style). > > I would not consider exceptions or RTTI as syntactic sugar, because > these involve things that do not map to native C. But surely *anything* that “is not generally possible to express within the base language” woud “not map to native C”.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-05-28 12:47 -0700 |
| Message-ID | <10va65d$3mfiv$1@dont-email.me> |
| In reply to | #399469 |
On 5/28/2026 12:18 AM, Janis Papanagnou wrote: > On 2026-05-28 01:49, BGB wrote: >>> [...] >> >> In general I like her videos, and she seems to know what she is >> talking about... >> >> But, I am not personally as much of a fan of C++ as she is... > > I'm a big fan of abstractions. - So many things beyond "C" are fine! > >> [...] >> >> [ Cygwin ] > > A sensible but imperfect workaround provided for an inferior platform. > >> [...] >> >> Similar reason to why one doesn't build complex patterns or do >> template- like stuff via function macros in the C preprocessor: >> One can do this... But again, bloated binaries and terrible build times. > > Code patterns that are bulky in "C" can be formulated tersely with > C++/STL (while still preserving an efficient implementation, even with > complexities guaranteed); and the framework is flexible, orthogonally > designed. Easy to reuse high-level concepts as opposed to re-implement > the same code for different types. Or weaken the code by extensive use > of casts. > All sorts of C's problems with memory can be addressed. (The > list can be continued; but I wonder why such things aren't recognized.) C's problems with memory? Don't you mean the programmers that make bugs? [...]
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 09:56 +0200 |
| Message-ID | <10vbgs9$3uus7$2@dont-email.me> |
| In reply to | #399478 |
On 2026-05-28 21:47, Chris M. Thomasson wrote: > On 5/28/2026 12:18 AM, Janis Papanagnou wrote: >> [...] > >> All sorts of C's problems with memory can be addressed. (The >> list can be continued; but I wonder why such things aren't recognized.) > > C's problems with memory? Don't you mean the programmers that make bugs? I'm not sure you're serious here or just joking. - To clarify... Yes, the programmers "implement the bugs", and the language makes it just easy and obligingly support the programmers to make such bugs. Janis
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-05-29 11:00 -0700 |
| Message-ID | <10vck7l$b0j4$1@dont-email.me> |
| In reply to | #399486 |
On 5/29/2026 12:56 AM, Janis Papanagnou wrote: > On 2026-05-28 21:47, Chris M. Thomasson wrote: >> On 5/28/2026 12:18 AM, Janis Papanagnou wrote: >>> [...] >> >>> All sorts of C's problems with memory can be addressed. (The >>> list can be continued; but I wonder why such things aren't recognized.) >> >> C's problems with memory? Don't you mean the programmers that make bugs? > > I'm not sure you're serious here or just joking. - To clarify... > > Yes, the programmers "implement the bugs", and the language makes it > just easy and obligingly support the programmers to make such bugs. Well... Actually, its not C's fault at all. We have some tools to help a programmer, but ultimately its up to them...?
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-05-28 17:12 +0200 |
| Message-ID | <10v9m0r$3hgv7$1@dont-email.me> |
| In reply to | #399461 |
BGB pisze: > On 5/27/2026 1:15 PM, fir wrote: >> fir pisze: >>> https://www.youtube.com/watch?v=I7fEsbksKRE >>> >>> as far as i understood..(becouse if someona talks english fast my >>> mind tend to skip more than half of the message) >>> >>> overally this is quite curious... >>> >>> >>> she probably read this articles etc for lisp ponys who say lisp is >>> beautifull and c is not so much... but still this is much of >>> incompetence call c ugly... >>> >> >> well i see she named bjorne stroustrup smart (well i wouldnt be so >> bold here) - and said he took UGLY c and combined it with OO so this >> make a c++ 'succesfull' language which >> takes much hate >> >> so i understand c is ugly and to blame c++ is hated... instead of >> coding in lisp... now thats where comedy possibly gets too strong :3 >> >> (now im quite convinced my comment on this is also not too strong in >> bad way of its sense but i was kinda really stunned/surprised ehen >> someona talks such things on video ) -,- > > In general I like her videos, and she seems to know what she is talking > about... > good to watch for sure, but those statements are still preposterous for me its kinda funny becouse i didnt think people who say c is ugly are real though my opinion on c++ from -10/10 or about rised recently maybe to -9/10 becouse of this so called 'references' who after thinking shoved to have some sense (thou in c++ they probably dont even know it have sense thay just add sh*t (and by chance 1 on 100 has some sense) > But, I am not personally as much of a fan of C++ as she is... >
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-05-28 14:07 -0500 |
| Message-ID | <10va3qt$3lsda$1@dont-email.me> |
| In reply to | #399473 |
On 5/28/2026 10:12 AM, fir wrote:
> BGB pisze:
>> On 5/27/2026 1:15 PM, fir wrote:
>>> fir pisze:
>>>> https://www.youtube.com/watch?v=I7fEsbksKRE
>>>>
>>>> as far as i understood..(becouse if someona talks english fast my
>>>> mind tend to skip more than half of the message)
>>>>
>>>> overally this is quite curious...
>>>>
>>>>
>>>> she probably read this articles etc for lisp ponys who say lisp is
>>>> beautifull and c is not so much... but still this is much of
>>>> incompetence call c ugly...
>>>>
>>>
>>> well i see she named bjorne stroustrup smart (well i wouldnt be so
>>> bold here) - and said he took UGLY c and combined it with OO so this
>>> make a c++ 'succesfull' language which
>>> takes much hate
>>>
>>> so i understand c is ugly and to blame c++ is hated... instead of
>>> coding in lisp... now thats where comedy possibly gets too strong :3
>>>
>>> (now im quite convinced my comment on this is also not too strong in
>>> bad way of its sense but i was kinda really stunned/surprised ehen
>>> someona talks such things on video ) -,-
>>
>> In general I like her videos, and she seems to know what she is
>> talking about...
>>
>
> good to watch for sure, but those statements are still preposterous
>
> for me its kinda funny becouse i didnt think people who say c is ugly
> are real
>
> though my opinion on c++ from -10/10 or about rised recently maybe to
> -9/10 becouse of this so called 'references' who after thinking shoved
> to have some sense (thou in c++ they probably dont even know it have
> sense thay just add sh*t (and by chance 1 on 100 has some sense)
>
I can't answer for her, but there are differences in aesthetic preferences.
Some like LISP syntax, others can't stand the excessive parenthesis.
There have been attempts to eliminate parenthesis, but then you can end
up with an indentation sensitive syntax (like Python):
defun foo (x y)
if ( > x y )
- ( * 2 x ) y
- ( * 2 y ) x
But, then you have all the hassles of white-space sensitive syntax...
Infix notation and precedence rules are pros/cons.
Many people much preferred Pascal style.
Smalltalk was once popular, and while arguably some aspects of its
syntax are "aesthetic", I personally found trying to read anything in
the language to be almost incomprehensible (so, negative points if I
can't make any sense of what is going on).
Trying to awkwardly bolt Smalltalk syntax onto C (as in Objective-C)
being horribly ugly IMO.
Early on, I had liked JS and ActionScript, as (compared with LISP and
Scheme) they scaled a lot easier to "real programming work".
But, then one faces a tension:
Light duty scripting: Favors keeping the language dynamic and minimizing
structural concerns;
Implementation work: Favors strongly going in a direction more like the
C-like languages.
So, my first major language ended up going from being a small JS clone
to something more like ActionScript3 (with a large and complex VM).
Then I rebooted it into something more Java-like (a language I called
BS2), but then:
It was no longer good at light scripting tasks;
It failed to really compete well with C in C's home turf.
BGBCC has BS2 support, but I rarely use-it, as it was often more useful
to write in C and then invoke BS2 features as C extensions when relevant.
Well, even if the syntax is ugly, and people can question why BS2
features and not C++ features.
Both C++ and BS2 had exceptions, but in both cases, enabling them has
non-zero overhead.
This mostly takes the form of:
Metadata tables to map code-locations to unwind and exception-handler
entry points;
Additional stub handlers to be generated in the code mostly to be like
"all good here, continue on your way."
Though, maybe could add a flag or something to the EH-unwind metadata to
flag that no handlers are present, so it should just skip past that step
and continue on directly. In this case, the idea is that it borrows a
trick from the Windows X64 ABI of using the function epilog to encode
information for the exception unwind via machine instructions (the EH
unwinder would effectively implement a sort of very naive machine-code
interpreter).
So, the metadata here is mostly a table of packed members to encode the
start and end RVA (within .text), where to find the epilog, and where to
find the entry-point for the unwind/catch handlers. I forget the exact
layout ATM, but do remember it originally came from the PE/COFF spec.
Did experiment with using the BS2 features in BGBCC to support an EC++
like subset, but this fell well short of being able to claim actual C++
support.
Or, Like EC++ but with interfaces and namespaces.
Didn't add the actual interface keyword though, more like:
abstract class IFoo {
public:
void method1();
void method2(int x, int y);
};
And, it understands it as an interface.
Did experiment with adding support for templates, but this is mostly
where I gave up.
Even getting to C++98 levels would be a strong uphill battle.
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.
But, yeah, some priorities I would have for such a language (as another
attempt at a C++ alternative):
Scope remains within what is reasonable for a person to implement in a
custom compiler;
Language should ideally be able to compete head on with C in C-like
use-cases (say, for example, including bare-metal programming and ROMs);
Language should ideally be able to have build times similar or better
than C for similar code complexity.
So, say, compiler should be ideally able to chew through at least 10
kLOC per second or so.
...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-05-28 23:54 +0000 |
| Message-ID | <10vakkb$3phl1$9@dont-email.me> |
| In reply to | #399477 |
On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:
> Some like LISP syntax, others can't stand the excessive parenthesis.
Worth mentioning that the whole point about Lisp syntax is to get as
close to no syntax as possible -- essentially, all the “syntax” is
down to the meaning of the first word after each opening parenthesis
(function call, macro call or “special form”). This is to achieve
homoiconicity, which is a core feature of the language.
Anybody remember PostScript? That, too, was homoiconic. And achieved
it in a similar way, with an absolutely minimalist compile-time
syntax.
Other, newer languages have found a way to implement AST-level macros
without going to that sort of extreme -- Julia and Rust, I think, can
manage it. I even did it in Python, with a little bit of fudging.
> There have been attempts to eliminate parenthesis ...
The problem for me is the “parenthesis pileup” layout that seems to be
traditional among Lisp programmers. I prefer to put parentheses that
have the interpretation of delimiting statement blocks on lines by
themselves (and sometimes other constructs as well, if they get too
long), e.g.
(defun set_auto_indent (&optional on)
"lets user change auto-indent setting."
(interactive)
(when (eq on nil)
(setq on
(y-or-n-p
(format
"Auto-indent [%s]? "
(if
(eq
(lookup-key (current-global-map) "\015")
'auto_indent
)
"y"
"n"
) ; if
)
)
) ; setq
) ; when
(cond
(on
(global-set-key "\015" 'auto_indent)
(global-set-key [?\C-\M-m] 'newline)
(message "Auto-indent on")
)
(t
(global-set-key "\015" 'newline)
(global-set-key [?\C-\M-m] 'auto_indent)
(message "Auto-indent off")
)
) ; cond
) ; set_auto_indent
> Infix notation and precedence rules are pros/cons.
Python took over most of the C operator precedence rules, with one
interesting wrinkle: they moved up the precedence of the bitwise
operators so that what has to be written like this in C:
(«val» & «mask») == «expected»
can have the parentheses omitted in Python:
«val» & «mask» == «expected»
> Smalltalk was once popular, and while arguably some aspects of its
> syntax are "aesthetic", I personally found trying to read anything
> in the language to be almost incomprehensible (so, negative points
> if I can't make any sense of what is going on).
I did have a look at it at one point. Not too hard to manage. The
hardest part was trying to find some actual explicit definition of the
whole syntax.
All in all, though, I think its approach to object-orientation is a
bit ancient, compared to, say, Python.
> Early on, I had liked JS and ActionScript, as (compared with LISP
> and Scheme) they scaled a lot easier to "real programming work".
>
> But, then one faces a tension:
> Light duty scripting: Favors keeping the language dynamic and
> minimizing structural concerns;
> Implementation work: Favors strongly going in a direction more like
> the C-like languages.
Lua sounds like it was designed for what you had in mind.
But these days, it’s just easier to use Python.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 10:02 +0200 |
| Message-ID | <10vbh6b$3uus7$3@dont-email.me> |
| In reply to | #399481 |
On 2026-05-29 01:54, Lawrence D’Oliveiro wrote: > On Thu, 28 May 2026 14:07:45 -0500, BGB wrote: > >> Infix notation and precedence rules are pros/cons. > > Python took over most of the C operator precedence rules, with one > interesting wrinkle: they moved up the precedence of the bitwise > operators so that what has to be written like this in C: > > («val» & «mask») == «expected» > > can have the parentheses omitted in Python: > > «val» & «mask» == «expected» Unsurprisingly; since exactly *that* was the obvious (and single) issue with C's precedence definitions. Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 12:19 +0100 |
| Message-ID | <10vbsn8$3vdf$1@dont-email.me> |
| In reply to | #399487 |
On 29/05/2026 09:02, Janis Papanagnou wrote:
> On 2026-05-29 01:54, Lawrence D’Oliveiro wrote:
>> On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:
>>
>>> Infix notation and precedence rules are pros/cons.
>>
>> Python took over most of the C operator precedence rules, with one
>> interesting wrinkle: they moved up the precedence of the bitwise
>> operators so that what has to be written like this in C:
>>
>> («val» & «mask») == «expected»
>>
>> can have the parentheses omitted in Python:
>>
>> «val» & «mask» == «expected»
>
> Unsurprisingly; since exactly *that* was the obvious (and single)
> issue with C's precedence definitions.
The only one?
How about:
* What is the order here: a ^ b | c
* Why do bitwise & | ^ need their own level anyway
* What is most intuitive precedence here: a << 3 + b, and what
is it in C
* Why do << >> have their own level anyway
* Why do == != have a difference precendence from < <= >= >
Further, here: 'a * b + c' the multplication is done first, but here:
a *= b += c
It is done second.
The issue I have is whether augmented assignments should return a value
at all. It's just generally too confusing especially with mixed types.
It's confusing enough with assignments returning a value:
a = b = x;
Here, assuming x has no side-effects, you might expect this to mean the
same as:
b = x;
a = x;
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.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 14:46 +0200 |
| Message-ID | <10vc1rb$3uus8$1@dont-email.me> |
| In reply to | #399490 |
On 2026-05-29 13:19, Bart wrote: > On 29/05/2026 09:02, Janis Papanagnou wrote: >> On 2026-05-29 01:54, Lawrence D’Oliveiro wrote: >>> On Thu, 28 May 2026 14:07:45 -0500, BGB wrote: >>> >>>> Infix notation and precedence rules are pros/cons. >>> >>> Python took over most of the C operator precedence rules, with one >>> interesting wrinkle: they moved up the precedence of the bitwise >>> operators so that what has to be written like this in C: >>> >>> («val» & «mask») == «expected» >>> >>> can have the parentheses omitted in Python: >>> >>> «val» & «mask» == «expected» >> >> Unsurprisingly; since exactly *that* was the obvious (and single) >> issue with C's precedence definitions. > > The only one? Yes. - That group of operators was what I noticed immediately when I've learned "C" back then reading K&R. Much later I've seen some folks also mentioning that specific disorder. Still later I've got information about a paper of some of the "C" authors admitting that mistake. (I think I've also seen comments from some regulars here that also noted that.) That all together is certainly a solid base for a sensible valuation. > How about: > [...] Your well known very specific views have never been a landmark for reconsidering my personal judgement. (And I'm positive that won't ever change; never mind!) The "confusions" you listed - not worth quoting - are your personal problem. The precedence of assignments and related operations and their evaluation order are clear, reasonable, and they can be found that way in many existing languages. (Some of your listed "problems" have been answered here already in the past - I wonder whether it's worth replying to you if you don't learn from the answers. You seem to have fun wasting everyone's time.) You can continue to assume that all those people, language designers and programmers, are wrong, and I accept your astonishment that for those folks it's not "confusing" as it is for you. Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 14:22 +0100 |
| Message-ID | <10vc3ua$5nkf$1@dont-email.me> |
| In reply to | #399492 |
On 29/05/2026 13:46, Janis Papanagnou wrote: > On 2026-05-29 13:19, Bart wrote: >> On 29/05/2026 09:02, Janis Papanagnou wrote: >>> On 2026-05-29 01:54, Lawrence D’Oliveiro wrote: >>>> On Thu, 28 May 2026 14:07:45 -0500, BGB wrote: >>>> >>>>> Infix notation and precedence rules are pros/cons. >>>> >>>> Python took over most of the C operator precedence rules, with one >>>> interesting wrinkle: they moved up the precedence of the bitwise >>>> operators so that what has to be written like this in C: >>>> >>>> («val» & «mask») == «expected» >>>> >>>> can have the parentheses omitted in Python: >>>> >>>> «val» & «mask» == «expected» >>> >>> Unsurprisingly; since exactly *that* was the obvious (and single) >>> issue with C's precedence definitions. >> >> The only one? > > Yes. - That group of operators was what I noticed immediately when > I've learned "C" back then reading K&R. Much later I've seen some > folks also mentioning that specific disorder. Still later I've got > information about a paper of some of the "C" authors admitting that > mistake. (I think I've also seen comments from some regulars here > that also noted that.) That all together is certainly a solid base > for a sensible valuation. > >> How about: >> [...] > > Your well known very specific views have never been a landmark for > reconsidering my personal judgement. (And I'm positive that won't > ever change; never mind!) > > The "confusions" you listed - not worth quoting - are your personal > problem. The precedence of assignments and related operations and > their evaluation order are clear, reasonable, and they can be found > that way in many existing languages. (Some of your listed "problems" > have been answered here already in the past - I wonder whether it's > worth replying to you if you don't learn from the answers. You seem > to have fun wasting everyone's time.) > > You can continue to assume that all those people, language designers > and programmers, are wrong, I noticed that you didn't answer my questions. Precedence is 100% for the benefit of human programmers, therefore if you have lots of obscure or unintuitive levels, they have to provide some extra value. Having too many levels, having them unintuitive, and having them differ across languages, suggests that the value either doesn't exist or is not worthwhile. So, yes, language designers can be wrong. Having lots of obscure precedence levels SOUNDS a good idea and it is VERY EASY to implement, hence it is commonly found. And newer languages are often obliged to perpetuate those decisions. You can agree or disagree with the above, but if the latter, I'd quite like to hear your arguments, and some examples that show the advantages of having ^ one level above &, or one level below, or whatever the hell it is. > and I accept your astonishment that for > those folks it's not "confusing" as it is for you. It was presumably confusing for Google when they decided to have a much reduced set for their Go language. Something you might do when you have time (as I'm busy), is to analyse the expressions in some C codebases, and isolate those where removal of parentheses that group terms, would result in exactly the same shape of expressions, and are therefore redundant. (You would have to exclude ones using macros.) It would be interesting to see if the use of those unnecessary parentheses correlated more closely with the less well known precedence levels. If so, then having those custom levels was unnecessary.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 17:15 +0200 |
| Message-ID | <10vcaho$3uus7$4@dont-email.me> |
| In reply to | #399494 |
On 2026-05-29 15:22, Bart wrote: > On 29/05/2026 13:46, Janis Papanagnou wrote: >> On 2026-05-29 13:19, Bart wrote: >>> On 29/05/2026 09:02, Janis Papanagnou wrote: >>>> On 2026-05-29 01:54, Lawrence D’Oliveiro wrote: >>>>> On Thu, 28 May 2026 14:07:45 -0500, BGB wrote: [...] >> [...] >> >> The "confusions" you listed - not worth quoting - are your personal >> problem. The precedence of assignments and related operations and >> their evaluation order are clear, reasonable, and they can be found >> that way in many existing languages. (Some of your listed "problems" >> have been answered here already in the past - I wonder whether it's >> worth replying to you if you don't learn from the answers. You seem >> to have fun wasting everyone's time.) >> >> [...] > > I noticed that you didn't answer my questions. Yes, because, as experience shows, it's obviously a waste of time! Okay, I'll bite. - I'll go waste my time again and comment on your other post where you said you are confused about these cases... Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-29 15:59 +0000 |
| Message-ID | <ZJiSR.14$_BG8.9@fx24.iad> |
| In reply to | #399496 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 2026-05-29 15:22, Bart wrote: >> On 29/05/2026 13:46, Janis Papanagnou wrote: >>> On 2026-05-29 13:19, Bart wrote: >>>> On 29/05/2026 09:02, Janis Papanagnou wrote: >>>>> On 2026-05-29 01:54, Lawrence D’Oliveiro wrote: >>>>>> On Thu, 28 May 2026 14:07:45 -0500, BGB wrote: >[...] >>> [...] >>> >>> The "confusions" you listed - not worth quoting - are your personal >>> problem. The precedence of assignments and related operations and >>> their evaluation order are clear, reasonable, and they can be found >>> that way in many existing languages. (Some of your listed "problems" >>> have been answered here already in the past - I wonder whether it's >>> worth replying to you if you don't learn from the answers. You seem >>> to have fun wasting everyone's time.) >>> >>> [...] >> >> I noticed that you didn't answer my questions. > >Yes, because, as experience shows, it's obviously a waste of time! > >Okay, I'll bite. - I'll go waste my time again and comment on your >other post where you said you are confused about these cases... Why bother? C isn't ever going to change operator precedence just to make Bart happy.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 17:12 +0100 |
| Message-ID | <10vcdsl$82tr$2@dont-email.me> |
| In reply to | #399497 |
On 29/05/2026 16:59, Scott Lurndal wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-05-29 15:22, Bart wrote: >>> On 29/05/2026 13:46, Janis Papanagnou wrote: >>>> On 2026-05-29 13:19, Bart wrote: >>>>> On 29/05/2026 09:02, Janis Papanagnou wrote: >>>>>> On 2026-05-29 01:54, Lawrence D’Oliveiro wrote: >>>>>>> On Thu, 28 May 2026 14:07:45 -0500, BGB wrote: >> [...] >>>> [...] >>>> >>>> The "confusions" you listed - not worth quoting - are your personal >>>> problem. The precedence of assignments and related operations and >>>> their evaluation order are clear, reasonable, and they can be found >>>> that way in many existing languages. (Some of your listed "problems" >>>> have been answered here already in the past - I wonder whether it's >>>> worth replying to you if you don't learn from the answers. You seem >>>> to have fun wasting everyone's time.) >>>> >>>> [...] >>> >>> I noticed that you didn't answer my questions. >> >> Yes, because, as experience shows, it's obviously a waste of time! >> >> Okay, I'll bite. - I'll go waste my time again and comment on your >> other post where you said you are confused about these cases... > > Why bother? C isn't ever going to change operator precedence > just to make Bart happy. It would make me happy just for someone to admit there are problems. JP always says they are perfect but for one little thing. What a C compiler /can/ do is to warn when an expression relies on knowing the precedence of the more obscure operators.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 18:48 +0200 |
| Message-ID | <10vcg1h$3uus8$4@dont-email.me> |
| In reply to | #399500 |
On 2026-05-29 18:12, Bart wrote: > On 29/05/2026 16:59, Scott Lurndal wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>> On 2026-05-29 15:22, Bart wrote: >>>> >>>> I noticed that you didn't answer my questions. >>> >>> Yes, because, as experience shows, it's obviously a waste of time! >>> >>> Okay, I'll bite. - I'll go waste my time again and comment on your >>> other post where you said you are confused about these cases... >> >> Why bother? C isn't ever going to change operator precedence >> just to make Bart happy. I think it's the "someone is wrong on the internet" syndrome.[*] My apologies. :-) > > It would make me happy just for someone to admit there are problems. JP > always says they are perfect but for one little thing. You said in your previous post that I would have said that they are perfect. And now you are even saying that I'd always say that. Please stop that! Just for the record... What I would say is that operator precedences are in "C" "sensibly and appropriately defined, modulo the bit-ops". If you want to cite me in future please quote this statement and not anything else. Janis [*] https://xkcd.com/386/
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 19:09 +0100 |
| Message-ID | <10vckpc$aquo$2@dont-email.me> |
| In reply to | #399502 |
On 29/05/2026 17:48, Janis Papanagnou wrote: > On 2026-05-29 18:12, Bart wrote: >> On 29/05/2026 16:59, Scott Lurndal wrote: >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>>> On 2026-05-29 15:22, Bart wrote: >>>>> >>>>> I noticed that you didn't answer my questions. >>>> >>>> Yes, because, as experience shows, it's obviously a waste of time! >>>> >>>> Okay, I'll bite. - I'll go waste my time again and comment on your >>>> other post where you said you are confused about these cases... >>> >>> Why bother? C isn't ever going to change operator precedence >>> just to make Bart happy. > > I think it's the "someone is wrong on the internet" syndrome.[*] > My apologies. :-) > >> >> It would make me happy just for someone to admit there are problems. >> JP always says they are perfect but for one little thing. > > You said in your previous post that I would have said that they > are perfect. And now you are even saying that I'd always say that. > > Please stop that! > > Just for the record... > > What I would say is that operator precedences are in "C" > "sensibly and appropriately defined, modulo the bit-ops". You actually said this: > (The point is that - with the exception of & ^ | - the ranking > makes perfectly sense and should be easily usable without doubt > by a concept-knowing programmer." (14-May-2026 0159 BST.) And today: > Unsurprisingly; since exactly *that* was the obvious (and single) > issue with C's precedence definitions. So you do seem to have a consistent view that there is only one thing wrong with C operator precedence. However, in that same 14-May post was this exchange: Dan Cross: >> Programmers _should_ absolutely learn the rules. But in C, >> there are many of them, and some of them are deceptively subtle. JP: > We agreed. So, a hint of something else that is amiss? You just seem reluctant to say it yourself, but will disagree with me when I suggest it, while at the same time agree when somebody else does so.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 22:00 +0200 |
| Message-ID | <10vcr8v$3uus8$5@dont-email.me> |
| In reply to | #399506 |
On 2026-05-29 20:09, Bart wrote: > You actually said this: You continue your trollish stance to cherry-pick words without understanding or trying to understand what's been expressed. The insight appears to me that you're taking communication in a similar way as you "design" your languages; focusing on personal *syntax* preferences instead of the more important *semantics*. Despite we're talking in your native language (and not mine) you obvious completely miss or deliberately ignore that there's a difference between "it makes perfectly sense" and "it's perfect". (I said the former, you put the latter in my mouth. And to not get identified as a liar you're squirming with such moves. Gee!) Or are again just confused about the difference, and despite you have already been advised to quote what I think can neither be misrepresented nor misinterpreted (since it doesn't contain common word patterns that obviously confuse you) >> What I would say is that operator precedences are in "C" >> "sensibly and appropriately defined, modulo the bit-ops". you're still playing your stupid game; you ignored that. I suggest to try to map this statement to either of the above two statements, the one I said and the one you (wrongly) attributed, and see which one fits. (Hint: the former.) > [...] > > Dan Cross: > >> Programmers _should_ absolutely learn the rules. But in C, > >> there are many of them, and some of them are deceptively subtle. > > JP: > > We agreed. Bart, you are incapable of understanding semantics and associating context. Janis
[toc] | [prev] | [next] | [standalone]
Page 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web