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 448 — 24 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:37 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 16:31 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 13:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 23:49 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:04 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:10 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:50 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:20 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 12:39 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 23:15 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 18:51 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 09:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:07 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-09 01:25 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-09 18:29 -0400
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:01 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:36 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 16:49 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 15:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 18:08 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-11 16:30 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:52 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-12 02:20 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 14:57 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 15:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:40 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:50 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:26 -0700
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-22 03:56 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 06:27 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 15:47 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 16:36 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:43 -0700
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-06 17:41 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 10:41 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 10:49 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 16:15 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-06 18:06 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-07 22:34 -0700
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-08 23:05 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-09 10:19 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:12 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 14:37 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 18:30 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:55 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:32 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:47 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 08:56 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:38 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-11 14:05 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 15:38 -0700
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:07 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:43 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:02 +0000
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:34 +0200
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 10:58 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 12:27 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 12:36 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:03 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:35 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:02 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 12:13 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-13 12:44 +0000
Re: Constants and undefined behavior ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-14 17:22 +0000
Re: Constants and undefined behavior scott@slp53.sl.home (Scott Lurndal) - 2026-06-14 21:24 +0000
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 17:52 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-13 18:32 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-14 14:33 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-14 22:02 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-14 15:55 -0700
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 10:09 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 10:43 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-15 16:01 +0200
Re: Constants and undefined behavior antispam@fricas.org (Waldek Hebisch) - 2026-06-15 17:57 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-16 10:10 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 17:45 +0200
Re: Constants and undefined behavior "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 12:27 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-24 16:58 +0200
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-15 19:26 +0000
Re: Constants and undefined behavior James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-15 21:59 -0400
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-16 04:59 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-29 05:41 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-29 15:23 +0000
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:27 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 13:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 02:08 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:02 +0200
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 17:45 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-10 15:11 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 22:44 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:19 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:50 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 16:28 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 23:46 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 18:29 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-12 01:54 +0000
Re: Constants and undefined behavior David Brown <david.brown@hesbynett.no> - 2026-06-12 11:37 +0200
Re: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 07:58 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:28 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly 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
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 14:05 -0700
Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 15:17 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 14:53 +0100
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:30 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-09 17:13 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:34 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 09:04 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-10 11:10 +0100
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:29 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 03:17 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-10 13:43 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 14:08 -0700
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-11 09:10 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:29 +0200
Re: Expression statements (was Re: Meaning of "expression") David Brown <david.brown@hesbynett.no> - 2026-06-12 12:55 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 15:01 +0200
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 20:12 +0200
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 15:13 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 00:37 +0200
Re: Expression statements (was Re: Meaning of "expression") scott@slp53.sl.home (Scott Lurndal) - 2026-06-11 23:05 +0000
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 01:18 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 17:41 -0700
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 02:49 +0200
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-27 21:00 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:52 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:28 -0700
Re: Expression statements (was Re: Meaning of "expression") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:40 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:13 -0700
Re: Expression statements (was Re: Meaning of "expression") James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-11 20:41 -0400
Re: Expression statements (was Re: Meaning of "expression") Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 03:16 +0200
Re: Expression statements (was Re: Meaning of "expression") tTh <tth@none.invalid> - 2026-06-09 19:27 +0200
Re: Expression statements (was Re: Meaning of "expression") Bart <bc@freeuk.com> - 2026-06-09 19:19 +0100
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 15:22 -0700
Re: Meaning of "expression" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 00:42 -0700
The meaning of 42 ; (was: Re: Meaning of "expression") Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 19:42 +0800
Re: Meaning of "expression" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 05:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:22 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:56 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-07 13:37 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-07 15:09 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 02:33 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 09:37 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 17:29 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:30 +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 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:31 +0000
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 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 08:32 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-12 11:05 -0700
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: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-21 14:13 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 08:58 +0200
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 03:35 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:50 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) David Brown <david.brown@hesbynett.no> - 2026-06-22 12:59 +0200
Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 09:42 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:06 -0700
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 20:20 -0700
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:56 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 22:30 +0000
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:10 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 15:20 +0000
Re: Storage needed when there are bit-field members Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 14:19 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-22 10:45 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:23 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 13:23 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:32 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 15:04 +0000
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-22 13:02 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-14 12:51 -0700
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 05:02 +0800
Re: Microcontroller software stacks bart <bc@freeuk.com> - 2026-08-15 01:18 +0100
Re: Microcontroller software stacks Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-16 13:52 +0800
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-14 14:06 -0700
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-14 21:42 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 22:13 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-15 19:39 +0000
Re: Microcontroller software stacks Michael S <already5chosen@yahoo.com> - 2026-08-15 23:22 +0300
Re: Microcontroller software stacks scott@slp53.sl.home (Scott Lurndal) - 2026-08-16 14:38 +0000
Re: Microcontroller software stacks Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-16 16:11 -0700
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 16:16 -0700
Re: Microcontroller software stacks cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:34 +0000
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
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 20 of 23 — ← Prev page 1 … 18 19 [20] 21 22 23 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-01 18:48 +0000 |
| Message-ID | <10vkk65$l8v$1@reader1.panix.com> |
| In reply to | #399591 |
In article <10vjsg2$259m3$3@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 01/06/2026 13:04, Dan Cross wrote:
>> In article <10vjdn8$22tgu$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 31/05/2026 19:11, Bart wrote:
>>>> [snip]
>>>> Actual examples of too many parentheses?
>>>
>>> Any source code written in LISP :-)
>>
>> Hey now. Some of us have programmed in Lisp professionally, and
>> rather enjoy it.
>>
>> Lisp is often maligned for its parentheses; I don't think that's
>> fair. They really aren't that onorus once you start working in
>> it, and they're unambiguous; one may of the structure of Lisp
>> code as a shorthand notation for the resulting program's AST.
>
>I did include a smiley - I know there are people here who enjoy working
>with LISP, and have probably heard a few too many jokes about parentheses!
It's fine; many variants of Lisp are deserving of criticism, and
that community has a tendency to get too touchy about defending
the language's honor. People like Stallman are fond of calling
Lisp "the most powerful language" but I think that's nonsense.
A problem with many Lisp variants is that they're dynamically
typed; I once had to fix a production outage that happened with
a programmer converted a pair of integers into a triple. The
pair had been represented using a single `CONS` cell, but when
it became apparent that a triple was needed, it was changed into
a proper list. The operation for retrieving the first half of a
`CONS` cell is `CAR`; the operation for retrieving the second
half is `CDR`. Lisp hackers usually refer to the two halves as
"the CAR" and "the CDR" of the cell.
If a `CONS` cell just holds a pair of scalar values, as in this
example, these functions give back those scalars. However,
lists are built from `CONS` cells, where the CAR of the list is
the first element, and the CDR is the tail of the list, which is
itself a list.
Anyway, to access the values from the pair, the programmer used
`CAR` and `CDR`, but when the pair was converted to a list, this
was no longer correct; the first element was still accessible as
the CAR, but the CDR was now a list; to get the second element
of the list one would use `CADR` (or the better named `SECOND`).
Unfortunately, the programmer missed one place, and passed the
CDR of the list to a function that expected a `FIXNUM` and tried
to do arithmetic on it. Lisp is usually strongly typed, so you
can't just add a list to a number; that raises a "condition"
(which is like an exception, though that you can often restart
the thing that raised the condition). In this program, that
resulted in an ISE and an error returned to the user.
The fix was trivial, but it struck me at the time that in a
statically typed language it would have been a compile time
error.
>>> (And for too few parentheses, any source code in Forth.)
>>
>> No comment.
>>
>>> From a quick grep of an SDK in a project I am working on, I saw this
>>> example :
>>>
>>> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U))
>>>
>>> The number of parentheses there is so high it's hard to see that not
>>> only is there an unnecessary extra parentheses for the first ||
>>> operator, but there is a second set of extra parentheses around it.
>>> Eliminating these would give :
>>>
>>> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U))
>>>
>>> or, with an extra space for clarity,
>>>
>>> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) )
>>>
>>> That still leaves extra parentheses around the equality operators, but
>>> the decision to keep or remove them is subjective (as is the choice of
>>> "pData1 == NULL" vs. "!pData1").
>>>
>>> But IMHO, the original line had at least two sets of completely
>>> redundant and unhelpful parentheses which made it harder to read - the
>>> reader is left wondering whether these parentheses are there for a
>>> purpose and have an effect on what should have been a simple and clear
>>> expression.
>>
>> I see code like this all the time; usually it comes from
>> hardware vendors (I take it this was from a BSP or something
>> similar?). I often wonder about vendor programming standards
>> when I run across things like it.
>
>Yes, this was from a hardware vendor (who shall remain nameless to
>protect the guilty - not that I have found other vendors to be much
>better). They have a tendency to be obsessed with MISRA, with sticking
>to C90, and with filling headers with huge Doxygen templates giving no
>information and obscuring the code. (I'm fine with Doxygen comments
>that actually add useful information, but not a dozen lines repeating
>the names and types from a function signature.)
Yes. I see all of this, and it mystifies me; I have seen how
excessive abstraction can lead to opaque code, but many times
hardware people go in the opposite direction, and one hardly
ever sees useful abstraction; for example, often the same code
sequence could be trivially extracted into a function, but it is
instead repeated multiple times, inline.
>>> The SDK also contains examples of parentheses used because it mixes
>>> relatively rare operators (shifts and binary operators). Parentheses
>>> around such sub-expressions are not uncommon, and can definitely be
>>> helpful, but the quantity here makes things hard to read. Ironically,
>>> though it is a macro, there are not "safety" parentheses around the
>>> argument in the expression.
>>>
>>> And yes, these really are the names of the macro in this code.
>>>
>>> #define CONVERTARGB88882ARGB4444(Color) \
>>> ((((Color & 0xFFU) >> 4) & 0xFU) |\
>>> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\
>>> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \
>>> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12))
>>>
>>> #define CONVERTRGB5652ARGB8888(Color) \
>>> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\
>>> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\
>>> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000)
>>>
>>> It can be argued that the parentheses themselves are not the problem
>>> here - it is doing too much in one expression. Static inline functions
>>> would make things clearer, as would a separation of the steps of
>>> breaking down the original colour format into parts, scaling or
>>> conversions, then building up the new colour format. Different named
>>> types for the different formats would go a long way towards usability
>>> and safety - at least using typedefs, but preferably using structs to
>>> make real different types. And surely nicer names could have been found!
>>
>> Not to mention symbolic names for the magic constants. :-/
>
>Names for magic constants can be good, but they are not always helpful -
>if the magic number is only used once, its definition is far from its
>use, and it is polluting the global name space, then it can be a lot
>better to simply use the number directly and add a comment at the point
>of use. But the shift-and-mask constants could be replaced by either a
>struct with bit-fields, or inline functions for field extractions, or at
>separate local variables for the extracted fields.
I don't mind some magic: the shift constants and the masks, for
instance, are fine. But the magic 527, 259, 23, and 33, and why
the subsequent values are shifted right by 6, could be better
explained by naming those constants.
Btw, with respect to this specific algorithm, I looked them up,
and they seem to be empirically discovered lore, though derived
from a relatively standard algorithm for projection of a
discrete value into a larger space. This stack overflow page
has some details:
https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
Anyway, I don't think the constants have to be defined far away
from the code; I'd be happy with a local `const uint32_t FOO`,
though in this case it should probably just be a comment.
Here's my offering:
// Converts a 16-bit RGB16 (5-6-5) value to an ARGB32
// ("RGBA8888") value.
static inline uint32_t
rgb16_to_argb(uint16_t color)
{
const uint32_t blue5 = (color >> 0) & 0x1F;
const uint32_t green6 = (color >> 5) & 0x3F;
const uint32_t red5 = (color >> 11) & 0x1F;
// Map from a 5 or 6 bit space into an 8 bit space. A
// 5-bit number has 32 possibilities; a 6 bit number
// has 64. We can calculate the projected 8-bit
// value for a k-bit number v, we can use the formula,
// v_8 = (v*2^8-1 + (k - 1)/2)/(2^k-1), or
// (v*255 + 15)/31 (for k=5) or (v*255 + 31)/63 (for
// k=6.
//
// To remove division by a prime and turn it into a
// shift, the constants below were empirically
// discovered to generate good results. See
// https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
// for details.
const uint32_t blue = (blue5 * 527 + 23) >> 6;
const uint32_t green = (green6 * 259 + 33) >> 6;
const uint32_t red = (red5 * 527 + 23) >> 6;
const uint32_t alpha = 0xFF000000;
return blue | (green << 8) | (red << 16) | alpha;
}
It's longer, yes, but I'd argue it's much easier to understand.
On my compiler, it generates almost identical code, except that
some instructions are in a different order.
>> This is exactly the sort of thing that, as you point out, a
>> `static inline` function is far better suited for. Some code
>> bases don't want to use them for a variety of reasons, usually
>> compatibility concerns with older code, compilers, or language
>> standards. Some variants of Unix, for instance, worry about
>> header compatibility with C90 [and in some cases K&R C] code.
>
>Indeed. But even if they don't want to use "inline", a static function
>is better - the compiler will do the inlining anyway (if it makes sense
>according to its heuristics).
Assuming the compiler they're working with is known to do so,
then I agree.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-01 21:04 +0100 |
| Message-ID | <10vkojf$2et5i$1@dont-email.me> |
| In reply to | #399592 |
On 01/06/2026 19:48, Dan Cross wrote:
> In article <10vjsg2$259m3$3@dont-email.me>,
>> Names for magic constants can be good, but they are not always helpful -
>> if the magic number is only used once, its definition is far from its
>> use, and it is polluting the global name space, then it can be a lot
>> better to simply use the number directly and add a comment at the point
>> of use. But the shift-and-mask constants could be replaced by either a
>> struct with bit-fields, or inline functions for field extractions, or at
>> separate local variables for the extracted fields.
>
> I don't mind some magic: the shift constants and the masks, for
> instance, are fine. But the magic 527, 259, 23, and 33, and why
> the subsequent values are shifted right by 6, could be better
> explained by naming those constants.
>
> Btw, with respect to this specific algorithm, I looked them up,
> and they seem to be empirically discovered lore, though derived
> from a relatively standard algorithm for projection of a
> discrete value into a larger space. This stack overflow page
> has some details:
> https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
>
> Anyway, I don't think the constants have to be defined far away
> from the code; I'd be happy with a local `const uint32_t FOO`,
> though in this case it should probably just be a comment.
> Here's my offering:
>
> // Converts a 16-bit RGB16 (5-6-5) value to an ARGB32
> // ("RGBA8888") value.
> static inline uint32_t
> rgb16_to_argb(uint16_t color)
> {
> const uint32_t blue5 = (color >> 0) & 0x1F;
> const uint32_t green6 = (color >> 5) & 0x3F;
> const uint32_t red5 = (color >> 11) & 0x1F;
>
> // Map from a 5 or 6 bit space into an 8 bit space. A
> // 5-bit number has 32 possibilities; a 6 bit number
> // has 64. We can calculate the projected 8-bit
> // value for a k-bit number v, we can use the formula,
> // v_8 = (v*2^8-1 + (k - 1)/2)/(2^k-1), or
> // (v*255 + 15)/31 (for k=5) or (v*255 + 31)/63 (for
> // k=6.
> //
> // To remove division by a prime and turn it into a
> // shift, the constants below were empirically
> // discovered to generate good results. See
> // https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
> // for details.
> const uint32_t blue = (blue5 * 527 + 23) >> 6;
> const uint32_t green = (green6 * 259 + 33) >> 6;
> const uint32_t red = (red5 * 527 + 23) >> 6;
> const uint32_t alpha = 0xFF000000;
>
> return blue | (green << 8) | (red << 16) | alpha;
> }
>
> It's longer, yes, but I'd argue it's much easier to understand.
> On my compiler, it generates almost identical code, except that
> some instructions are in a different order.
The speed probably isn't that important. This can be table-driven: you
use those formulae once to populate some tables (and with the shifts
built-in). Then the routine can be simplified to this:
uint32_t rgb16_to_argb_bc(uint16_t color) {
const uint32_t blue5 = (color >> 0) & 0x1F;
const uint32_t green6 = (color >> 5) & 0x3F;
const uint32_t red5 = (color >> 11) & 0x1F;
return bluetab[blue5] | greentab[green6] | redtab[red5] |
0xFF000000;
}
On a test I did (one billion conversions cycling over 1M precalculated
random 16-bit numbers), the table version was twice as fast. Maybe a bit
faster if the Alpha value is pre-added to the red-table.
(Results were merely summed, but if writing into a new buffer, then
memory access is probably more dominant.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 09:17 +0200 |
| Message-ID | <10vm01d$2ne3j$3@dont-email.me> |
| In reply to | #399593 |
On 01/06/2026 22:04, Bart wrote:
> On 01/06/2026 19:48, Dan Cross wrote:
>> In article <10vjsg2$259m3$3@dont-email.me>,
>
>>> Names for magic constants can be good, but they are not always helpful -
>>> if the magic number is only used once, its definition is far from its
>>> use, and it is polluting the global name space, then it can be a lot
>>> better to simply use the number directly and add a comment at the point
>>> of use. But the shift-and-mask constants could be replaced by either a
>>> struct with bit-fields, or inline functions for field extractions, or at
>>> separate local variables for the extracted fields.
>>
>> I don't mind some magic: the shift constants and the masks, for
>> instance, are fine. But the magic 527, 259, 23, and 33, and why
>> the subsequent values are shifted right by 6, could be better
>> explained by naming those constants.
>>
>> Btw, with respect to this specific algorithm, I looked them up,
>> and they seem to be empirically discovered lore, though derived
>> from a relatively standard algorithm for projection of a
>> discrete value into a larger space. This stack overflow page
>> has some details:
>> https://stackoverflow.com/questions/2442576/how-does-one-convert-16-
>> bit-rgb565-to-24-bit-rgb888
>>
>> Anyway, I don't think the constants have to be defined far away
>> from the code; I'd be happy with a local `const uint32_t FOO`,
>> though in this case it should probably just be a comment.
>> Here's my offering:
>>
>> // Converts a 16-bit RGB16 (5-6-5) value to an ARGB32
>> // ("RGBA8888") value.
>> static inline uint32_t
>> rgb16_to_argb(uint16_t color)
>> {
>> const uint32_t blue5 = (color >> 0) & 0x1F;
>> const uint32_t green6 = (color >> 5) & 0x3F;
>> const uint32_t red5 = (color >> 11) & 0x1F;
>>
>> // Map from a 5 or 6 bit space into an 8 bit space. A
>> // 5-bit number has 32 possibilities; a 6 bit number
>> // has 64. We can calculate the projected 8-bit
>> // value for a k-bit number v, we can use the formula,
>> // v_8 = (v*2^8-1 + (k - 1)/2)/(2^k-1), or
>> // (v*255 + 15)/31 (for k=5) or (v*255 + 31)/63 (for
>> // k=6.
>> //
>> // To remove division by a prime and turn it into a
>> // shift, the constants below were empirically
>> // discovered to generate good results. See
>> // https://stackoverflow.com/questions/2442576/how-does-one-
>> convert-16-bit-rgb565-to-24-bit-rgb888
>> // for details.
>> const uint32_t blue = (blue5 * 527 + 23) >> 6;
>> const uint32_t green = (green6 * 259 + 33) >> 6;
>> const uint32_t red = (red5 * 527 + 23) >> 6;
>> const uint32_t alpha = 0xFF000000;
>>
>> return blue | (green << 8) | (red << 16) | alpha;
>> }
>>
>> It's longer, yes, but I'd argue it's much easier to understand.
>> On my compiler, it generates almost identical code, except that
>> some instructions are in a different order.
>
> The speed probably isn't that important. This can be table-driven: you
> use those formulae once to populate some tables (and with the shifts
> built-in). Then the routine can be simplified to this:
>
>
> uint32_t rgb16_to_argb_bc(uint16_t color) {
> const uint32_t blue5 = (color >> 0) & 0x1F;
> const uint32_t green6 = (color >> 5) & 0x3F;
> const uint32_t red5 = (color >> 11) & 0x1F;
>
> return bluetab[blue5] | greentab[green6] | redtab[red5] |
> 0xFF000000;
> }
>
> On a test I did (one billion conversions cycling over 1M precalculated
> random 16-bit numbers), the table version was twice as fast. Maybe a bit
> faster if the Alpha value is pre-added to the red-table.
>
> (Results were merely summed, but if writing into a new buffer, then
> memory access is probably more dominant.)
Such timing results are, as they stand, totally useless - the best
choice of algorithm is entirely dependent on the target device,
tradeoffs for speed and code/table space, and on how the code is used in
practice.
It is absolutely true that a table-based approach can give faster
results. (And there's no doubt that your table code here is vastly
clearer than the original macro.) On some microcontrollers, avoiding
the multiplications would give code that is an order of magnitude
faster. On others, table lookup would be a lot slower.
So it is definitely worth thinking about alternative approaches such as
this, but testing on a PC gives very little information about real-world
speed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 09:09 +0200 |
| Message-ID | <10vlvie$2ne3j$2@dont-email.me> |
| In reply to | #399592 |
On 01/06/2026 20:48, Dan Cross wrote:
> In article <10vjsg2$259m3$3@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 01/06/2026 13:04, Dan Cross wrote:
>>> In article <10vjdn8$22tgu$1@dont-email.me>,
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 31/05/2026 19:11, Bart wrote:
>>>>> [snip]
>>>>> Actual examples of too many parentheses?
>>>>
[Snipping the LISP stuff - fun, but OT and not really relevant to the
thread branch. And I have never used the language.]
>>>
>>> I see code like this all the time; usually it comes from
>>> hardware vendors (I take it this was from a BSP or something
>>> similar?). I often wonder about vendor programming standards
>>> when I run across things like it.
>>
>> Yes, this was from a hardware vendor (who shall remain nameless to
>> protect the guilty - not that I have found other vendors to be much
>> better). They have a tendency to be obsessed with MISRA, with sticking
>> to C90, and with filling headers with huge Doxygen templates giving no
>> information and obscuring the code. (I'm fine with Doxygen comments
>> that actually add useful information, but not a dozen lines repeating
>> the names and types from a function signature.)
>
> Yes. I see all of this, and it mystifies me; I have seen how
> excessive abstraction can lead to opaque code, but many times
> hardware people go in the opposite direction, and one hardly
> ever sees useful abstraction; for example, often the same code
> sequence could be trivially extracted into a function, but it is
> instead repeated multiple times, inline.
>
Indeed. There is just /so/ much that is done badly in these SDK's - I
am not going to go into details as it would take all day. I get the
impression that software libraries are very much an afterthought for
most microcontroller design groups - I don't think they ever bother
talking to developers who will use them. In fact, I don't think they
talk much to the software folks when designing the microcontrollers either.
Sometimes, however, they do have abstractions - sometimes multiple
layers of HALs ("Hardware Abstraction Layer"), drivers, interfaces, etc.
Each layer has a completely different way of viewing things - one will
use #define'd constants for everything, another will use a struct with
30 fields passed as a pointer in order to turn a GPIO pin on or off, and
the next layer will use a macro TURN_GPIO_PIN_A14_ON. When you have
figured out which API you are expected to use, toggling a GPIO leads to
a half-dozen nested calls (not including macros) up and down theses
stacks when all the hardware needs is a single write to a particular
register. And if you are really lucky, a global HAL_LOCK_MUTEX is
acquired and released along the way.
The most extreme example I saw was working on a very small 8-bit
microcontroller - 2 KB of code flash. I wanted to use the ADC, and
thought I'd save reading the datasheet and reference manual by using the
"wizard" and SDK. The result needed 4 KB of flash - twice what the chip
had - and half of its ram. I looked in the manual and got the same
results I needed with a single line of C code that compiled to just one
assembly instruction.
(Time to cut the rant short.)
>>>
>>> Not to mention symbolic names for the magic constants. :-/
>>
>> Names for magic constants can be good, but they are not always helpful -
>> if the magic number is only used once, its definition is far from its
>> use, and it is polluting the global name space, then it can be a lot
>> better to simply use the number directly and add a comment at the point
>> of use. But the shift-and-mask constants could be replaced by either a
>> struct with bit-fields, or inline functions for field extractions, or at
>> separate local variables for the extracted fields.
>
> I don't mind some magic: the shift constants and the masks, for
> instance, are fine. But the magic 527, 259, 23, and 33, and why
> the subsequent values are shifted right by 6, could be better
> explained by naming those constants.
>
Agreed - those are the "magic" ones, and need explaining (or perhaps
calculating, at compile time, from something that makes sense to the
reader and maintainer).
> Btw, with respect to this specific algorithm, I looked them up,
> and they seem to be empirically discovered lore, though derived
> from a relatively standard algorithm for projection of a
> discrete value into a larger space. This stack overflow page
> has some details:
> https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
>
A URL in comments in the code would be a lot better than just the numbers.
> Anyway, I don't think the constants have to be defined far away
> from the code; I'd be happy with a local `const uint32_t FOO`,
> though in this case it should probably just be a comment.
> Here's my offering:
>
> // Converts a 16-bit RGB16 (5-6-5) value to an ARGB32
> // ("RGBA8888") value.
> static inline uint32_t
> rgb16_to_argb(uint16_t color)
> {
> const uint32_t blue5 = (color >> 0) & 0x1F;
> const uint32_t green6 = (color >> 5) & 0x3F;
> const uint32_t red5 = (color >> 11) & 0x1F;
>
> // Map from a 5 or 6 bit space into an 8 bit space. A
> // 5-bit number has 32 possibilities; a 6 bit number
> // has 64. We can calculate the projected 8-bit
> // value for a k-bit number v, we can use the formula,
> // v_8 = (v*2^8-1 + (k - 1)/2)/(2^k-1), or
> // (v*255 + 15)/31 (for k=5) or (v*255 + 31)/63 (for
> // k=6.
> //
> // To remove division by a prime and turn it into a
> // shift, the constants below were empirically
> // discovered to generate good results. See
> // https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
> // for details.
> const uint32_t blue = (blue5 * 527 + 23) >> 6;
> const uint32_t green = (green6 * 259 + 33) >> 6;
> const uint32_t red = (red5 * 527 + 23) >> 6;
> const uint32_t alpha = 0xFF000000;
>
> return blue | (green << 8) | (red << 16) | alpha;
> }
>
> It's longer, yes, but I'd argue it's much easier to understand.
> On my compiler, it generates almost identical code, except that
> some instructions are in a different order.
Yes, that would be vastly better. (I would still prefer to have
different named types for colours in the different encoding schemes.)
>
>>> This is exactly the sort of thing that, as you point out, a
>>> `static inline` function is far better suited for. Some code
>>> bases don't want to use them for a variety of reasons, usually
>>> compatibility concerns with older code, compilers, or language
>>> standards. Some variants of Unix, for instance, worry about
>>> header compatibility with C90 [and in some cases K&R C] code.
>>
>> Indeed. But even if they don't want to use "inline", a static function
>> is better - the compiler will do the inlining anyway (if it makes sense
>> according to its heuristics).
>
> Assuming the compiler they're working with is known to do so,
> then I agree.
>
If a compiler is not capable of inlining static functions without them
being labelled "inline", then you are unlikely to get efficient results
anyway. (Or the user has not enabled optimisation, and again cannot
expect efficient results.) I don't see the point in pandering to poorly
optimising compilers (including good compilers with optimisation
disabled) in order to produce marginally less big and slow code. There
was a time when a good optimising compiler was a significant investment
and not always within the budget for a project, but such times are far
in the past. I can understand that some developers are hamstrung by
daft C90 restrictions, but I have little sympathy for people wanting
good results from poor tools.
(The exception, perhaps, is people who have to use Microchip development
tools.)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 12:07 +0000 |
| Message-ID | <10vmh2e$b44$1@reader1.panix.com> |
| In reply to | #399602 |
In article <10vlvie$2ne3j$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 01/06/2026 20:48, Dan Cross wrote:
>> In article <10vjsg2$259m3$3@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 01/06/2026 13:04, Dan Cross wrote:
>>>> In article <10vjdn8$22tgu$1@dont-email.me>,
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> On 31/05/2026 19:11, Bart wrote:
>>>>>> [snip]
>>>>>> Actual examples of too many parentheses?
>>>>>
>
>[Snipping the LISP stuff - fun, but OT and not really relevant to the
>thread branch. And I have never used the language.]
Fair!
>>>> [snip]
>>>> I see code like this all the time; usually it comes from
>>>> hardware vendors (I take it this was from a BSP or something
>>>> similar?). I often wonder about vendor programming standards
>>>> when I run across things like it.
>>>
>>> Yes, this was from a hardware vendor (who shall remain nameless to
>>> protect the guilty - not that I have found other vendors to be much
>>> better). They have a tendency to be obsessed with MISRA, with sticking
>>> to C90, and with filling headers with huge Doxygen templates giving no
>>> information and obscuring the code. (I'm fine with Doxygen comments
>>> that actually add useful information, but not a dozen lines repeating
>>> the names and types from a function signature.)
>>
>> Yes. I see all of this, and it mystifies me; I have seen how
>> excessive abstraction can lead to opaque code, but many times
>> hardware people go in the opposite direction, and one hardly
>> ever sees useful abstraction; for example, often the same code
>> sequence could be trivially extracted into a function, but it is
>> instead repeated multiple times, inline.
>
>Indeed. There is just /so/ much that is done badly in these SDK's - I
>am not going to go into details as it would take all day. I get the
>impression that software libraries are very much an afterthought for
>most microcontroller design groups - I don't think they ever bother
>talking to developers who will use them. In fact, I don't think they
>talk much to the software folks when designing the microcontrollers either.
I think that's exactly what happens: the uCtlr companies don't
have robust software development organizations, and it's seen as
a side-bag to their core business. The same is true for the
bigger hardware vendors, as well (lookin' at you, Intel). Cue
the famous story about Fred Brooks throwing Gene Amdahl out of
his office until the latter came with with a hardware design for
the IBM 360 with byte addressing and power of two widths for
primitive data types.
>Sometimes, however, they do have abstractions - sometimes multiple
>layers of HALs ("Hardware Abstraction Layer"), drivers, interfaces, etc.
> Each layer has a completely different way of viewing things - one will
>use #define'd constants for everything, another will use a struct with
>30 fields passed as a pointer in order to turn a GPIO pin on or off, and
>the next layer will use a macro TURN_GPIO_PIN_A14_ON. When you have
>figured out which API you are expected to use, toggling a GPIO leads to
>a half-dozen nested calls (not including macros) up and down theses
>stacks when all the hardware needs is a single write to a particular
>register. And if you are really lucky, a global HAL_LOCK_MUTEX is
>acquired and released along the way.
Yes. The way one boots an AMD server SoC, for instance,
requires shipping a bunch of binary data structures around to
little microcontrollers spread across a bunch of AXI buses, that
are then responsible for things like configuring PCIe links and
enumerating IO buses and so on. The vendor code for doing this
is opaque, at best. For example,
https://github.com/openSIL/openSIL/blob/turin_poc/xUSL/Nbio/Brh/NbioPcieComplexDataBrh.c
(and that's a cleaned-up version).
>[snip color mapping code]
>
>Yes, that would be vastly better. (I would still prefer to have
>different named types for colours in the different encoding schemes.)
I'll see your named types and raise you a bitfield struct. The
shifting and masking is superfluous.
>>>> This is exactly the sort of thing that, as you point out, a
>>>> `static inline` function is far better suited for. Some code
>>>> bases don't want to use them for a variety of reasons, usually
>>>> compatibility concerns with older code, compilers, or language
>>>> standards. Some variants of Unix, for instance, worry about
>>>> header compatibility with C90 [and in some cases K&R C] code.
>>>
>>> Indeed. But even if they don't want to use "inline", a static function
>>> is better - the compiler will do the inlining anyway (if it makes sense
>>> according to its heuristics).
>>
>> Assuming the compiler they're working with is known to do so,
>> then I agree.
>
>If a compiler is not capable of inlining static functions without them
>being labelled "inline", then you are unlikely to get efficient results
>anyway. (Or the user has not enabled optimisation, and again cannot
>expect efficient results.) I don't see the point in pandering to poorly
>optimising compilers (including good compilers with optimisation
>disabled) in order to produce marginally less big and slow code. There
>was a time when a good optimising compiler was a significant investment
>and not always within the budget for a project, but such times are far
>in the past. I can understand that some developers are hamstrung by
>daft C90 restrictions, but I have little sympathy for people wanting
>good results from poor tools.
>
>(The exception, perhaps, is people who have to use Microchip development
>tools.)
It's not just because the optimizer is bad or the developers are
obtuse. Sometimes it's a deliberate decision to support
external tooling, like a debugger or tracing program or similar.
Some projects deliberately tolerate slower code for that.
Moreover, on large code bases, with long life spans, upgrading a
compiler is a significant investment. Almost invariably the
code has UB somewhere (I work on a code base that has been
evolving since before ANSI C; out of about 11 million lines,
there's lots of code that can be considered "legacy" in it).
From a business standpoint, it's not worth the time or
engineering resources required to go find all of it and make it
strictly conforming; from a technical standpoint, it may not
always be possible to do so anyway (though other superset
standards, like POSIX, are another matter), and in other cases
the resulting obfuscation to meet much stricter demands of ISO C
has been deemed, rightly or wrongly, as simply not worth it. It
may not ideal, but them's the breaks.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 14:37 +0200 |
| Message-ID | <10vmipn$2ruaa$2@dont-email.me> |
| In reply to | #399616 |
On 02/06/2026 14:07, Dan Cross wrote: > In article <10vlvie$2ne3j$2@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 01/06/2026 20:48, Dan Cross wrote: >>> In article <10vjsg2$259m3$3@dont-email.me>, >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 01/06/2026 13:04, Dan Cross wrote: >>>>> In article <10vjdn8$22tgu$1@dont-email.me>, >>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>> On 31/05/2026 19:11, Bart wrote: >>>>>>> [snip] >> [snip color mapping code] >> >> Yes, that would be vastly better. (I would still prefer to have >> different named types for colours in the different encoding schemes.) > > I'll see your named types and raise you a bitfield struct. The > shifting and masking is superfluous. Sure. "Named types" does not preclude bit-fields. I'd prefer some kind of struct, for type safety, but even a typedef is better than nothing. And when you have a struct for something like this, bit-fields are an obvious choice (at least for code that doesn't have to be portable to different endian systems). > >>>>> This is exactly the sort of thing that, as you point out, a >>>>> `static inline` function is far better suited for. Some code >>>>> bases don't want to use them for a variety of reasons, usually >>>>> compatibility concerns with older code, compilers, or language >>>>> standards. Some variants of Unix, for instance, worry about >>>>> header compatibility with C90 [and in some cases K&R C] code. >>>> >>>> Indeed. But even if they don't want to use "inline", a static function >>>> is better - the compiler will do the inlining anyway (if it makes sense >>>> according to its heuristics). >>> >>> Assuming the compiler they're working with is known to do so, >>> then I agree. >> >> If a compiler is not capable of inlining static functions without them >> being labelled "inline", then you are unlikely to get efficient results >> anyway. (Or the user has not enabled optimisation, and again cannot >> expect efficient results.) I don't see the point in pandering to poorly >> optimising compilers (including good compilers with optimisation >> disabled) in order to produce marginally less big and slow code. There >> was a time when a good optimising compiler was a significant investment >> and not always within the budget for a project, but such times are far >> in the past. I can understand that some developers are hamstrung by >> daft C90 restrictions, but I have little sympathy for people wanting >> good results from poor tools. >> >> (The exception, perhaps, is people who have to use Microchip development >> tools.) > > It's not just because the optimizer is bad or the developers are > obtuse. Sometimes it's a deliberate decision to support > external tooling, like a debugger or tracing program or similar. > Some projects deliberately tolerate slower code for that. That's fine - you are knowingly picking a different tradeoff. > > Moreover, on large code bases, with long life spans, upgrading a > compiler is a significant investment. In any given project, I consider the toolchain as part of the project. I don't upgrade or replace it without very good reason. If I pull an old project out of its mothballs to make a change, the first thing I do is a clean rebuild and compare the binary to the one stored with the project, to be sure that everything builds cleanly and identically. (My record for doing this was almost exactly 20 years between code changes - and that code was in C90. But the compiler was happy to do inlining optimisations without the "inline" keyword.) > Almost invariably the > code has UB somewhere (I work on a code base that has been > evolving since before ANSI C; out of about 11 million lines, > there's lots of code that can be considered "legacy" in it). > From a business standpoint, it's not worth the time or > engineering resources required to go find all of it and make it > strictly conforming; from a technical standpoint, it may not > always be possible to do so anyway (though other superset > standards, like POSIX, are another matter), and in other cases > the resulting obfuscation to meet much stricter demands of ISO C > has been deemed, rightly or wrongly, as simply not worth it. It > may not ideal, but them's the breaks. > Fair enough. I am a little spoiled in that most of the code I work with, I wrote. But that is less true now than it used to be. In the old days, I would rarely need anything from the standard library and nothing from microcontroller vendors or third parties. (Before that, I would typically use assembly for microcontrollers, and then everything was my own work.) I have sometimes had to add "-fno-strict-aliasing -fwrapv" to deal with UB in other people's code, which always feels uncomfortable. And of course sometimes you get handed code written by a muppet with no clue what they are doing. I once had to debug code written by someone who did not see the point in keeping the number and type of parameters in sync between function definitions and function calls. The parts of the program that worked did so by sheer chance.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-02 15:06 +0000 |
| Subject | Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <fkCTR.17300$_BG8.7520@fx24.iad> |
| In reply to | #399616 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <10vlvie$2ne3j$2@dont-email.me>,
>David Brown <david.brown@hesbynett.no> wrote:
<snip>
>
>Yes. The way one boots an AMD server SoC, for instance,
>requires shipping a bunch of binary data structures around to
>little microcontrollers spread across a bunch of AXI buses, that
>are then responsible for things like configuring PCIe links and
>enumerating IO buses and so on. The vendor code for doing this
>is opaque, at best. For example,
>https://github.com/openSIL/openSIL/blob/turin_poc/xUSL/Nbio/Brh/NbioPcieComplexDataBrh.c
>(and that's a cleaned-up version).
Indeed, even the high-speed SERDES now have small microprocessors
that need proprietary firmware loaded at power-on.
Most vendors prefer to keep such details proprietary, for various
reasons both good and bad.
I'll agree that software (firmware) development at chip vendors
has been, in the past, an afterthought with the primary emphasis
on the hardware side. In modern chip design, software has taken
a larger role in both hardware definition, and the software
quality has improved somewhat.
>
>>[snip color mapping code]
>>
>>Yes, that would be vastly better. (I would still prefer to have
>>different named types for colours in the different encoding schemes.)
>
>I'll see your named types and raise you a bitfield struct. The
>shifting and masking is superfluous.
Or useful helpers:
a = bit::extract(value, 12, 0); /* Extract bits 12:0 from value */
b = bit::insert(b, 0x10, 5, 5); /* Insert 0x10 into b starting at bit 5 for 5 bits */
One might also define data structures for control and status registers using
bitfield structs.
e.g. for the SATA UAHC_GLB_OOBR register:
union UAHC_GBL_OOBR {
uint32_t u;
struct UAHC_GBL_OOBR_s {
#if __BYTE_ORDER == __BIG_ENDIAN
uint32_t we : 1; /**< R/W/H - Write enable. */
uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value. Writable only if WE is set. */
uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value. Writable only if WE is set. */
uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value. Writable only if WE is set. */
uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value. Writable only if WE is set. */
#else
uint32_t cimax : 8;
uint32_t cimin : 8;
uint32_t cwmax : 8;
uint32_t cwmin : 7;
uint32_t we : 1;
#endif
} s;
};
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-21 14:13 -0700 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <86h5mv8umk.fsf@linuxsc.com> |
| In reply to | #399630 |
scott@slp53.sl.home (Scott Lurndal) writes:
> One might also define data structures for control and status
> registers using bitfield structs.
Yeah. This kind of application (among others) I consider one of
the motivating forces behind bitfields.
[Some whitespace trimming done in the excerpt below.]
> e.g. for the SATA UAHC_GLB_OOBR register:
>
> union UAHC_GBL_OOBR {
> uint32_t u;
> struct UAHC_GBL_OOBR_s {
> #if __BYTE_ORDER == __BIG_ENDIAN
> uint32_t we : 1; /**< R/W/H - Write enable. */
> uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value [...] */
> uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value [...] */
> uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value [...] */
> uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value [...] */
> #else
> uint32_t cimax : 8;
> uint32_t cimin : 8;
> uint32_t cwmax : 8;
> uint32_t cwmin : 7;
> uint32_t we : 1;
> #endif
> } s;
> };
To me it seems kind of goofy to use uint32_t for the bitfields type.
I would just use unsigned, which is just as sure to work as intended,
isn't it?
(Personal note: I tried sending an email to you at the address in
your news posting, but my mailer complained about the address. If
it's okay could I ask you to send me an email at the address in my
news posting? Whatever you decide, thanks.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-22 08:58 +0200 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <111amdq$1at39$1@dont-email.me> |
| In reply to | #400174 |
On 21/06/2026 23:13, Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> One might also define data structures for control and status
>> registers using bitfield structs.
>
> Yeah. This kind of application (among others) I consider one of
> the motivating forces behind bitfields.
>
> [Some whitespace trimming done in the excerpt below.]
>
>> e.g. for the SATA UAHC_GLB_OOBR register:
>>
>> union UAHC_GBL_OOBR {
>> uint32_t u;
>> struct UAHC_GBL_OOBR_s {
>> #if __BYTE_ORDER == __BIG_ENDIAN
>> uint32_t we : 1; /**< R/W/H - Write enable. */
>> uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value [...] */
>> uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value [...] */
>> uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value [...] */
>> uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value [...] */
>> #else
>> uint32_t cimax : 8;
>> uint32_t cimin : 8;
>> uint32_t cwmax : 8;
>> uint32_t cwmin : 7;
>> uint32_t we : 1;
>> #endif
>> } s;
>> };
>
> To me it seems kind of goofy to use uint32_t for the bitfields type.
> I would just use unsigned, which is just as sure to work as intended,
> isn't it?
>
Size-specific types are almost always the best choice for situations
like this.
When you are using bitfields simply as a way to pack small bits of data
more efficiently, you use whatever style of type fits best with your
needs - consistency with the rest of the code, making the sizes
independent of the target, making the sizes adjust according to the
target, maximal portability across compilers and standards version -
whatever you like.
But when you are using them to fit to an existing externally defined
structure, fixed-size types are a big advantage (for the whole struct,
not just the bitfields). It is easier to see that the structure is
correct because you are explicit about the sizes. Types like "uint32_t"
have the advantage that they are not portable to targets that can't
support them - as it is likely that you would need to write such code
somewhat differently for it to work on a machine that does not have such
types, causing a compile-time error is useful.
And when the structures represent hardware registers, such as here, you
have additional motivation - these registers are typically accessed with
volatile accesses, and you often want to be sure of the exact size of
the accesses. That is always up to the implementation, but the norm is
that when your bitfields are of a given size, generated volatile
accesses for them use that matching size.
So "uint32_t" says /precisely/ what the code author wants to say for the
type. "unsigned" does not. "uint32_t" is appropriate regardless of the
target and the choice of standard integer sizes - "unsigned" is not.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-22 03:35 -0700 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <111b35d$1duuq$1@kst.eternal-september.org> |
| In reply to | #400184 |
David Brown <david.brown@hesbynett.no> writes:
> On 21/06/2026 23:13, Tim Rentsch wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> One might also define data structures for control and status
>>> registers using bitfield structs.
>> Yeah. This kind of application (among others) I consider one of
>> the motivating forces behind bitfields.
>> [Some whitespace trimming done in the excerpt below.]
>>
>>> e.g. for the SATA UAHC_GLB_OOBR register:
>>>
>>> union UAHC_GBL_OOBR {
>>> uint32_t u;
>>> struct UAHC_GBL_OOBR_s {
>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>> uint32_t we : 1; /**< R/W/H - Write enable. */
>>> uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value [...] */
>>> uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value [...] */
>>> uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value [...] */
>>> uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value [...] */
>>> #else
>>> uint32_t cimax : 8;
>>> uint32_t cimin : 8;
>>> uint32_t cwmax : 8;
>>> uint32_t cwmin : 7;
>>> uint32_t we : 1;
>>> #endif
>>> } s;
>>> };
>> To me it seems kind of goofy to use uint32_t for the bitfields type.
>> I would just use unsigned, which is just as sure to work as intended,
>> isn't it?
>>
>
> Size-specific types are almost always the best choice for situations
> like this.
>
> When you are using bitfields simply as a way to pack small bits of
> data more efficiently, you use whatever style of type fits best with
> your needs - consistency with the rest of the code, making the sizes
> independent of the target, making the sizes adjust according to the
> target, maximal portability across compilers and standards version -
> whatever you like.
>
> But when you are using them to fit to an existing externally defined
> structure, fixed-size types are a big advantage (for the whole struct,
> not just the bitfields). It is easier to see that the structure is
> correct because you are explicit about the sizes. Types like
> "uint32_t" have the advantage that they are not portable to targets
> that can't support them - as it is likely that you would need to write
> such code somewhat differently for it to work on a machine that does
> not have such types, causing a compile-time error is useful.
>
> And when the structures represent hardware registers, such as here,
> you have additional motivation - these registers are typically
> accessed with volatile accesses, and you often want to be sure of the
> exact size of the accesses. That is always up to the implementation,
> but the norm is that when your bitfields are of a given size,
> generated volatile accesses for them use that matching size.
>
> So "uint32_t" says /precisely/ what the code author wants to say for
> the type. "unsigned" does not. "uint32_t" is appropriate regardless
> of the target and the choice of standard integer sizes - "unsigned" is
> not.
uint32_t x;
says precisely that x is 32 bits, unsigned, with no padding bits. But
uint32_t bf : 1;
is meaningfully different from
unsigned bf : 1;
only because in most implementations (and ABIs), the underlying type of
a bit field affects the layout of the entire structure.
I accept that this is the case, but it's never made any sense to me, and
there's no hint of it in the C standard.
For example, if I write:
uint64_t bf : 1;
then the containing struct is typically at least 64 bits, even though
those other 63 bits aren't part of the bit field and other members can
be allocated within them.
It would make a lot more sense *to me* if an N-bit bit field were simply
N bits.
(And of course int, signed int, unsigned int, and bool are the only
portable types for bitfields -- but if you're using bit fields, it's
likely that portability isn't your only priority.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-22 10:50 +0000 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <111b412$41p$1@reader1.panix.com> |
| In reply to | #400186 |
In article <111b35d$1duuq$1@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>[snip]
> uint32_t x;
>says precisely that x is 32 bits, unsigned, with no padding bits. But
> uint32_t bf : 1;
>is meaningfully different from
> unsigned bf : 1;
>only because in most implementations (and ABIs), the underlying type of
>a bit field affects the layout of the entire structure.
>
>I accept that this is the case, but it's never made any sense to me, and
>there's no hint of it in the C standard.
>
>For example, if I write:
> uint64_t bf : 1;
>then the containing struct is typically at least 64 bits, even though
>those other 63 bits aren't part of the bit field and other members can
>be allocated within them.
>
>It would make a lot more sense *to me* if an N-bit bit field were simply
>N bits.
If dealing with, e.g., hardware, then the author should probably
constrain things so that bitfields occupy the fully width of the
underlying type. E.g.,
uint64_t bt:1;
uint64_t reserved:63;
And so forth.
>(And of course int, signed int, unsigned int, and bool are the only
>portable types for bitfields -- but if you're using bit fields, it's
>likely that portability isn't your only priority.)
It may be, but you'll be programming against an ABI (or set of
ABIs) or similar external standards that give you stronger
guarantees than ISO C, at that point.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-22 12:59 +0200 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <111b4if$1dtp4$1@dont-email.me> |
| In reply to | #400186 |
On 22/06/2026 12:35, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 21/06/2026 23:13, Tim Rentsch wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> One might also define data structures for control and status
>>>> registers using bitfield structs.
>>> Yeah. This kind of application (among others) I consider one of
>>> the motivating forces behind bitfields.
>>> [Some whitespace trimming done in the excerpt below.]
>>>
>>>> e.g. for the SATA UAHC_GLB_OOBR register:
>>>>
>>>> union UAHC_GBL_OOBR {
>>>> uint32_t u;
>>>> struct UAHC_GBL_OOBR_s {
>>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>>> uint32_t we : 1; /**< R/W/H - Write enable. */
>>>> uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value [...] */
>>>> uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value [...] */
>>>> uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value [...] */
>>>> uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value [...] */
>>>> #else
>>>> uint32_t cimax : 8;
>>>> uint32_t cimin : 8;
>>>> uint32_t cwmax : 8;
>>>> uint32_t cwmin : 7;
>>>> uint32_t we : 1;
>>>> #endif
>>>> } s;
>>>> };
>>> To me it seems kind of goofy to use uint32_t for the bitfields type.
>>> I would just use unsigned, which is just as sure to work as intended,
>>> isn't it?
>>>
>>
>> Size-specific types are almost always the best choice for situations
>> like this.
>>
>> When you are using bitfields simply as a way to pack small bits of
>> data more efficiently, you use whatever style of type fits best with
>> your needs - consistency with the rest of the code, making the sizes
>> independent of the target, making the sizes adjust according to the
>> target, maximal portability across compilers and standards version -
>> whatever you like.
>>
>> But when you are using them to fit to an existing externally defined
>> structure, fixed-size types are a big advantage (for the whole struct,
>> not just the bitfields). It is easier to see that the structure is
>> correct because you are explicit about the sizes. Types like
>> "uint32_t" have the advantage that they are not portable to targets
>> that can't support them - as it is likely that you would need to write
>> such code somewhat differently for it to work on a machine that does
>> not have such types, causing a compile-time error is useful.
>>
>> And when the structures represent hardware registers, such as here,
>> you have additional motivation - these registers are typically
>> accessed with volatile accesses, and you often want to be sure of the
>> exact size of the accesses. That is always up to the implementation,
>> but the norm is that when your bitfields are of a given size,
>> generated volatile accesses for them use that matching size.
>>
>> So "uint32_t" says /precisely/ what the code author wants to say for
>> the type. "unsigned" does not. "uint32_t" is appropriate regardless
>> of the target and the choice of standard integer sizes - "unsigned" is
>> not.
>
> uint32_t x;
> says precisely that x is 32 bits, unsigned, with no padding bits. But
> uint32_t bf : 1;
> is meaningfully different from
> unsigned bf : 1;
> only because in most implementations (and ABIs), the underlying type of
> a bit field affects the layout of the entire structure.
>
> I accept that this is the case, but it's never made any sense to me, and
> there's no hint of it in the C standard.
>
> For example, if I write:
> uint64_t bf : 1;
> then the containing struct is typically at least 64 bits, even though
> those other 63 bits aren't part of the bit field and other members can
> be allocated within them.
>
> It would make a lot more sense *to me* if an N-bit bit field were simply
> N bits.
There is sense in that, yes, but as I said the access type is important
too. The struct Scott gave would not be the same if it used uint8_t
instead of uint32_t for the bit-fields, even though there would be no
difference in the alignments or paddings (on a "normal" cpus, rather
than a DS9000). For hardware registers, access size is often critical -
it is not like accessing ram. And while the choice of access size is
implementation defined, the size of the type used for the bit-field is
the most common way to determine that (for volatile accesses).
If C had a different way of specifying access sizes, then it might be a
bit different - perhaps _BitInt types would be the best choices for
bit-field types.
>
> (And of course int, signed int, unsigned int, and bool are the only
> portable types for bitfields -- but if you're using bit fields, it's
> likely that portability isn't your only priority.)
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-28 09:42 -0700 |
| Subject | Storage needed when there are bit-field members |
| Message-ID | <86v7b27h20.fsf_-_@linuxsc.com> |
| In reply to | #400186 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [...] > uint32_t x; > says precisely that x is 32 bits, unsigned, with no padding bits. Actually it says a little bit more, but never mind that. > But > uint32_t bf : 1; > is meaningfully different from > unsigned bf : 1; > only because in most implementations (and ABIs), the underlying type > of a bit field affects the layout of the entire structure. I would say this differently. The two member declarations shown might be meaningfully different, depending on the implementation: they >can< be different, but they don't have to be, and indeed on many implementations they are exactly the same. > I accept that this is the case, but it's never made any sense to me, > and there's no hint of it in the C standard. I think saying there is not even a hint is an overstatement. The C standard says that an implementation "may allocate any addressable storage unit large enough to hold a bit-field." It shouldn't be a surprise that how much storage is allocated depends on the type of the bit-field member. For example, a bit-field of type 'unsigned' might very well choose a larger storage unit than what is chosen for a bit-field of type '_Bool'. It seems obvious that the type of a bit-field might affect what size and layout is chosen. > For example, if I write: > uint64_t bf : 1; > then the containing struct is typically at least 64 bits, even > though those other 63 bits aren't part of the bit field and other > members can be allocated within them. > > It would make a lot more sense *to me* if an N-bit bit field were > simply N bits. Two problems with that. One, it seems to be in conflict with what the C standard says about 0-width bit-fields. Two, the C standard explicitly allows allocating bit-fields using a high-to-low order or a low-to-high order (implementation-defined choice). Presumably this freedom is given to accommodate both big- and little-endian platforms. The idea that an N-bit bit-field should simply be N bits doesn't work in big-endian environments. It seems better to allow little-endian implementations to choose a size that matches what a big-endian implementation would use, rather than insisting that they be different.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-28 18:06 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <111sgeq$3vq40$1@kst.eternal-september.org> |
| In reply to | #400273 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> But
>> uint32_t bf : 1;
>> is meaningfully different from
>> unsigned bf : 1;
>
>> only because in most implementations (and ABIs), the underlying type
>> of a bit field affects the layout of the entire structure.
[...]
>> I accept that this is the case, but it's never made any sense to me,
>> and there's no hint of it in the C standard.
>
> I think saying there is not even a hint is an overstatement. The C
> standard says that an implementation "may allocate any addressable
> storage unit large enough to hold a bit-field." It shouldn't be a
> surprise that how much storage is allocated depends on the type of
> the bit-field member. For example, a bit-field of type 'unsigned'
> might very well choose a larger storage unit than what is chosen
> for a bit-field of type '_Bool'. It seems obvious that the type of
> a bit-field might affect what size and layout is chosen.
I'm sure it seems obvious to you. As I said, it's not at all
obvious to me.
Prior to C99, C didn't even require compilers to support bit-field types
other than int, unsigned int, and signed int. The declared type might
typically be used only to determine the signedness of the bit-field
(though I *think* most compilers permitted other types).
Implementations are certainly not *required* to use the declared
type of a bit-field as a factor in deciding how to allocate it,
or how to allocate the rest of the structure. Allocating just one
byte for an isolated 1-bit bit-field of any declared type would
be conforming. A conforming compiler could use the declared type
only to determine the signedness and the maximum allowed width of
a bit-field (and its conversion behavior in the case of bool)
>> For example, if I write:
>> uint64_t bf : 1;
>
>> then the containing struct is typically at least 64 bits, even
>> though those other 63 bits aren't part of the bit field and other
>> members can be allocated within them.
>>
>> It would make a lot more sense *to me* if an N-bit bit field were
>> simply N bits.
>
> Two problems with that. One, it seems to be in conflict with what
> the C standard says about 0-width bit-fields.
0-width bit-fields are obviously a special case.
> Two, the C standard
> explicitly allows allocating bit-fields using a high-to-low order or
> a low-to-high order (implementation-defined choice). Presumably
> this freedom is given to accommodate both big- and little-endian
> platforms. The idea that an N-bit bit-field should simply be N bits
> doesn't work in big-endian environments. It seems better to allow
> little-endian implementations to choose a size that matches what a
> big-endian implementation would use, rather than insisting that they
> be different.
I honestly don't understand your point here. How does making
N-bit bit-fields N bits not work in a big-endian environment?
Can you elaborate? Of course endianness can affect how bit-fields
are allocated within a "storage unit".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-28 20:20 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <111soae$1eq8$1@kst.eternal-september.org> |
| In reply to | #400276 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>> It would make a lot more sense *to me* if an N-bit bit field were
>>> simply N bits.
[...]
>> Two, the C standard
>> explicitly allows allocating bit-fields using a high-to-low order or
>> a low-to-high order (implementation-defined choice). Presumably
>> this freedom is given to accommodate both big- and little-endian
>> platforms. The idea that an N-bit bit-field should simply be N bits
>> doesn't work in big-endian environments. It seems better to allow
>> little-endian implementations to choose a size that matches what a
>> big-endian implementation would use, rather than insisting that they
>> be different.
>
> I honestly don't understand your point here. How does making
> N-bit bit-fields N bits not work in a big-endian environment?
> Can you elaborate? Of course endianness can affect how bit-fields
> are allocated within a "storage unit".
Perhaps you read more than I intended into my statement about N-bit
bit-fields being "simply N bits".
Thinking about this a bit more.
As of C90, "A bit-field shall have a type that is a qualified or
unqualified version of one of int, unsigned int, or signed int."
The "shall" is outside a constraint, so an implementation could allow
bit-fields of other types without triggering a required diagnostic,
and many implementations did so.
C99 added _Bool bit-fields, and explicitly allowed "some other
implementation-defined type". C23 allows bit-fields of bit-precise
integer types; I'll avoid thinking about that for now.
Implementions commonly use the declared type of a bit-field to
affect the layout, not necessarily of the bit-field itself, but
of the containing structure. Given that the standard doesn't
require support for types other than bool and the int types (and
now bit-precise integer types), the idea that `short bf:1` and
`long bf:1` have different semantics is not, as far as I can tell,
implied by anything in the standard.
I understand that implementations *can* allow other integer types
in bit-field declarations, and that they can use the declared type
in implementation-defined ways.
One possible approach would be to use the declared type only to
determine the signedness of the bit-field (and its conversion
behavior in the case of bool), and the upper bound for the number
of bits (`int bf:33` is a constraint violation if int is 32 bits).
In this relatively simple approach, there's no point in defining
a bit-field with one of the char or short types.
Using gcc on Linux, if I define a 1-bit bit-field with a 64-bit type,
that forces the containing structure to be at least 64 bits -- but
not by reserving a 64-bit region to hold the bit-field. If I define
a struct containing a 1-bit unsigned long long bit-field followed by
a 1-byte ordinary member, the second member is at a 1-bytes offset.
I had gotten the impression that the behavior is imposed by ABIs,
but my copy of the "System V Application Binary Interface AMD64
Architecture Processor Supplement" just says:
- bit-fields are allocated from right to left
- bit-fields must be contained in a storage unit appropriate for
its declared type
- bit-fields may share a storage unit with other struct / union
members
which doesn't seem to be enough to specify the behavior I see
(and I find it annoyingly vague).
Is there a document (ABI, compiler document, whatever) that specifies
the (odd, to me) behavior I'm seeing?
Here's a test program:
#include <stdio.h>
#include <stddef.h>
int main(void) {
struct s1 { unsigned char bf:1; unsigned char c; };
struct s2 { unsigned short bf:1; unsigned char c; };
struct s3 { unsigned int bf:1; unsigned char c; };
struct s4 { unsigned long bf:1; unsigned char c; };
struct s5 { unsigned long long bf:1; unsigned char c; };
printf("%-18s %-4s %-6s %s\n",
"type", "size", "offset", "struct-size");
printf("%-18s %-4zu %-6zu %-1zu\n",
"unsigned char",
sizeof (unsigned char),
offsetof(struct s1, c),
sizeof (struct s1));
printf("%-18s %-4zu %-6zu %-1zu\n",
"unsigned short",
sizeof (unsigned short),
offsetof(struct s2, c),
sizeof (struct s2));
printf("%-18s %-4zu %-6zu %-1zu\n",
"unsigned int",
sizeof (unsigned int),
offsetof(struct s3, c),
sizeof (struct s3));
printf("%-18s %-4zu %-6zu %-1zu\n",
"unsigned long",
sizeof (unsigned long),
offsetof(struct s4, c),
sizeof (struct s4));
printf("%-18s %-4zu %-6zu %-1zu\n",
"unsigned long long",
sizeof (unsigned long long),
offsetof(struct s5, c),
sizeof (struct s5));
}
and its output on my system (Ubuntu, x86_64):
type size offset struct-size
unsigned char 1 1 2
unsigned short 2 1 2
unsigned int 4 1 4
unsigned long 8 1 8
unsigned long long 8 1 8
Again, the declared type of a bit-field doesn't affect how the
bit-field itself is allocated, but it does affect the size of the
containing struct, but it doesn't prevent other members from being
allocated within that space.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-14 14:56 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <86o6f45pu7.fsf@linuxsc.com> |
| In reply to | #400280 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>>>> It would make a lot more sense *to me* if an N-bit bit field were
>>>> simply N bits.
>
> [...]
>
>>> Two, the C standard
>>> explicitly allows allocating bit-fields using a high-to-low order or
>>> a low-to-high order (implementation-defined choice). Presumably
>>> this freedom is given to accommodate both big- and little-endian
>>> platforms. The idea that an N-bit bit-field should simply be N bits
>>> doesn't work in big-endian environments. It seems better to allow
>>> little-endian implementations to choose a size that matches what a
>>> big-endian implementation would use, rather than insisting that they
>>> be different.
>>
>> I honestly don't understand your point here. How does making
>> N-bit bit-fields N bits not work in a big-endian environment?
>> Can you elaborate? Of course endianness can affect how bit-fields
>> are allocated within a "storage unit".
>
> Perhaps you read more than I intended into my statement about N-bit
> bit-fields being "simply N bits".
It's possible, but I don't think I did.
> Thinking about this a bit more.
>
> As of C90, "A bit-field shall have a type that is a qualified or
> unqualified version of one of int, unsigned int, or signed int."
> The "shall" is outside a constraint, so an implementation could allow
> bit-fields of other types without triggering a required diagnostic,
> and many implementations did so.
Allowing other types is listed as a common extension.
> C99 added _Bool bit-fields, and explicitly allowed "some other
> implementation-defined type". C23 allows bit-fields of bit-precise
> integer types; I'll avoid thinking about that for now.
>
> Implementions commonly use the declared type of a bit-field to
> affect the layout, not necessarily of the bit-field itself, but
> of the containing structure. Given that the standard doesn't
> require support for types other than bool and the int types (and
> now bit-precise integer types), the idea that `short bf:1` and
> `long bf:1` have different semantics is not, as far as I can tell,
> implied by anything in the standard.
They may have different semantics, depending on what particular
implementation-specific choices are made, but as best I can tell
the C standard doesn't require them to.
> I understand that implementations *can* allow other integer types
> in bit-field declarations, and that they can use the declared type
> in implementation-defined ways.
I don't think there is a specific explicit requirement that how a
bit-field's declared type affects layout be implementation-defined.
There is a general requirement that the number, order, and encodings
of bytes that make up an object be implementation-defined if they
are not explicitly specified.
> One possible approach would be to use the declared type only to
> determine the signedness of the bit-field (and its conversion
> behavior in the case of bool), and the upper bound for the number
> of bits (`int bf:33` is a constraint violation if int is 32 bits).
> In this relatively simple approach, there's no point in defining
> a bit-field with one of the char or short types.
I think that depends on how the allocatable storage unit for a
given bit-field is chosen. The C standard is pretty vague about
what determines what allocatable storage unit is chosen in each
case, and under what circumstances that might vary from bit-field
to bit-field.
> Using gcc on Linux, if I define a 1-bit bit-field with a 64-bit type,
> that forces the containing structure to be at least 64 bits -- but
> not by reserving a 64-bit region to hold the bit-field. If I define
> a struct containing a 1-bit unsigned long long bit-field followed by
> a 1-byte ordinary member, the second member is at a 1-bytes offset.
>
> I had gotten the impression that the behavior is imposed by ABIs,
> but my copy of the "System V Application Binary Interface AMD64
> Architecture Processor Supplement" just says:
>
> - bit-fields are allocated from right to left
I think that means they are allocated in order of low-to-high,
because the AMD64 architecture is little-endian.
> - bit-fields must be contained in a storage unit appropriate for
> its declared type
> - bit-fields may share a storage unit with other struct / union
> members
>
> which doesn't seem to be enough to specify the behavior I see
> (and I find it annoyingly vague).
>
> Is there a document (ABI, compiler document, whatever) that specifies
> the (odd, to me) behavior I'm seeing?
As best I can tell the layout you are seeing is consistent with
the rules stated above. Perhaps the rules are deliberately meant
to be an under-specification (which IMO is not a bad thing).
> Here's a test program:
>
> #include <stdio.h>
> #include <stddef.h>
> int main(void) {
> struct s1 { unsigned char bf:1; unsigned char c; };
> struct s2 { unsigned short bf:1; unsigned char c; };
> struct s3 { unsigned int bf:1; unsigned char c; };
> struct s4 { unsigned long bf:1; unsigned char c; };
> struct s5 { unsigned long long bf:1; unsigned char c; };
>
> printf("%-18s %-4s %-6s %s\n",
> "type", "size", "offset", "struct-size");
>
> printf("%-18s %-4zu %-6zu %-1zu\n",
> "unsigned char",
> sizeof (unsigned char),
> offsetof(struct s1, c),
> sizeof (struct s1));
> printf("%-18s %-4zu %-6zu %-1zu\n",
> "unsigned short",
> sizeof (unsigned short),
> offsetof(struct s2, c),
> sizeof (struct s2));
> printf("%-18s %-4zu %-6zu %-1zu\n",
> "unsigned int",
> sizeof (unsigned int),
> offsetof(struct s3, c),
> sizeof (struct s3));
> printf("%-18s %-4zu %-6zu %-1zu\n",
> "unsigned long",
> sizeof (unsigned long),
> offsetof(struct s4, c),
> sizeof (struct s4));
> printf("%-18s %-4zu %-6zu %-1zu\n",
> "unsigned long long",
> sizeof (unsigned long long),
> offsetof(struct s5, c),
> sizeof (struct s5));
> }
>
> and its output on my system (Ubuntu, x86_64):
>
> type size offset struct-size
> unsigned char 1 1 2
> unsigned short 2 1 2
> unsigned int 4 1 4
> unsigned long 8 1 8
> unsigned long long 8 1 8
>
> Again, the declared type of a bit-field doesn't affect how the
> bit-field itself is allocated, but it does affect the size of the
> containing struct, but it doesn't prevent other members from being
> allocated within that space.
You should be able to determine the layout exactly from the
implementation's documentation. If you can't, that means the
implementation is not conforming, because these are implemenation
defined behaviors, and so much be documented.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-14 22:30 +0000 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <5GMfS.13614$EDc8.5150@fx24.iad> |
| In reply to | #401191 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [...]
>>
>>>>> It would make a lot more sense *to me* if an N-bit bit field were
>>>>> simply N bits.
>>
>> [...]
>>
<snip>
>> I had gotten the impression that the behavior is imposed by ABIs,
>> but my copy of the "System V Application Binary Interface AMD64
>> Architecture Processor Supplement" just says:
>>
>> - bit-fields are allocated from right to left
>
>I think that means they are allocated in order of low-to-high,
>because the AMD64 architecture is little-endian.
>
>> - bit-fields must be contained in a storage unit appropriate for
>> its declared type
>> - bit-fields may share a storage unit with other struct / union
>> members
>>
>> which doesn't seem to be enough to specify the behavior I see
>> (and I find it annoyingly vague).
>>
>> Is there a document (ABI, compiler document, whatever) that specifies
>> the (odd, to me) behavior I'm seeing?
>
>As best I can tell the layout you are seeing is consistent with
>the rules stated above. Perhaps the rules are deliberately meant
>to be an under-specification (which IMO is not a bad thing).
>
>> Here's a test program:
>>
>> #include <stdio.h>
>> #include <stddef.h>
>> int main(void) {
>> struct s1 { unsigned char bf:1; unsigned char c; };
>> struct s2 { unsigned short bf:1; unsigned char c; };
>> struct s3 { unsigned int bf:1; unsigned char c; };
>> struct s4 { unsigned long bf:1; unsigned char c; };
>> struct s5 { unsigned long long bf:1; unsigned char c; };
FWIW, adding GCC's __attribute__((packed)) to each of those, we see:
> type size offset struct-size
> unsigned char 1 1 2
> unsigned short 2 1 2
> unsigned int 4 1 4
> unsigned long 8 1 8
> unsigned long long 8 1 8
type size offset struct-size
unsigned char 1 1 2
unsigned short 2 1 2
unsigned int 4 1 2
unsigned long 8 1 2
unsigned long long 8 1 2
Which doesn't seem to violate the ABI rules you quoted.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 16:10 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <86cxvj3rq1.fsf@linuxsc.com> |
| In reply to | #401192 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>> [...]
>>>
>>>>>> It would make a lot more sense *to me* if an N-bit bit field were
>>>>>> simply N bits.
>>>
>>> [...]
>
> <snip>
>
>>> I had gotten the impression that the behavior is imposed by ABIs,
>>> but my copy of the "System V Application Binary Interface AMD64
>>> Architecture Processor Supplement" just says:
>>>
>>> - bit-fields are allocated from right to left
>>
>> I think that means they are allocated in order of low-to-high,
>> because the AMD64 architecture is little-endian.
>>
>>> - bit-fields must be contained in a storage unit appropriate for
>>> its declared type
>>> - bit-fields may share a storage unit with other struct / union
>>> members
>>>
>>> which doesn't seem to be enough to specify the behavior I see
>>> (and I find it annoyingly vague).
>>>
>>> Is there a document (ABI, compiler document, whatever) that specifies
>>> the (odd, to me) behavior I'm seeing?
>>
>> As best I can tell the layout you are seeing is consistent with
>> the rules stated above. Perhaps the rules are deliberately meant
>> to be an under-specification (which IMO is not a bad thing).
>>
>>> Here's a test program:
>>>
>>> #include <stdio.h>
>>> #include <stddef.h>
>>> int main(void) {
>>> struct s1 { unsigned char bf:1; unsigned char c; };
>>> struct s2 { unsigned short bf:1; unsigned char c; };
>>> struct s3 { unsigned int bf:1; unsigned char c; };
>>> struct s4 { unsigned long bf:1; unsigned char c; };
>>> struct s5 { unsigned long long bf:1; unsigned char c; };
>
> FWIW, adding GCC's __attribute__((packed)) to each of those, we see:
>
>> type size offset struct-size
>> unsigned char 1 1 2
>> unsigned short 2 1 2
>> unsigned int 4 1 4
>> unsigned long 8 1 8
>> unsigned long long 8 1 8
>
> type size offset struct-size
> unsigned char 1 1 2
> unsigned short 2 1 2
> unsigned int 4 1 2
> unsigned long 8 1 2
> unsigned long long 8 1 2
>
> Which doesn't seem to violate the ABI rules you quoted.
That's good to know I guess, although I'm not sure what it
tells me. My impression is that using attribute__((packed))
produces code that may be less portable than not using it.
Generally I try to write code that avoids compiler-specific
constructs whenever feasible.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-16 15:20 +0000 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <jzkgS.4883$4QJ.2251@fx21.iad> |
| In reply to | #401223 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Here's a test program:
>>>>
>>>> #include <stdio.h>
>>>> #include <stddef.h>
>>>> int main(void) {
>>>> struct s1 { unsigned char bf:1; unsigned char c; };
>>>> struct s2 { unsigned short bf:1; unsigned char c; };
>>>> struct s3 { unsigned int bf:1; unsigned char c; };
>>>> struct s4 { unsigned long bf:1; unsigned char c; };
>>>> struct s5 { unsigned long long bf:1; unsigned char c; };
>>
>> FWIW, adding GCC's __attribute__((packed)) to each of those, we see:
>>
>>> type size offset struct-size
>>> unsigned char 1 1 2
>>> unsigned short 2 1 2
>>> unsigned int 4 1 4
>>> unsigned long 8 1 8
>>> unsigned long long 8 1 8
>>
>> type size offset struct-size
>> unsigned char 1 1 2
>> unsigned short 2 1 2
>> unsigned int 4 1 2
>> unsigned long 8 1 2
>> unsigned long long 8 1 2
>>
>> Which doesn't seem to violate the ABI rules you quoted.
>
>That's good to know I guess, although I'm not sure what it
>tells me. My impression is that using attribute__((packed))
>produces code that may be less portable than not using it.
>Generally I try to write code that avoids compiler-specific
>constructs whenever feasible.
I generally only use the packed attribute when creating
a C struct to match a hardware register, data structure or
data packet.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-14 14:19 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <86se4g5riz.fsf@linuxsc.com> |
| In reply to | #400276 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>>> But
>>> uint32_t bf : 1;
>>> is meaningfully different from
>>> unsigned bf : 1;
>>>
>>> only because in most implementations (and ABIs), the underlying type
>>> of a bit field affects the layout of the entire structure.
>
> [...]
>
>>> I accept that this is the case, but it's never made any sense to me,
>>> and there's no hint of it in the C standard.
>>
>> I think saying there is not even a hint is an overstatement. The C
>> standard says that an implementation "may allocate any addressable
>> storage unit large enough to hold a bit-field." It shouldn't be a
>> surprise that how much storage is allocated depends on the type of
>> the bit-field member. For example, a bit-field of type 'unsigned'
>> might very well choose a larger storage unit than what is chosen
>> for a bit-field of type '_Bool'. It seems obvious that the type of
>> a bit-field might affect what size and layout is chosen.
>
> I'm sure it seems obvious to you. As I said, it's not at all
> obvious to me.
>
> Prior to C99, C didn't even require compilers to support bit-field
> types other than int, unsigned int, and signed int.
True, but allowing other types was listed as a common extension.
> The declared
> type might typically be used only to determine the signedness of the
> bit-field (though I *think* most compilers permitted other types).
>
> Implementations are certainly not *required* to use the declared
> type of a bit-field as a factor in deciding how to allocate it,
> or how to allocate the rest of the structure. Allocating just one
> byte for an isolated 1-bit bit-field of any declared type would
> be conforming. A conforming compiler could use the declared type
> only to determine the signedness and the maximum allowed width of
> a bit-field (and its conversion behavior in the case of bool)
Yes, it could.
>>> For example, if I write:
>>> uint64_t bf : 1;
>>>
>>> then the containing struct is typically at least 64 bits, even
>>> though those other 63 bits aren't part of the bit field and other
>>> members can be allocated within them.
>>>
>>> It would make a lot more sense *to me* if an N-bit bit field were
>>> simply N bits.
>>
>> Two problems with that. One, it seems to be in conflict with what
>> the C standard says about 0-width bit-fields.
>
> 0-width bit-fields are obviously a special case.
Sorry for not making my point more clear. My comment is meant to
to raise the question of whether
struct x {
_Bool foo:1;
_Bool :0;
char c;
};
and
struct y {
unsigned foo:1;
_Bool :0;
char c;
};
should be different. I'm inclined to think they should be, by
which I mean my preference is for compilers where they would be.
>> Two, the C standard
>> explicitly allows allocating bit-fields using a high-to-low order
>> or a low-to-high order (implementation-defined choice). Presumably
>> this freedom is given to accommodate both big- and little-endian
>> platforms. The idea that an N-bit bit-field should simply be N
>> bits doesn't work in big-endian environments. It seems better to
>> allow little-endian implementations to choose a size that matches
>> what a big-endian implementation would use, rather than insisting
>> that they be different.
>
> I honestly don't understand your point here. How does making
> N-bit bit-fields N bits not work in a big-endian environment?
> Can you elaborate? Of course endianness can affect how bit-fields
> are allocated within a "storage unit".
Suppose we have a little endian machine where bit-fields are
allocated in a high-to-low order. Further suppose that unsigned
ints are 32 bits. In such an environment, I would expect (or
prefer) a definition like this
struct foo {
unsigned x:15;
};
to be represented like so
-------- -------- -XXXXXXX XXXXXXXX
where the X's indicate where the bit-field goes, and the -'s
indicate where there are padding bits. In such an environment,
I would find it counterintuitive if this type were represented
thus
-XXXXXXX XXXXXXXX
rather than as shown in the previous layout.
[toc] | [prev] | [next] | [standalone]
Page 20 of 23 — ← Prev page 1 … 18 19 [20] 21 22 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web