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 21 of 24 — ← Prev page 1 … 19 20 [21] 22 23 24 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 16:10 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <86cxvj3rq1.fsf@linuxsc.com> |
| In reply to | #401192 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>> [...]
>>>
>>>>>> It would make a lot more sense *to me* if an N-bit bit field were
>>>>>> simply N bits.
>>>
>>> [...]
>
> <snip>
>
>>> I had gotten the impression that the behavior is imposed by ABIs,
>>> but my copy of the "System V Application Binary Interface AMD64
>>> Architecture Processor Supplement" just says:
>>>
>>> - bit-fields are allocated from right to left
>>
>> I think that means they are allocated in order of low-to-high,
>> because the AMD64 architecture is little-endian.
>>
>>> - bit-fields must be contained in a storage unit appropriate for
>>> its declared type
>>> - bit-fields may share a storage unit with other struct / union
>>> members
>>>
>>> which doesn't seem to be enough to specify the behavior I see
>>> (and I find it annoyingly vague).
>>>
>>> Is there a document (ABI, compiler document, whatever) that specifies
>>> the (odd, to me) behavior I'm seeing?
>>
>> As best I can tell the layout you are seeing is consistent with
>> the rules stated above. Perhaps the rules are deliberately meant
>> to be an under-specification (which IMO is not a bad thing).
>>
>>> Here's a test program:
>>>
>>> #include <stdio.h>
>>> #include <stddef.h>
>>> int main(void) {
>>> struct s1 { unsigned char bf:1; unsigned char c; };
>>> struct s2 { unsigned short bf:1; unsigned char c; };
>>> struct s3 { unsigned int bf:1; unsigned char c; };
>>> struct s4 { unsigned long bf:1; unsigned char c; };
>>> struct s5 { unsigned long long bf:1; unsigned char c; };
>
> FWIW, adding GCC's __attribute__((packed)) to each of those, we see:
>
>> type size offset struct-size
>> unsigned char 1 1 2
>> unsigned short 2 1 2
>> unsigned int 4 1 4
>> unsigned long 8 1 8
>> unsigned long long 8 1 8
>
> type size offset struct-size
> unsigned char 1 1 2
> unsigned short 2 1 2
> unsigned int 4 1 2
> unsigned long 8 1 2
> unsigned long long 8 1 2
>
> Which doesn't seem to violate the ABI rules you quoted.
That's good to know I guess, although I'm not sure what it
tells me. My impression is that using attribute__((packed))
produces code that may be less portable than not using it.
Generally I try to write code that avoids compiler-specific
constructs whenever feasible.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-16 15:20 +0000 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <jzkgS.4883$4QJ.2251@fx21.iad> |
| In reply to | #401223 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Here's a test program:
>>>>
>>>> #include <stdio.h>
>>>> #include <stddef.h>
>>>> int main(void) {
>>>> struct s1 { unsigned char bf:1; unsigned char c; };
>>>> struct s2 { unsigned short bf:1; unsigned char c; };
>>>> struct s3 { unsigned int bf:1; unsigned char c; };
>>>> struct s4 { unsigned long bf:1; unsigned char c; };
>>>> struct s5 { unsigned long long bf:1; unsigned char c; };
>>
>> FWIW, adding GCC's __attribute__((packed)) to each of those, we see:
>>
>>> type size offset struct-size
>>> unsigned char 1 1 2
>>> unsigned short 2 1 2
>>> unsigned int 4 1 4
>>> unsigned long 8 1 8
>>> unsigned long long 8 1 8
>>
>> type size offset struct-size
>> unsigned char 1 1 2
>> unsigned short 2 1 2
>> unsigned int 4 1 2
>> unsigned long 8 1 2
>> unsigned long long 8 1 2
>>
>> Which doesn't seem to violate the ABI rules you quoted.
>
>That's good to know I guess, although I'm not sure what it
>tells me. My impression is that using attribute__((packed))
>produces code that may be less portable than not using it.
>Generally I try to write code that avoids compiler-specific
>constructs whenever feasible.
I generally only use the packed attribute when creating
a C struct to match a hardware register, data structure or
data packet.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-08-19 19:34 +0000 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <11650g9$19gjl$1@paganini.bofh.team> |
| In reply to | #400280 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
<snip>
> One possible approach would be to use the declared type only to
> determine the signedness of the bit-field (and its conversion
> behavior in the case of bool), and the upper bound for the number
> of bits (`int bf:33` is a constraint violation if int is 32 bits).
> In this relatively simple approach, there's no point in defining
> a bit-field with one of the char or short types.
>
> Using gcc on Linux, if I define a 1-bit bit-field with a 64-bit type,
> that forces the containing structure to be at least 64 bits -- but
> not by reserving a 64-bit region to hold the bit-field. If I define
> a struct containing a 1-bit unsigned long long bit-field followed by
> a 1-byte ordinary member, the second member is at a 1-bytes offset.
>
> I had gotten the impression that the behavior is imposed by ABIs,
> but my copy of the "System V Application Binary Interface AMD64
> Architecture Processor Supplement" just says:
>
> - bit-fields are allocated from right to left
> - bit-fields must be contained in a storage unit appropriate for
> its declared type
> - bit-fields may share a storage unit with other struct / union
> members
>
> which doesn't seem to be enough to specify the behavior I see
> (and I find it annoyingly vague).
>
> Is there a document (ABI, compiler document, whatever) that specifies
> the (odd, to me) behavior I'm seeing?
>
> Here's a test program:
<snip>
> and its output on my system (Ubuntu, x86_64):
>
> type size offset struct-size
> unsigned char 1 1 2
> unsigned short 2 1 2
> unsigned int 4 1 4
> unsigned long 8 1 8
> unsigned long long 8 1 8
>
> Again, the declared type of a bit-field doesn't affect how the
> bit-field itself is allocated, but it does affect the size of the
> containing struct, but it doesn't prevent other members from being
> allocated within that space.
I leave it to language and standard lawyers to discuss if such
behaviour is mandated, but I find results of the test program
obvious given how gcc behaves is general. First, IIUC given
bit field should be at fixed bit offset within its storage unit.
Second, storage units are allocated at byte addresses with
appropriate alignment. Third, the passage above says that
storage unit must be approptiate for its type, so 1 byte in
case of unsigned char, 2 bytes in case of unsigend short,
4 bytes in case of unsigned int, 8 bytes in case of unsignend
long. Together, size of storage unit, its alignment and
fixed bit offset of bit field within storage unit determines
mininal size of structure needed to hold the bitfield.
When this size is bigger then 1, then there is enough space
within the storage unit to place the extra character there.
When type is unsigned char, then size is 1 and there are
no space to have bit field and char withing a single storage
unit, so second one is allocated giving total size of the
struct as 2. So in each case we get the struct size above.
Other post mentioned gcc "packed". gcc "packed" does not
respect alignment rules, so in such cases 2 byte are enough
regardless of type.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-19 15:26 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <1165ai6$314h2$2@kst.eternal-september.org> |
| In reply to | #401331 |
antispam@fricas.org (Waldek Hebisch) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> I had gotten the impression that the behavior is imposed by ABIs,
>> but my copy of the "System V Application Binary Interface AMD64
>> Architecture Processor Supplement" just says:
>>
>> - bit-fields are allocated from right to left
>> - bit-fields must be contained in a storage unit appropriate for
>> its declared type
>> - bit-fields may share a storage unit with other struct / union
>> members
>>
>> which doesn't seem to be enough to specify the behavior I see
>> (and I find it annoyingly vague).
>>
>> Is there a document (ABI, compiler document, whatever) that specifies
>> the (odd, to me) behavior I'm seeing?
[...]
> I leave it to language and standard lawyers to discuss if such
> behaviour is mandated, but I find results of the test program
> obvious given how gcc behaves is general. First, IIUC given
> bit field should be at fixed bit offset within its storage unit.
> Second, storage units are allocated at byte addresses with
> appropriate alignment. Third, the passage above says that
> storage unit must be approptiate for its type, so 1 byte in
> case of unsigned char, 2 bytes in case of unsigend short,
> 4 bytes in case of unsigned int, 8 bytes in case of unsignend
> long.
Thank you, that's the point I had overlooked (even though I
quoted it).
The ABI document's statement that "bit-fields must be contained in
a storage unit appropriate for its declared type", can reasonably
be read to mean that an unsigned char bit-field is contained in a
1-byte storage unit, and an unsigned long long bit-field is contained
in an 8-byte storage unit (given that unsigned long long is 8 bytes).
I still find the language vague (and ungrammatical). What exactly
does "appropriate" mean? Could an implementation decide that a
32-bit storage unit is "appropriate" for an unsigned short bit-field?
Presumably not, since that would break binary compatibility, but
I don't see that it would violate the wording of the ABI.
The C standard's language is also vague, but it's not trying to
require binary compatibility.
An implementation may allocate any addressable storage unit
large enough to hold a bit-field. If enough space remains,
a bit-field that immediately follows another bit-field in a
structure shall be packed into adjacent bits of the same unit.
[...]
> Other post mentioned gcc "packed". gcc "packed" does not
> respect alignment rules, so in such cases 2 byte are enough
> regardless of type.
gcc "packed" can also cause quiet crashes on some systems. It can
result in, for example, an int member being allocated at an odd address.
Passing the address of such a member to a function that assumes the
pointed-to object is correctly aligned can result in Bad Things
Happening. (On x86, as I understand it, misaligned accesses
are merely somewhat slower than aligned accesses.)
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628>
<https://stackoverflow.com/q/8568432/827263>
<https://stackoverflow.com/a/8568441/827263>
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-20 11:00 +0200 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <1166fo6$3blln$1@dont-email.me> |
| In reply to | #401341 |
On 20/08/2026 00:26, Keith Thompson wrote: > antispam@fricas.org (Waldek Hebisch) writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: [...] >> Other post mentioned gcc "packed". gcc "packed" does not >> respect alignment rules, so in such cases 2 byte are enough >> regardless of type. > > gcc "packed" can also cause quiet crashes on some systems. It can > result in, for example, an int member being allocated at an odd address. > Passing the address of such a member to a function that assumes the > pointed-to object is correctly aligned can result in Bad Things > Happening. (On x86, as I understand it, misaligned accesses > are merely somewhat slower than aligned accesses.) > > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628> > <https://stackoverflow.com/q/8568432/827263> > <https://stackoverflow.com/a/8568441/827263> > gcc "packed" can cause problems only if you don't use the compiler correctly (or if there are bugs in the compiler, as happens occasionally. gcc's bugzilla seems to be having trouble, so I have not checked your bug link). As you say, "packed" means that struct fields can be misaligned. This has two potential problems. One is that if you take the address of a field, you then have a pointer whose value is invalid for dereferencing as that type - so dereferencing it is UB. (You can still convert it to a character pointer and dereference that.) A compiler could therefore assume that if you have "int * p;" and you dereference it, then "p" must be correctly aligned. AFAIUI gcc does not make such assumptions, precisely because misaligned pointers do turn up in some code (either from the use of "packed" or by other means), and it is not an optimisation that is likely to be useful in any but the most obscure niche cases. (And if you have code in that category, you can always use __builtin_assume_aligned() to give the compiler the additional information.) The real problem with misaligned data is that on some systems, accessing misaligned data is not supported by the hardware. Such hardware certainly exists. From the links you gave, it appears to apply to SPARCs. It certainly applies to some of the smaller and cheaper ARM Cortex-M cores (M0, M1, M23 - perhaps more). And even on bigger devices, there can particular instructions that require correct alignment, such as "move multiple registers" or "load/store double register". In the x86 world, I believe there are some SIMD load/store instructions that must use aligned addresses. For most processors, and most instructions, misaligned accesses work but are a little slower than aligned accesses. If a misaligned access is not supported, the effects vary by device. Some will trigger a hardware fault and a program crash. Some will have a hardware fault and then software emulation of the misaligned access - then it will "work", but be /massively/ slower. And for some you simply get the wrong access - your program silently does the wrong thing. (On the msp430, trying to access a 16-bit value at an odd address had - in my brief testing long ago - the effect of accessing the data at one bye lower address but with swapped endianness. This is not a documented effect, however, so not something to rely on.) gcc is smart enough to use smaller accesses when it knows it is necessary. Accessing a misaligned 32-bit field when targeting a Cortex-M4 will give normal load/store 32-bit instructions - when targeting an M23, it will generate multiple 8-bit or 16-bit load/stores. And if you take a pointer to a packed field, you get a warning. So I think you have to put a bit of effort into getting in trouble here - you have to use pointers and ignore warnings, or use inappropriate command-line switches or generate code targeting one processor and try to run it on a different processor.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-20 03:30 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <1166l0m$3d0b0$1@kst.eternal-september.org> |
| In reply to | #401347 |
David Brown <david.brown@hesbynett.no> writes:
> On 20/08/2026 00:26, Keith Thompson wrote:
>> antispam@fricas.org (Waldek Hebisch) writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> [...]
>>> Other post mentioned gcc "packed". gcc "packed" does not
>>> respect alignment rules, so in such cases 2 byte are enough
>>> regardless of type.
>> gcc "packed" can also cause quiet crashes on some systems. It can
>> result in, for example, an int member being allocated at an odd address.
>> Passing the address of such a member to a function that assumes the
>> pointed-to object is correctly aligned can result in Bad Things
>> Happening. (On x86, as I understand it, misaligned accesses
>> are merely somewhat slower than aligned accesses.)
>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628>
>> <https://stackoverflow.com/q/8568432/827263>
>> <https://stackoverflow.com/a/8568441/827263>
>
> gcc "packed" can cause problems only if you don't use the compiler
> correctly (or if there are bugs in the compiler, as happens
> occasionally. gcc's bugzilla seems to be having trouble, so I have
> not checked your bug link).
That may be the case now, but it was definitely causing runtime bus
errors on some systems when I reported it. It was later marked as
FIXED.
> As you say, "packed" means that struct fields can be misaligned. This
> has two potential problems.
>
> One is that if you take the address of a field, you then have a
> pointer whose value is invalid for dereferencing as that type - so
> dereferencing it is UB. (You can still convert it to a character
> pointer and dereference that.) A compiler could therefore assume that
> if you have "int * p;" and you dereference it, then "p" must be
> correctly aligned. AFAIUI gcc does not make such assumptions,
> precisely because misaligned pointers do turn up in some code (either
> from the use of "packed" or by other means), and it is not an
> optimisation that is likely to be useful in any but the most obscure
> niche cases. (And if you have code in that category, you can always
> use __builtin_assume_aligned() to give the compiler the additional
> information.)
I'm not sure what assumptions gcc makes now. Once you add something
outside the sco of the standard like `__attribute__((packed))`, the
behavior is arguably undefined anyway. I can't reproduce the original
symptom with a modern gcc, but that may be because I don't have access
to a system that traps on unaligned accesses.
[...]
> gcc is smart enough to use smaller accesses when it knows it is
> necessary. Accessing a misaligned 32-bit field when targeting a
> Cortex-M4 will give normal load/store 32-bit instructions - when
> targeting an M23, it will generate multiple 8-bit or 16-bit
> load/stores. And if you take a pointer to a packed field, you get a
> warning. So I think you have to put a bit of effort into getting in
> trouble here - you have to use pointers and ignore warnings, or use
> inappropriate command-line switches or generate code targeting one
> processor and try to run it on a different processor.
The problem is that if you have a separately compiled function like:
void inc(int *p) {
(*p)++;
}
the compiler has no way to know whether smaller (and perhaps
significantly more expensive) accesses are necessary. Direct access to
a packed member is easy enough, but once you take its address and pass
it somewhere, there's no good way to deal with it.
gcc added a warning option -Waddress-of-packed-member.
I haven't been able to get any code to run on SPARC via godbolt.org.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-20 13:58 +0200 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <1166q5g$3dg4d$2@dont-email.me> |
| In reply to | #401350 |
On 20/08/2026 12:30, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 20/08/2026 00:26, Keith Thompson wrote:
>>> antispam@fricas.org (Waldek Hebisch) writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> [...]
>>>> Other post mentioned gcc "packed". gcc "packed" does not
>>>> respect alignment rules, so in such cases 2 byte are enough
>>>> regardless of type.
>>> gcc "packed" can also cause quiet crashes on some systems. It can
>>> result in, for example, an int member being allocated at an odd address.
>>> Passing the address of such a member to a function that assumes the
>>> pointed-to object is correctly aligned can result in Bad Things
>>> Happening. (On x86, as I understand it, misaligned accesses
>>> are merely somewhat slower than aligned accesses.)
>>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628>
>>> <https://stackoverflow.com/q/8568432/827263>
>>> <https://stackoverflow.com/a/8568441/827263>
>>
>> gcc "packed" can cause problems only if you don't use the compiler
>> correctly (or if there are bugs in the compiler, as happens
>> occasionally. gcc's bugzilla seems to be having trouble, so I have
>> not checked your bug link).
>
> That may be the case now, but it was definitely causing runtime bus
> errors on some systems when I reported it. It was later marked as
> FIXED.
>
As I say, I can't seem to get any response from the gcc bugzilla server,
so I can't look at the link for now. Certainly gcc has bugs, some of
which can be serious.
>> As you say, "packed" means that struct fields can be misaligned. This
>> has two potential problems.
>>
>> One is that if you take the address of a field, you then have a
>> pointer whose value is invalid for dereferencing as that type - so
>> dereferencing it is UB. (You can still convert it to a character
>> pointer and dereference that.) A compiler could therefore assume that
>> if you have "int * p;" and you dereference it, then "p" must be
>> correctly aligned. AFAIUI gcc does not make such assumptions,
>> precisely because misaligned pointers do turn up in some code (either
>> from the use of "packed" or by other means), and it is not an
>> optimisation that is likely to be useful in any but the most obscure
>> niche cases. (And if you have code in that category, you can always
>> use __builtin_assume_aligned() to give the compiler the additional
>> information.)
>
> I'm not sure what assumptions gcc makes now. Once you add something
> outside the sco of the standard like `__attribute__((packed))`, the
> behavior is arguably undefined anyway. I can't reproduce the original
> symptom with a modern gcc, but that may be because I don't have access
> to a system that traps on unaligned accesses.
>
You can use godbolt to generate the code. If you are targetting a
processor that does not support misaligned accesses, it should generate
smaller accesses for misaligned packed data. With the following link,
you can try changing the "-mcpu=cortex-23" to "cortex-m33" and see the
difference in the code.
<https://godbolt.org/z/PqGabdfWG>
If you can make an example where a modern gcc for the target hardware
generates multiple small accesses, and an older version generates a
misaligned big access, then that would probably show the issue even
without access to the hardware.
> [...]
>
>> gcc is smart enough to use smaller accesses when it knows it is
>> necessary. Accessing a misaligned 32-bit field when targeting a
>> Cortex-M4 will give normal load/store 32-bit instructions - when
>> targeting an M23, it will generate multiple 8-bit or 16-bit
>> load/stores. And if you take a pointer to a packed field, you get a
>> warning. So I think you have to put a bit of effort into getting in
>> trouble here - you have to use pointers and ignore warnings, or use
>> inappropriate command-line switches or generate code targeting one
>> processor and try to run it on a different processor.
>
> The problem is that if you have a separately compiled function like:
>
> void inc(int *p) {
> (*p)++;
> }
>
> the compiler has no way to know whether smaller (and perhaps
> significantly more expensive) accesses are necessary. Direct access to
> a packed member is easy enough, but once you take its address and pass
> it somewhere, there's no good way to deal with it.
Yes. The best it can do is warn you when you take the address of the
packed field.
>
> gcc added a warning option -Waddress-of-packed-member.
Exactly. (It was added in gcc 9, as far as I can tell.)
>
> I haven't been able to get any code to run on SPARC via godbolt.org.
>
I could not see incorrect code generated for SPARC gcc, but I am not
very familiar with SPARC assembly, my example code may not have shown
the problem, and godbolt only has back to gcc 12 for the SPARC. So my
own tests are far from conclusive.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-20 13:37 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <1167oir$3ptto$2@kst.eternal-september.org> |
| In reply to | #401355 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> If you can make an example where a modern gcc for the target hardware
> generates multiple small accesses, and an older version generates a
> misaligned big access, then that would probably show the issue even
> without access to the hardware.
Yes, but I lack both the familiarity with the relevant assembly
languages and the patience to do that.
[...]
--
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-20 14:50 +0000 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <RuEhS.43025$KXn4.4683@fx08.iad> |
| In reply to | #401341 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >antispam@fricas.org (Waldek Hebisch) writes: <snip> >> Other post mentioned gcc "packed". gcc "packed" does not >> respect alignment rules, so in such cases 2 byte are enough >> regardless of type. > >gcc "packed" can also cause quiet crashes on some systems. It can >result in, for example, an int member being allocated at an odd address. >Passing the address of such a member to a function that assumes the >pointed-to object is correctly aligned can result in Bad Things >Happening. (On x86, as I understand it, misaligned accesses >are merely somewhat slower than aligned accesses.) In modern systems, so long as the misaligned access is fully contained within a single cache line, there is zero additional latency for the misaligned access.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-20 12:31 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <1167km4$3ordo$1@dont-email.me> |
| In reply to | #401358 |
On 8/20/2026 7:50 AM, Scott Lurndal wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> antispam@fricas.org (Waldek Hebisch) writes: > <snip> >>> Other post mentioned gcc "packed". gcc "packed" does not >>> respect alignment rules, so in such cases 2 byte are enough >>> regardless of type. >> >> gcc "packed" can also cause quiet crashes on some systems. It can >> result in, for example, an int member being allocated at an odd address. >> Passing the address of such a member to a function that assumes the >> pointed-to object is correctly aligned can result in Bad Things >> Happening. (On x86, as I understand it, misaligned accesses >> are merely somewhat slower than aligned accesses.) > > In modern systems, so long as the misaligned access is > fully contained within a single cache line, there is > zero additional latency for the misaligned access. > fully contained within a single cache line, that's step 1. We also need to make sure the cache line is aligned on a cache line boundary.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-08-20 19:55 +0000 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <1167m35$1iosv$1@paganini.bofh.team> |
| In reply to | #401358 |
Scott Lurndal <scott@slp53.sl.home> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>antispam@fricas.org (Waldek Hebisch) writes:
> <snip>
>>> Other post mentioned gcc "packed". gcc "packed" does not
>>> respect alignment rules, so in such cases 2 byte are enough
>>> regardless of type.
>>
>>gcc "packed" can also cause quiet crashes on some systems. It can
>>result in, for example, an int member being allocated at an odd address.
>>Passing the address of such a member to a function that assumes the
>>pointed-to object is correctly aligned can result in Bad Things
>>Happening. (On x86, as I understand it, misaligned accesses
>>are merely somewhat slower than aligned accesses.)
>
> In modern systems, so long as the misaligned access is
> fully contained within a single cache line, there is
> zero additional latency for the misaligned access.
But most efficient access fetches the whole line. If it stays
within a single cache line, then by neccessity it is aligned.
And adjective "modern" can be applied to microcontrollers.
Microcontrollers typically have word-sized data bus. Misaligned
word sized access needs two transfers over data bus, clearly
less efficient than single access.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-08-20 22:15 +0300 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <20260820221531.0000017d@yahoo.com> |
| In reply to | #401341 |
On Wed, 19 Aug 2026 15:26:14 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > > (On x86, as I understand it, misaligned accesses > are merely somewhat slower than aligned accesses.) > On all surviving general-purpose CPUs that I am aware of, not just x86. Not that there are many that survived. May be, some of Chinese general-purpose designs are exception. And in many cases it's not slower. Typically, mis-aligned accesses become slower than aligned only when dozens of such accesses executed in tight sequence.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-14 14:19 -0700 |
| Subject | Re: Storage needed when there are bit-field members |
| Message-ID | <86se4g5riz.fsf@linuxsc.com> |
| In reply to | #400276 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>>> But
>>> uint32_t bf : 1;
>>> is meaningfully different from
>>> unsigned bf : 1;
>>>
>>> only because in most implementations (and ABIs), the underlying type
>>> of a bit field affects the layout of the entire structure.
>
> [...]
>
>>> I accept that this is the case, but it's never made any sense to me,
>>> and there's no hint of it in the C standard.
>>
>> I think saying there is not even a hint is an overstatement. The C
>> standard says that an implementation "may allocate any addressable
>> storage unit large enough to hold a bit-field." It shouldn't be a
>> surprise that how much storage is allocated depends on the type of
>> the bit-field member. For example, a bit-field of type 'unsigned'
>> might very well choose a larger storage unit than what is chosen
>> for a bit-field of type '_Bool'. It seems obvious that the type of
>> a bit-field might affect what size and layout is chosen.
>
> I'm sure it seems obvious to you. As I said, it's not at all
> obvious to me.
>
> Prior to C99, C didn't even require compilers to support bit-field
> types other than int, unsigned int, and signed int.
True, but allowing other types was listed as a common extension.
> The declared
> type might typically be used only to determine the signedness of the
> bit-field (though I *think* most compilers permitted other types).
>
> Implementations are certainly not *required* to use the declared
> type of a bit-field as a factor in deciding how to allocate it,
> or how to allocate the rest of the structure. Allocating just one
> byte for an isolated 1-bit bit-field of any declared type would
> be conforming. A conforming compiler could use the declared type
> only to determine the signedness and the maximum allowed width of
> a bit-field (and its conversion behavior in the case of bool)
Yes, it could.
>>> For example, if I write:
>>> uint64_t bf : 1;
>>>
>>> then the containing struct is typically at least 64 bits, even
>>> though those other 63 bits aren't part of the bit field and other
>>> members can be allocated within them.
>>>
>>> It would make a lot more sense *to me* if an N-bit bit field were
>>> simply N bits.
>>
>> Two problems with that. One, it seems to be in conflict with what
>> the C standard says about 0-width bit-fields.
>
> 0-width bit-fields are obviously a special case.
Sorry for not making my point more clear. My comment is meant to
to raise the question of whether
struct x {
_Bool foo:1;
_Bool :0;
char c;
};
and
struct y {
unsigned foo:1;
_Bool :0;
char c;
};
should be different. I'm inclined to think they should be, by
which I mean my preference is for compilers where they would be.
>> Two, the C standard
>> explicitly allows allocating bit-fields using a high-to-low order
>> or a low-to-high order (implementation-defined choice). Presumably
>> this freedom is given to accommodate both big- and little-endian
>> platforms. The idea that an N-bit bit-field should simply be N
>> bits doesn't work in big-endian environments. It seems better to
>> allow little-endian implementations to choose a size that matches
>> what a big-endian implementation would use, rather than insisting
>> that they be different.
>
> I honestly don't understand your point here. How does making
> N-bit bit-fields N bits not work in a big-endian environment?
> Can you elaborate? Of course endianness can affect how bit-fields
> are allocated within a "storage unit".
Suppose we have a little endian machine where bit-fields are
allocated in a high-to-low order. Further suppose that unsigned
ints are 32 bits. In such an environment, I would expect (or
prefer) a definition like this
struct foo {
unsigned x:15;
};
to be represented like so
-------- -------- -XXXXXXX XXXXXXXX
where the X's indicate where the bit-field goes, and the -'s
indicate where there are padding bits. In such an environment,
I would find it counterintuitive if this type were represented
thus
-XXXXXXX XXXXXXXX
rather than as shown in the previous layout.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-22 10:45 +0000 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <111b3ni$s5m$1@reader1.panix.com> |
| In reply to | #400174 |
In article <86h5mv8umk.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> One might also define data structures for control and status
>> registers using bitfield structs.
>
>Yeah. This kind of application (among others) I consider one of
>the motivating forces behind bitfields.
>
>[Some whitespace trimming done in the excerpt below.]
>
>> e.g. for the SATA UAHC_GLB_OOBR register:
>>
>> union UAHC_GBL_OOBR {
>> uint32_t u;
>> struct UAHC_GBL_OOBR_s {
>> #if __BYTE_ORDER == __BIG_ENDIAN
>> uint32_t we : 1; /**< R/W/H - Write enable. */
>> uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value [...] */
>> uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value [...] */
>> uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value [...] */
>> uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value [...] */
>> #else
>> uint32_t cimax : 8;
>> uint32_t cimin : 8;
>> uint32_t cwmax : 8;
>> uint32_t cwmin : 7;
>> uint32_t we : 1;
>> #endif
>> } s;
>> };
>
>To me it seems kind of goofy to use uint32_t for the bitfields type.
>I would just use unsigned, which is just as sure to work as intended,
>isn't it?
No. There are issues of alignment and padding one must consider
when using bitfields to model hardware registers, particularly
if (say) a device driver is meant to be shared across ISAs.
Using the exact width types really does make a difference; it's
IB what those properties are, though we're usually at the mercy
of the target platform's ABI anyway at that point.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-22 15:23 +0000 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <0sc_R.3744$Zhg2.2911@fx12.iad> |
| In reply to | #400187 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <86h5mv8umk.fsf@linuxsc.com>,
>Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> One might also define data structures for control and status
>>> registers using bitfield structs.
>>
>>Yeah. This kind of application (among others) I consider one of
>>the motivating forces behind bitfields.
>>
>>[Some whitespace trimming done in the excerpt below.]
>>
>>> e.g. for the SATA UAHC_GLB_OOBR register:
>>>
>>> union UAHC_GBL_OOBR {
>>> uint32_t u;
>>> struct UAHC_GBL_OOBR_s {
>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>> uint32_t we : 1; /**< R/W/H - Write enable. */
>>> uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value [...] */
>>> uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value [...] */
>>> uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value [...] */
>>> uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value [...] */
>>> #else
>>> uint32_t cimax : 8;
>>> uint32_t cimin : 8;
>>> uint32_t cwmax : 8;
>>> uint32_t cwmin : 7;
>>> uint32_t we : 1;
>>> #endif
>>> } s;
>>> };
>>
>>To me it seems kind of goofy to use uint32_t for the bitfields type.
>>I would just use unsigned, which is just as sure to work as intended,
>>isn't it?
>
>No. There are issues of alignment and padding one must consider
>when using bitfields to model hardware registers, particularly
>if (say) a device driver is meant to be shared across ISAs.
That's a good choice of verb (model).
As it happens, the primary use of this data structure is not
to handle direct accesses to the hardware registers, but rather
to model them in a simulation. So when the simulated CPU
accesses the register, after determining the target address
is assigned to the SATA controller GBL_OOB register, the
SATA device model code (which hosts the register) will access
the bitfields individually by name when implementing the
semantics of a store to that register by the simulated CPU
(which will typically be running the linux SATA driver).
Far more maintainable and readable than manipulating the bit fields
with shift and mask operations.
e.g.
if (gbl_oobr.s.we) { /* Writes are enabled */
/* do it */
}
is better in all respects than
if (gbl_oobr & 1) /* LE */
or
if (gbl_oobr & (1 << 31)) /* BE */
or even
if (gbl_oobr & (1 << WRITE_ENABLE_BIT_OFFSET))
Of course the data structure can also be used by a real
hardware device driver, with the caveat that the contents
of the hardware register is loaded explicitly into the '.u'
member by the driver before accessing the bitfields.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-14 13:23 -0700 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <861pc078pc.fsf@linuxsc.com> |
| In reply to | #400187 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <86h5mv8umk.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> One might also define data structures for control and status
>>> registers using bitfield structs.
>>
>> Yeah. This kind of application (among others) I consider one of
>> the motivating forces behind bitfields.
>>
>> [Some whitespace trimming done in the excerpt below.]
>>
>>> e.g. for the SATA UAHC_GLB_OOBR register:
>>>
>>> union UAHC_GBL_OOBR {
>>> uint32_t u;
>>> struct UAHC_GBL_OOBR_s {
>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>> uint32_t we : 1; /**< R/W/H - Write enable. */
>>> uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value [...] */
>>> uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value [...] */
>>> uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value [...] */
>>> uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value [...] */
>>> #else
>>> uint32_t cimax : 8;
>>> uint32_t cimin : 8;
>>> uint32_t cwmax : 8;
>>> uint32_t cwmin : 7;
>>> uint32_t we : 1;
>>> #endif
>>> } s;
>>> };
>>
>> To me it seems kind of goofy to use uint32_t for the bitfields type.
>> I would just use unsigned, which is just as sure to work as intended,
>> isn't it?
>
> No. There are issues of alignment and padding one must consider
> when using bitfields to model hardware registers, particularly
> if (say) a device driver is meant to be shared across ISAs.
>
> Using the exact width types really does make a difference; it's
> IB what those properties are, though we're usually at the mercy
> of the target platform's ABI anyway at that point.
The motivation for my query was not to ask an abstract theoretical
question but a specific and pragmatic one.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-08-18 20:32 +0000 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <1162fgr$dv8$1@reader1.panix.com> |
| In reply to | #401177 |
In article <861pc078pc.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <86h5mv8umk.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> One might also define data structures for control and status
>>>> registers using bitfield structs.
>>>
>>> Yeah. This kind of application (among others) I consider one of
>>> the motivating forces behind bitfields.
>>>
>>> [Some whitespace trimming done in the excerpt below.]
>>>
>>>> e.g. for the SATA UAHC_GLB_OOBR register:
>>>>
>>>> union UAHC_GBL_OOBR {
>>>> uint32_t u;
>>>> struct UAHC_GBL_OOBR_s {
>>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>>> uint32_t we : 1; /**< R/W/H - Write enable. */
>>>> uint32_t cwmin : 7; /**< R/W/H - COMWAKE minimum value [...] */
>>>> uint32_t cwmax : 8; /**< R/W/H - COMWAKE maximum value [...] */
>>>> uint32_t cimin : 8; /**< R/W/H - COMINIT minimum value [...] */
>>>> uint32_t cimax : 8; /**< R/W/H - COMINIT maximum value [...] */
>>>> #else
>>>> uint32_t cimax : 8;
>>>> uint32_t cimin : 8;
>>>> uint32_t cwmax : 8;
>>>> uint32_t cwmin : 7;
>>>> uint32_t we : 1;
>>>> #endif
>>>> } s;
>>>> };
>>>
>>> To me it seems kind of goofy to use uint32_t for the bitfields type.
>>> I would just use unsigned, which is just as sure to work as intended,
>>> isn't it?
>>
>> No. There are issues of alignment and padding one must consider
>> when using bitfields to model hardware registers, particularly
>> if (say) a device driver is meant to be shared across ISAs.
>>
>> Using the exact width types really does make a difference; it's
>> IB what those properties are, though we're usually at the mercy
>> of the target platform's ABI anyway at that point.
>
>The motivation for my query was not to ask an abstract theoretical
>question but a specific and pragmatic one.
My response was practical and pragmatic, and arises in code that
is written by real-world systems programmers.
I understand that is not your domain of expertise.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-22 15:04 +0000 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <oac_R.3743$Zhg2.1242@fx12.iad> |
| In reply to | #400174 |
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.
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).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-22 13:02 -0700 |
| Subject | Re: Microcontroller software stacks (was Re: this girl calls c ugly) |
| Message-ID | <111c4ck$1p9qt$1@kst.eternal-september.org> |
| In reply to | #400192 |
scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> 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).
You could have used unsigned long long for both. I agree that using
uint64_t is better if you specifically need 64 bits.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-14 12:51 -0700 |
| Subject | Re: Microcontroller software stacks |
| Message-ID | <865x1c7a63.fsf@linuxsc.com> |
| In reply to | #400192 |
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?
> 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.
[toc] | [prev] | [next] | [standalone]
Page 21 of 24 — ← Prev page 1 … 19 20 [21] 22 23 24 Next page →
Back to top | Article view | comp.lang.c
csiph-web