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 463 — 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 Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:12 +0800
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") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-19 08:32 -0700
Re: Expression statements (was Re: Meaning of "expression") Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:09 -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 antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:34 +0000
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 15:26 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 11:00 +0200
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 03:30 -0700
Re: Storage needed when there are bit-field members David Brown <david.brown@hesbynett.no> - 2026-08-20 13:58 +0200
Re: Storage needed when there are bit-field members Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 13:37 -0700
Re: Storage needed when there are bit-field members scott@slp53.sl.home (Scott Lurndal) - 2026-08-20 14:50 +0000
Re: Storage needed when there are bit-field members "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-20 12:31 -0700
Re: Storage needed when there are bit-field members antispam@fricas.org (Waldek Hebisch) - 2026-08-20 19:55 +0000
Re: Storage needed when there are bit-field members Michael S <already5chosen@yahoo.com> - 2026-08-20 22:15 +0300
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 antispam@fricas.org (Waldek Hebisch) - 2026-08-19 19:57 +0000
Re: Microcontroller software stacks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 17:31 -0700
Re: Microcontroller software stacks (was Re: this girl calls c ugly) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:51 +0800
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 22 of 24 — ← Prev page 1 … 20 21 [22] 23 24 Next page →
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-15 05:02 +0800 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <knLfS.354154$aXr.97371@fx18.ams4> |
| In reply to | #401174 |
On 15/08/2026 3:51 AM, Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> 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?
>>
>> The SATA hardware register is defined as a 32-bit register in the
>> SATA specification. Therefore we explicitly declare it as such.
>
> I understand the motivation for using uint32_t for the union member
> u. My question is only about the type used for the bitfields. Do
> you know of any platform, or even suspect that there might be a
> platform, where using 'unsigned' rather than 'uint32_t' for the type
> of the bitfields makes any difference at all?
Yes, people still code real mode DOS for fun and amusement. Not to
mention boot strapping code for /real operating systems/, for some value
of /real/.
On 6502, int is 16bit, I believe, for reasons. And I also believe it
makes total sense to keep int 16bit on a 68000.
>
>> There are other hardware registers in our implementation of the SATA
>> controller that are defined as 64-bit registers, for those we use
>> uint64_t (rather than relying on 'unsigned long' for 64-bit linux
>> or 'unsigned long long' for 32-bit OS - and this code was designed
>> to be compiled for both 32-bit and 64-bit targets originally).
>
> Sure, for the non-bitfield member. My question is only about
> (unsigned) bitfields all of width 8 or less.
I'm ignorant of the prior discussion, so I'll stop now; happy retro-
coding!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-08-15 01:18 +0100 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <115ob7t$2v45v$1@dont-email.me> |
| In reply to | #401184 |
On 14/08/2026 22:02, Johann 'Myrkraverk' Oskarsson wrote:
> On 15/08/2026 3:51 AM, Tim Rentsch wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> 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?
>>>
>>> The SATA hardware register is defined as a 32-bit register in the
>>> SATA specification. Therefore we explicitly declare it as such.
>>
>> I understand the motivation for using uint32_t for the union member
>> u. My question is only about the type used for the bitfields. Do
>> you know of any platform, or even suspect that there might be a
>> platform, where using 'unsigned' rather than 'uint32_t' for the type
>> of the bitfields makes any difference at all?
>
> Yes, people still code real mode DOS for fun and amusement. Not to
> mention boot strapping code for /real operating systems/, for some value
> of /real/.
>
> On 6502, int is 16bit, I believe, for reasons. And I also believe it
> makes total sense to keep int 16bit on a 68000.
>
WTF are you on about? If you're an actual human then I suggest getting
some help. If not then where the hell does all this bilge come from?
>>> There are other hardware registers in our implementation of the SATA
>>> controller that are defined as 64-bit registers, for those we use
>>> uint64_t (rather than relying on 'unsigned long' for 64-bit linux
>>> or 'unsigned long long' for 32-bit OS - and this code was designed
>>> to be compiled for both 32-bit and 64-bit targets originally).
>>
>> Sure, for the non-bitfield member. My question is only about
>> (unsigned) bitfields all of width 8 or less.
>
> I'm ignorant of the prior discussion, so I'll stop now; happy retro-
> coding!
'Happy' - OK, CMT has finally convinced me!
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-16 13:52 +0800 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <iecgS.203613$xpxd.124363@fx14.ams4> |
| In reply to | #401193 |
On 15/08/2026 8:18 AM, bart wrote:
> On 14/08/2026 22:02, Johann 'Myrkraverk' Oskarsson wrote:
>> On 15/08/2026 3:51 AM, Tim Rentsch wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> 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?
>>>>
>>>> The SATA hardware register is defined as a 32-bit register in the
>>>> SATA specification. Therefore we explicitly declare it as such.
>>>
>>> I understand the motivation for using uint32_t for the union member
>>> u. My question is only about the type used for the bitfields. Do
>>> you know of any platform, or even suspect that there might be a
>>> platform, where using 'unsigned' rather than 'uint32_t' for the type
>>> of the bitfields makes any difference at all?
>>
>> Yes, people still code real mode DOS for fun and amusement. Not to
>> mention boot strapping code for /real operating systems/, for some value
>> of /real/.
>>
>> On 6502, int is 16bit, I believe, for reasons. And I also believe it
>> makes total sense to keep int 16bit on a 68000.
>>
>
> WTF are you on about? If you're an actual human then I suggest getting
> some help. If not then where the hell does all this bilge come from?
Hey bart! You fucking piece of shit asshole. Tim asked a question. I
answered it. There is a difference between 'unsigned' and 'uint32_t' on
DOS, you fucking piece of shit know-nothing slob burger.
Now, if Tim decides real mode DOS is not a target for his own question,
then he should be answering with a polite followup, or spew his own
hatred, and not you, you miserable psychopath!
>>>> There are other hardware registers in our implementation of the SATA
>>>> controller that are defined as 64-bit registers, for those we use
>>>> uint64_t (rather than relying on 'unsigned long' for 64-bit linux
>>>> or 'unsigned long long' for 32-bit OS - and this code was designed
>>>> to be compiled for both 32-bit and 64-bit targets originally).
>>>
>>> Sure, for the non-bitfield member. My question is only about
>>> (unsigned) bitfields all of width 8 or less.
>>
>> I'm ignorant of the prior discussion, so I'll stop now; happy retro-
>> coding!
>
> 'Happy' - OK, CMT has finally convinced me!
Happy living in alt.fantasy, you fucking piece of shit!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-14 14:06 -0700 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <115o01f$2rq0k$1@kst.eternal-september.org> |
| In reply to | #401174 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> I understand the motivation for using uint32_t for the union member
> u. My question is only about the type used for the bitfields. Do
> you know of any platform, or even suspect that there might be a
> platform, where using 'unsigned' rather than 'uint32_t' for the type
> of the bitfields makes any difference at all?
On platforms where unsigned int is 32 bits, I'd be very surprised
if it made any difference. If unsigned it is, say, 16 or 64 bits,
it can make a difference.
As I wrote here a while ago, "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." This was in
a thread with the subject "Storage needed when there are bit-field
members", in a followup to your post a few days after the article
to which you've just replied.
On the other hand, the standard only requires support for
bitfields of declared types int, signed int, unsigned int, and bool
(and bit-precise integer types in C23 and later); a conforming
implementation might not support bit-fields of type uint32_t.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-14 21:42 +0000 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <iZLfS.7962$oxY4.4420@fx09.iad> |
| In reply to | #401174 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> 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?
>>
>> The SATA hardware register is defined as a 32-bit register in the
>> SATA specification. Therefore we explicitly declare it as such.
>
>I understand the motivation for using uint32_t for the union member
>u. My question is only about the type used for the bitfields. Do
>you know of any platform, or even suspect that there might be a
>platform, where using 'unsigned' rather than 'uint32_t' for the type
>of the bitfields makes any difference at all?
I haven't canvassed all the available platforms, and don't have
any desire so to do. In my opinion, using the same type for the
bitfield members as was used for the corresponding union
element is simply logical. If we declare the integer part
of the union as uint64_t, we use the same time for the
bitfields (and yes, we could have used unsigned long
(or unsigned long long on the micky OS) - uint64_t
is less typing.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-08-15 22:13 +0300 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <20260815221303.0000723b@yahoo.com> |
| In reply to | #401190 |
On Fri, 14 Aug 2026 21:42:38 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >scott@slp53.sl.home (Scott Lurndal) writes:
> >
> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>
> >>> 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?
> >>
> >> The SATA hardware register is defined as a 32-bit register in the
> >> SATA specification. Therefore we explicitly declare it as such.
> >
> >I understand the motivation for using uint32_t for the union member
> >u. My question is only about the type used for the bitfields. Do
> >you know of any platform, or even suspect that there might be a
> >platform, where using 'unsigned' rather than 'uint32_t' for the type
> >of the bitfields makes any difference at all?
>
> I haven't canvassed all the available platforms, and don't have
> any desire so to do. In my opinion, using the same type for the
> bitfield members as was used for the corresponding union
> element is simply logical. If we declare the integer part
> of the union as uint64_t, we use the same time for the
> bitfields (and yes, we could have used unsigned long
> (or unsigned long long on the micky OS) - uint64_t
> is less typing.
>
Why not plain 'unsigned' ?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-15 19:39 +0000 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <eg3gS.10105$nSae.4424@fx47.iad> |
| In reply to | #401217 |
Michael S <already5chosen@yahoo.com> writes:
>On Fri, 14 Aug 2026 21:42:38 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> >scott@slp53.sl.home (Scott Lurndal) writes:
>> >
>> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> >>
>> >>> 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?
>> >>
>> >> The SATA hardware register is defined as a 32-bit register in the
>> >> SATA specification. Therefore we explicitly declare it as such.
>> >
>> >I understand the motivation for using uint32_t for the union member
>> >u. My question is only about the type used for the bitfields. Do
>> >you know of any platform, or even suspect that there might be a
>> >platform, where using 'unsigned' rather than 'uint32_t' for the type
>> >of the bitfields makes any difference at all?
>>
>> I haven't canvassed all the available platforms, and don't have
>> any desire so to do. In my opinion, using the same type for the
>> bitfield members as was used for the corresponding union
>> element is simply logical. If we declare the integer part
>> of the union as uint64_t, we use the same time for the
>> bitfields (and yes, we could have used unsigned long
>> (or unsigned long long on the micky OS) - uint64_t
>> is less typing.
>>
>
>Why not plain 'unsigned' ?
>
Did you not read the paragraph you are responding to?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-08-15 23:22 +0300 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <20260815232215.00006cf8@yahoo.com> |
| In reply to | #401218 |
On Sat, 15 Aug 2026 19:39:54 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
> Michael S <already5chosen@yahoo.com> writes:
> >On Fri, 14 Aug 2026 21:42:38 GMT
> >scott@slp53.sl.home (Scott Lurndal) wrote:
> >
> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >> >scott@slp53.sl.home (Scott Lurndal) writes:
> >> >
> >> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >> >>
> >> >>> 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?
> >> >>
> >> >> The SATA hardware register is defined as a 32-bit register in
> >> >> the SATA specification. Therefore we explicitly declare it as
> >> >> such.
> >> >
> >> >I understand the motivation for using uint32_t for the union
> >> >member u. My question is only about the type used for the
> >> >bitfields. Do you know of any platform, or even suspect that
> >> >there might be a platform, where using 'unsigned' rather than
> >> >'uint32_t' for the type of the bitfields makes any difference at
> >> >all?
> >>
> >> I haven't canvassed all the available platforms, and don't have
> >> any desire so to do. In my opinion, using the same type for the
> >> bitfield members as was used for the corresponding union
> >> element is simply logical. If we declare the integer part
> >> of the union as uint64_t, we use the same time for the
> >> bitfields (and yes, we could have used unsigned long
> >> (or unsigned long long on the micky OS) - uint64_t
> >> is less typing.
> >>
> >
> >Why not plain 'unsigned' ?
> >
>
> Did you not read the paragraph you are responding to?
I missed the part about "using the same type". Sorry.
Now, when I read it ... no, I don't think that it is logical.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-16 14:38 +0000 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <PXjgS.6807$Z7Ef.13@fx46.iad> |
| In reply to | #401221 |
Michael S <already5chosen@yahoo.com> writes:
>On Sat, 15 Aug 2026 19:39:54 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>> >On Fri, 14 Aug 2026 21:42:38 GMT
>> >scott@slp53.sl.home (Scott Lurndal) wrote:
>> >
>> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> >> >scott@slp53.sl.home (Scott Lurndal) writes:
>> >> >
>> >> >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> >> >>
>> >> >>> 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?
>> >> >>
>> >> >> The SATA hardware register is defined as a 32-bit register in
>> >> >> the SATA specification. Therefore we explicitly declare it as
>> >> >> such.
>> >> >
>> >> >I understand the motivation for using uint32_t for the union
>> >> >member u. My question is only about the type used for the
>> >> >bitfields. Do you know of any platform, or even suspect that
>> >> >there might be a platform, where using 'unsigned' rather than
>> >> >'uint32_t' for the type of the bitfields makes any difference at
>> >> >all?
>> >>
>> >> I haven't canvassed all the available platforms, and don't have
>> >> any desire so to do. In my opinion, using the same type for the
>> >> bitfield members as was used for the corresponding union
>> >> element is simply logical. If we declare the integer part
>> >> of the union as uint64_t, we use the same time for the
>> >> bitfields (and yes, we could have used unsigned long
>> >> (or unsigned long long on the micky OS) - uint64_t
>> >> is less typing.
>> >>
>> >
>> >Why not plain 'unsigned' ?
>> >
>>
>> Did you not read the paragraph you are responding to?
>
>I missed the part about "using the same type". Sorry.
>Now, when I read it ... no, I don't think that it is logical.
>
Using unsigned for the bitfields wouldn't work properly
if the modeled register is 64 bits and any of the fields
are more than 32 bits in size.
I've never liked using unadorned 'unsigned' in C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-16 16:11 -0700 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <115tg3g$hmg2$1@kst.eternal-september.org> |
| In reply to | #401230 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Michael S <already5chosen@yahoo.com> writes:
>>On Sat, 15 Aug 2026 19:39:54 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>> Michael S <already5chosen@yahoo.com> writes:
[...]
>>> >Why not plain 'unsigned' ?
>>>
>>> Did you not read the paragraph you are responding to?
>>
>>I missed the part about "using the same type". Sorry.
>>Now, when I read it ... no, I don't think that it is logical.
>
> Using unsigned for the bitfields wouldn't work properly
> if the modeled register is 64 bits and any of the fields
> are more than 32 bits in size.
If you need a bitfield wider than the width of int, of course you
have to use some implementation-defined type. There's no way to
do that portably unless you have C23. (C23 requires support for
bit-fields of bit-precise integer types, so up to at least 64 bits,
but still doesn't require support for bit-fields of type unsigned
long.)
> I've never liked using unadorned 'unsigned' in C.
I think that by "plain 'unsigned'", Michael was referring to the type,
not necessarily to how it's named. ("unsigned", "unsigned int", and
"int unsigned" are all the same type.)
--
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-15 16:16 -0700 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <868q673rft.fsf@linuxsc.com> |
| In reply to | #401190 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> 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?
>>>
>>> The SATA hardware register is defined as a 32-bit register in the
>>> SATA specification. Therefore we explicitly declare it as such.
>>
>> I understand the motivation for using uint32_t for the union member
>> u. My question is only about the type used for the bitfields. Do
>> you know of any platform, or even suspect that there might be a
>> platform, where using 'unsigned' rather than 'uint32_t' for the type
>> of the bitfields makes any difference at all?
>
> I haven't canvassed all the available platforms, and don't have
> any desire so to do. In my opinion, using the same type for the
> bitfield members as was used for the corresponding union
> element is simply logical. If we declare the integer part
> of the union as uint64_t, we use the same time for the
> bitfields (and yes, we could have used unsigned long
> (or unsigned long long on the micky OS) - uint64_t
> is less typing.
To me it seems more logical to use the smallest basic type that
suffices for the width of the associated bit-field, assuming
the compiler allows it, or 'unsigned' for compilers that don't
provide those extensions.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-08-18 20:34 +0000 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <1162fle$3a9$1@reader1.panix.com> |
| In reply to | #401224 |
In article <868q673rft.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> 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?
>>>>
>>>> The SATA hardware register is defined as a 32-bit register in the
>>>> SATA specification. Therefore we explicitly declare it as such.
>>>
>>> I understand the motivation for using uint32_t for the union member
>>> u. My question is only about the type used for the bitfields. Do
>>> you know of any platform, or even suspect that there might be a
>>> platform, where using 'unsigned' rather than 'uint32_t' for the type
>>> of the bitfields makes any difference at all?
>>
>> I haven't canvassed all the available platforms, and don't have
>> any desire so to do. In my opinion, using the same type for the
>> bitfield members as was used for the corresponding union
>> element is simply logical. If we declare the integer part
>> of the union as uint64_t, we use the same time for the
>> bitfields (and yes, we could have used unsigned long
>> (or unsigned long long on the micky OS) - uint64_t
>> is less typing.
>
>To me it seems more logical to use the smallest basic type that
>suffices for the width of the associated bit-field, assuming
>the compiler allows it, or 'unsigned' for compilers that don't
>provide those extensions.
You do not appear to actually write software that interfaces
directly with hardware in the manner that Scott and I (among
others) do.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-08-19 19:57 +0000 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <11651rc$19gjl$2@paganini.bofh.team> |
| In reply to | #401224 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> 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?
>>>>
>>>> The SATA hardware register is defined as a 32-bit register in the
>>>> SATA specification. Therefore we explicitly declare it as such.
>>>
>>> I understand the motivation for using uint32_t for the union member
>>> u. My question is only about the type used for the bitfields. Do
>>> you know of any platform, or even suspect that there might be a
>>> platform, where using 'unsigned' rather than 'uint32_t' for the type
>>> of the bitfields makes any difference at all?
>>
>> I haven't canvassed all the available platforms, and don't have
>> any desire so to do. In my opinion, using the same type for the
>> bitfield members as was used for the corresponding union
>> element is simply logical. If we declare the integer part
>> of the union as uint64_t, we use the same time for the
>> bitfields (and yes, we could have used unsigned long
>> (or unsigned long long on the micky OS) - uint64_t
>> is less typing.
>
> To me it seems more logical to use the smallest basic type that
> suffices for the width of the associated bit-field, assuming
> the compiler allows it, or 'unsigned' for compilers that don't
> provide those extensions.
Conider the following two structs:
typedef struct {char a:5; char b:5; char c:5;} bf1;
typedef struct {short a:5; short b:5; short c:5;} bf2;
gcc allocates 3 bytes to first one and 2 bytes for the second one.
Bitfields are frequently used to converve memory and the second
one is better in this aspect. So it is hard the avoid notion
of storage unit and using type to control size of storage unit.
Of course, if you can not count on compiler behaving in specific
way, abd you can not tolerate different behaviour, then it is better
to use access if given needed size and masks and shifts to access
the bits.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 17:31 -0700 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <864igu52jb.fsf@linuxsc.com> |
| In reply to | #401190 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> 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?
>>>
>>> The SATA hardware register is defined as a 32-bit register in the
>>> SATA specification. Therefore we explicitly declare it as such.
>>
>> I understand the motivation for using uint32_t for the union member
>> u. My question is only about the type used for the bitfields. Do
>> you know of any platform, or even suspect that there might be a
>> platform, where using 'unsigned' rather than 'uint32_t' for the type
>> of the bitfields makes any difference at all?
>
> I haven't canvassed all the available platforms, and don't have
> any desire so to do. In my opinion, using the same type for the
> bitfield members as was used for the corresponding union
> element is simply logical. If we declare the integer part
> of the union as uint64_t, we use the same time for the
> bitfields (and yes, we could have used unsigned long
> (or unsigned long long on the micky OS) - uint64_t
> is less typing.
Out of curiosity I put together a short program to explore how
bit-field types are understood by the compiler. Here is the
program:
#include <stdio.h>
#include <stdint.h>
typedef struct {
_Bool ub : 1;
unsigned char uc : 8;
unsigned short us :16;
unsigned int ui :32;
unsigned long ul :64;
unsigned long long ull :64;
uint8_t u1 : 1;
uint8_t u8 : 8;
uint16_t u16 :16;
uint32_t u32 :32;
uint64_t u64 :64;
uint64_t x1 : 1;
uint64_t x8 : 8;
uint64_t x16 :16;
uint64_t x32 :32;
uint64_t x64 :64;
} Bitfields;
#define whatkind(e) ( \
_Generic( e, \
_Bool : "_Bool", \
unsigned char : "unsigned char", \
unsigned short : "unsigned short", \
unsigned int : "unsigned int", \
unsigned long : "unsigned long", \
unsigned long long : "unsigned long long", \
default : "<something else>" \
) \
)
int
main(){
Bitfields bf;
printf( " whatkind( bf.ub ) is %s\n", whatkind( bf.ub ) );
printf( " whatkind( bf.uc ) is %s\n", whatkind( bf.uc ) );
printf( " whatkind( bf.us ) is %s\n", whatkind( bf.us ) );
printf( " whatkind( bf.ui ) is %s\n", whatkind( bf.ui ) );
printf( " whatkind( bf.ul ) is %s\n", whatkind( bf.ul ) );
printf( " whatkind( bf.ull ) is %s\n", whatkind( bf.ull ) );
printf( "\n" );
printf( " whatkind( bf.u1 ) is %s\n", whatkind( bf.u1 ) );
printf( " whatkind( bf.u8 ) is %s\n", whatkind( bf.u8 ) );
printf( " whatkind( bf.u16 ) is %s\n", whatkind( bf.u16 ) );
printf( " whatkind( bf.u32 ) is %s\n", whatkind( bf.u32 ) );
printf( " whatkind( bf.u64 ) is %s\n", whatkind( bf.u64 ) );
printf( "\n" );
printf( " whatkind( bf.x1 ) is %s\n", whatkind( bf.x1 ) );
printf( " whatkind( bf.x8 ) is %s\n", whatkind( bf.x8 ) );
printf( " whatkind( bf.x16 ) is %s\n", whatkind( bf.x16 ) );
printf( " whatkind( bf.x32 ) is %s\n", whatkind( bf.x32 ) );
printf( " whatkind( bf.x64 ) is %s\n", whatkind( bf.x64 ) );
}
and the output (using gcc)
whatkind( bf.ub ) is _Bool
whatkind( bf.uc ) is unsigned char
whatkind( bf.us ) is unsigned short
whatkind( bf.ui ) is unsigned int
whatkind( bf.ul ) is unsigned long
whatkind( bf.ull ) is unsigned long long
whatkind( bf.u1 ) is <something else>
whatkind( bf.u8 ) is unsigned char
whatkind( bf.u16 ) is unsigned short
whatkind( bf.u32 ) is unsigned int
whatkind( bf.u64 ) is unsigned long
whatkind( bf.x1 ) is <something else>
whatkind( bf.x8 ) is unsigned char
whatkind( bf.x16 ) is unsigned short
whatkind( bf.x32 ) is unsigned int
whatkind( bf.x64 ) is unsigned long
and the output (using clang)
whatkind( bf.ub ) is _Bool
whatkind( bf.uc ) is unsigned char
whatkind( bf.us ) is unsigned short
whatkind( bf.ui ) is unsigned int
whatkind( bf.ul ) is unsigned long
whatkind( bf.ull ) is unsigned long long
whatkind( bf.u1 ) is unsigned char
whatkind( bf.u8 ) is unsigned char
whatkind( bf.u16 ) is unsigned short
whatkind( bf.u32 ) is unsigned int
whatkind( bf.u64 ) is unsigned long
whatkind( bf.x1 ) is unsigned long
whatkind( bf.x8 ) is unsigned long
whatkind( bf.x16 ) is unsigned long
whatkind( bf.x32 ) is unsigned long
whatkind( bf.x64 ) is unsigned long
which serves to reinforce my view that bit-field types should be
chosen from the basic types, and should be the narrowest type that
covers the width of the corresponding bit-field member (with
possible adjustment for widths that match two types, as for example
unsigned long and unsigned long long).
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-20 04:51 +0800 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <rHohS.1224206$yWz9.765340@fx04.ams4> |
| In reply to | #400174 |
On 22/06/2026 5:13 AM, Tim Rentsch wrote: > > 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? As long as both /unsigned/ and /uint32_t/ are of the same /bit width/. In DOS, you can find /unsigned/ to be 16bits and not 32bits. And in the future, I'm sure someone here in comp.lang.c, or maybe comp.arch, will make a computer with /unsigned/ as 64bits. So, it really depends on whether you want to account for the past and the future, or if you're only coding in the present; plus of course visual aesthetics, because some people find uint32_t ugly. -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-04 03:58 -0700 |
| Message-ID | <861pemd12c.fsf@linuxsc.com> |
| In reply to | #399592 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[discussing how to produce a 32-bit color value from rgb16]
> 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.
I would choose a different approach, for two reasons. One is that,
for code that is likely to be in a header file, my preference is
that it be compilable under C90 rules if possible. The other is
that, given the simple nature of the transformation, it should be
able to produce a constant expression if given a constant input
value. Here is an possible implementation:
#define SOLID_RGB24_of_RGB16( rgb16 ) \
ARGB32_( 255ul, \
SCALE_5_to_8_( BITS_AT_OF_( 5, 11, (rgb16) ) ), \
SCALE_6_to_8_( BITS_AT_OF_( 6, 5, (rgb16) ) ), \
SCALE_5_to_8_( BITS_AT_OF_( 5, 0, (rgb16) ) ) \
)
#define ARGB32_( alpha, red, green, blue ) ( \
alpha << 24 | red << 16 | green << 8 | blue \
)
#define SCALE_5_to_8_( u ) ( u *527ul +23 >>6 )
#define SCALE_6_to_8_( u ) ( u *259ul +33 >>6 )
#define BITS_AT_OF_(width,where,u) ( u >> where & (1ul << width)-1 )
And here is a simple test driver:
const unsigned long some_red = SOLID_RGB24_of_RGB16( 29u << 11 );
const unsigned long some_green = SOLID_RGB24_of_RGB16( 59u << 5 );
const unsigned long some_blue = SOLID_RGB24_of_RGB16( 29u << 0 );
#include <stdio.h>
int
main(){
printf( " red: %#8lx\n", some_red );
printf( " green: %#8lx\n", some_green );
printf( " blue: %#8lx\n", some_blue );
}
[toc] | [prev] | [next] | [standalone]
| From | dave_thompson_2@comcast.net |
|---|---|
| Date | 2026-06-06 19:02 -0400 |
| Message-ID | <ll992l5j9vpi1ft977hfhl0qpmeuo8chro@4ax.com> |
| In reply to | #399582 |
On Mon, 1 Jun 2026 09:52:08 +0200, David Brown <david.brown@hesbynett.no> wrote: > On 31/05/2026 19:11, Bart wrote: ... > > Actual examples of too many parentheses? > > Any source code written in LISP :-) > > (And for too few parentheses, any source code in Forth.) > FORTH uses parentheses for stack diagrams -- a semi-standard type of comment/documentation -- and of course good code (using my subjective definition of good :-) ) always has sufficient documentation :-)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-31 19:11 +0000 |
| Message-ID | <10vi15t$ovl$1@reader1.panix.com> |
| In reply to | #399538 |
In article <10vemqf$r5qe$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 30/05/2026 13:29, Dan Cross wrote: >> In article <10vd1tu$ekvl$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>> On 29/05/2026 21:56, Keith Thompson wrote: >>>> [snip] >>>> Upthread, you asked a question: >>>> >>>> And then the point becomes, if you always add the parentheses, what >>>> was the point of having that particular precedence level? >>>> >>>> You've made it clear that you were never interested in an answer. >>> >>> You said this: >>> >>> "You're asking why C is designed the way it is. We could waste a >>> great deal of time and effort answering that for you. There are >>> numerous documents about the design and history of C, and of >>> its ancestor languages. I could provide you with links." >>> >>> Actually I'm not asking why C is like that. We're already there. >>> >>> I'm saying that there is no value in those extra levels, some people >>> think is, and I'm arging about that. I was replying to tTh. >>> >>> As for my question, what /is/ the point? I'm still waiting! >> >> To clarify: the question is, what is the point of those levels? >> >> How is that different from asking "why C is like that"? > >My question is actually independent of C or its history. > >I accept those levels exist. I was asking do they currently serve a >useful purpose. That is a distinction without a difference: I do not see how the two can be separated from one another. The useful purpose the C rules serve is allowing existing code to compile unmodified; the reason that existing code was written that way is because that's how the language was defined; the language was defined that way due to the aforementioned history. >If not, people can choose to ignore those them when writing C code, for >example like this where all () are technically superfluous: > > crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)]; > >And they can choose to not adopt them when devising new languages, >however many still do faithfully recreate the same pattern, with a few >notable exceptions such as Go lang. Languages should, presumably, do what makes sense for them. Lots of languages echo parts of C's syntax where that has proven to be convenient and popular; curly braces for grouping might be an example there. Others have not, or have purposely discarded parts of C syntax that have proven awkward or unpopular. An example there might be the variable declaration syntax, or the structure of `typedef`. I can't think of many languages that keep the exact same parsing rules with respect to operator precedence. You mentioned Go; neither Rust nor Zig follow C's rules, either. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-31 16:08 -0700 |
| Message-ID | <86ldczdvor.fsf@linuxsc.com> |
| In reply to | #399536 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In [...] early C, `|` and `&` were logical operators. The > short-circuiting `||` and `&&` came later, but the usage low > precedence for `|` and `&` was already baked in. > > That's the point: the precedence reflects the original use as > boolean operators, not how things evolved for use almost purely > as bitwise operators. Surely even in pre-K&R C the & and | operators were used for bitwise-and and bitwise-or as well as logical connectors.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-31 16:32 -0700 |
| Message-ID | <10vige1$1r8io$2@kst.eternal-september.org> |
| In reply to | #399570 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In [...] early C, `|` and `&` were logical operators. The
>> short-circuiting `||` and `&&` came later, but the usage low
>> precedence for `|` and `&` was already baked in.
>>
>> That's the point: the precedence reflects the original use as
>> boolean operators, not how things evolved for use almost purely
>> as bitwise operators.
>
> Surely even in pre-K&R C the & and | operators were used for
> bitwise-and and bitwise-or as well as logical connectors.
They were used for both (and that was the problem).
The "original use" being referred to is in BCPL and B, and in *very*
early C.
Reference:
https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.pdf
Neonatal C
Rapid changes continued after the language had been named,
for example the introduction of the && and || operators. In
BCPL and B, the evaluation of expressions depends on context:
within if and other conditional statements that compare an
expression’s value with zero, these languages place a special
interpretation on the and (&) and or (|) operators. In ordinary
contexts, they operate bitwise, but in the B statement
if (e1 & e2) ...
the compiler must evaluate e1 and if it is non-zero, evaluate e2,
and if it too is non-zero, elaborate the statement dependent on
the if. The requirement descends recursively on & and | operators
within e1 and e2. The short-circuit semantics of the Boolean
operators in such ‘truth-value’ context seemed desirable,
but the overloading of the operators was difficult to explain
and use. At the suggestion of Alan Snyder, I introduced the &&
and || operators to make the mechanism more explicit.
Their tardy introduction explains an infelicity of C’s
precedence rules. In B one writes
if (a==b & c) ...
to check whether a equals b and c is non-zero; in such a
conditional expression it is better that & have lower precedence
than ==. In converting from B to C, one wants to replace & by
&& in such a statement; to make the conversion less painful,
we decided to keep the precedence of the & operator the same
relative to ==, and merely split the precedence of && slightly
from &. Today, it seems that it would have been preferable to
move the relative precedences of & and ==, and thereby simplify
a common C idiom: to test a masked value against another value,
one must write
if ((a&mask) == b) ...
where the inner parentheses are required but easily forgotten.
--
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]
Page 22 of 24 — ← Prev page 1 … 20 21 [22] 23 24 Next page →
Back to top | Article view | comp.lang.c
csiph-web