Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #396152 > unrolled thread
| Started by | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| First post | 2026-01-05 07:19 +0000 |
| Last post | 2026-01-05 15:57 +0000 |
| Articles | 20 on this page of 209 — 21 participants |
Back to article view | Back to comp.lang.c
printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 07:19 +0000
Re: printf and time_t Andrey Tarasevich <noone@noone.net> - 2026-01-05 00:17 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-05 10:51 +0200
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 12:45 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-05 15:21 +0200
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 13:49 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-05 16:47 +0200
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 15:29 +0000
Re: printf and time_t bart <bc@freeuk.com> - 2026-01-05 13:22 +0000
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 13:52 +0000
Re: printf and time_t Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-06 00:27 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-06 11:29 +0200
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 10:31 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-06 20:05 +0200
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-06 18:16 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 05:06 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-07 13:08 -0500
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 09:54 -0800
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 10:08 -0800
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-08 18:36 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 13:05 -0800
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-09 16:26 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:38 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-10 22:40 -0500
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-06 16:29 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-06 17:14 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-07 14:01 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 04:28 -0800
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 22:03 -0800
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 15:45 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 13:28 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-08 01:26 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 16:00 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-08 02:38 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 17:36 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-08 11:01 +0200
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-08 19:31 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-09 14:18 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-09 13:49 +0100
Re: printf and time_t wij <wyniijj5@gmail.com> - 2026-01-10 00:17 +0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-09 11:27 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-10 22:02 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-11 13:20 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 04:59 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-11 15:32 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-11 16:34 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-11 18:19 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-11 20:25 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 15:23 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 10:50 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 14:56 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 22:44 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 10:51 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 08:21 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 11:06 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 13:26 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-12 16:06 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-13 08:56 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-13 00:53 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-13 11:09 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-13 13:45 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-13 14:32 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-13 17:47 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-12 04:27 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 17:57 +0100
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 17:19 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-03 18:19 -0800
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 21:05 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 21:24 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-14 09:26 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-14 14:53 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-15 08:29 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-14 11:03 +0200
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-14 22:19 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-15 11:02 +0200
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-11 11:58 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 08:28 +0100
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-11 11:51 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-11 23:51 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 22:47 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 08:34 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 11:24 +0200
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 10:34 +0200
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 07:47 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-03 19:51 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-04 06:22 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 16:44 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-04 18:12 +0100
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-04 18:48 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 18:11 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-04 21:09 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 20:42 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-05 12:41 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-05 17:42 +0000
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-02-05 18:38 +0000
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-05 23:55 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-05 23:42 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-05 21:10 -0800
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-06 09:51 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 04:46 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 12:39 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-02-06 14:47 +0200
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 13:04 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-02-08 10:52 +0200
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-08 12:18 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-08 04:03 -0800
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-08 16:50 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-08 18:55 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-08 19:54 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-08 21:27 +0100
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-08 19:59 +0000
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-08 21:51 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-08 19:43 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-06 14:06 +0100
Re: printf and time_t Kaz Kylheku <046-301-5902@kylheku.com> - 2026-02-07 18:07 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-07 20:32 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-07 22:48 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-07 23:54 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-08 19:21 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-08 23:35 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-09 01:27 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-10 00:14 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-10 13:22 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-09 01:40 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 05:08 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 14:28 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 14:29 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 11:21 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 20:08 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 12:56 -0800
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-02-06 14:35 +0000
Re: printf and time_t Kaz Kylheku <046-301-5902@kylheku.com> - 2026-02-07 17:55 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-07 20:51 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-06 12:27 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-05 11:05 -0800
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-06 02:59 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 04:49 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 13:05 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-17 23:11 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-06 12:42 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-02-04 22:48 +0200
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-02-04 22:57 +0200
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 23:24 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-04 16:04 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-04 15:39 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 23:52 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-05 12:51 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-05 11:22 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-06 12:46 +0100
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-06 02:25 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-03 14:43 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-03 23:06 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-03 15:33 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:17 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-14 11:10 +0200
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-15 06:10 -0500
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-15 04:00 -0800
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-15 20:08 -0500
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-15 18:17 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-09 09:25 +0100
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-08 11:35 +0100
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 19:44 -0500
Re: printf and time_t bart <bc@freeuk.com> - 2026-01-07 01:14 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-07 13:41 +0200
Re: printf and time_t bart <bc@freeuk.com> - 2026-01-07 15:54 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-07 18:17 +0200
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-07 12:45 -0500
Re: printf and time_t Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-07 20:31 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 13:32 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-08 01:29 +0200
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-08 19:16 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-08 17:13 +0100
Re: printf and time_t Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-01-05 16:23 +0000
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 16:34 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-05 17:34 +0100
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 13:11 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-05 19:28 +0100
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 14:00 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-05 20:38 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-05 14:41 -0800
Epoch seconds and linear count (was Re: printf and time_t) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-01-06 14:51 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-05 19:23 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-05 15:04 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-06 01:23 +0200
Re: printf and time_t Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-06 00:22 +0000
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 10:22 -0500
Re: printf and time_t Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-01-06 15:45 +0000
Re: printf and time_t Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-01-06 17:00 +0100
Re: printf and time_t Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-01-06 16:08 +0000
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 11:19 -0500
Re: printf and time_t Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-01-06 16:18 +0000
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 13:14 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-05 11:32 +0100
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 07:37 -0500
Re: printf and time_t Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-06 00:30 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-05 20:00 -0800
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 07:50 -0500
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 05:02 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-07 12:58 -0500
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 23:21 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-02 03:37 -0800
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-02 17:53 -0500
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-02 18:04 -0800
Re: printf and time_t Michael Sanders <porkchop@invalid.foo> - 2026-01-05 08:32 +0000
Re: printf and time_t Michael Sanders <porkchop@invalid.foo> - 2026-01-05 08:46 +0000
Re: printf and time_t highcrew <high.crew3868@fastmail.com> - 2026-01-05 12:48 +0100
Re: printf and time_t richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-01-05 14:53 +0000
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 15:36 +0000
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-05 15:57 +0000
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-13 13:45 +0200 |
| Message-ID | <20260113134501.000057c8@yahoo.com> |
| In reply to | #396390 |
On Tue, 13 Jan 2026 11:09:55 +0100
David Brown <david.brown@hesbynett.no> wrote:
> On 13/01/2026 09:53, Keith Thompson wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> >> On 13/01/2026 01:06, Keith Thompson wrote:
> >>> David Brown <david.brown@hesbynett.no> writes:
> >>> [...]
> >>> Context: %wN and %wfN printf length modifier, new in C23.
> >>>
> >>>> gcc has supported the format, along with much of C23, since gcc
> >>>> 13, and ARM's gcc-based toolchain version 13.2 is from October
> >>>> 2023. (The current version is 15.2 from December 2025.) But I
> >>>> don't know about library support - that is a very different
> >>>> matter. (Compiler support for printf really just means checking
> >>>> the format specifiers match the parameters.)
> >>> Of course printf is implemented in the library, not in the
> >>> compiler.
> >>
> >> Primarily, yes. But like all standard library functions, compilers
> >> can have special handling in some ways. This is more obvious for
> >> functions like memcpy, where the compiler can often generate
> >> significantly better code (specially for small known sizes). As
> >> far as I know, the only optimisation gcc does on printf is turn
> >> something like printf("Hello\n") into puts("Hello").
> >> Hypothetically, there is nothing to stop a compiler being a great
> >> deal more sophisticated than that, and doing the format-string
> >> interpretation directly in some way.
> >
> > Sure, but in practice the library support for printf is the only
> > thing that matters. If your library doesn't support %wN, having
> > the compiler recognize it doesn't help. I'm not sure why you even
> > mentioned gcc in this context.
> >
>
> I had several reasons (I would want compiler checking of the format
> before using it, I know the state of support in gcc, and I had
> mentioned ARM's gcc toolchains as they are the standard choice of
> toolchains for embedded ARM systems).
[O.T.]
AFAIK, that's no longer the case. For last 3-4 years Cortex-M MCU
vendors, in particular STMicro and TI, intensely push clang as a default
compiler in their free IDEs.
Today, in order to use gcc in the new embedded ARM project, developer
has to make a conscious effort of rejecting vendor's default. Most
likely, gcc compiler does not come as part of default installation
package. It has to be downloaded and installed separately.
I would guess that overwhelming majority of devs does not bother.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-13 14:32 +0100 |
| Message-ID | <10k5hht$35a2e$1@dont-email.me> |
| In reply to | #396391 |
On 13/01/2026 12:45, Michael S wrote:
> On Tue, 13 Jan 2026 11:09:55 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 13/01/2026 09:53, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 13/01/2026 01:06, Keith Thompson wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> [...]
>>>>> Context: %wN and %wfN printf length modifier, new in C23.
>>>>>
>>>>>> gcc has supported the format, along with much of C23, since gcc
>>>>>> 13, and ARM's gcc-based toolchain version 13.2 is from October
>>>>>> 2023. (The current version is 15.2 from December 2025.) But I
>>>>>> don't know about library support - that is a very different
>>>>>> matter. (Compiler support for printf really just means checking
>>>>>> the format specifiers match the parameters.)
>>>>> Of course printf is implemented in the library, not in the
>>>>> compiler.
>>>>
>>>> Primarily, yes. But like all standard library functions, compilers
>>>> can have special handling in some ways. This is more obvious for
>>>> functions like memcpy, where the compiler can often generate
>>>> significantly better code (specially for small known sizes). As
>>>> far as I know, the only optimisation gcc does on printf is turn
>>>> something like printf("Hello\n") into puts("Hello").
>>>> Hypothetically, there is nothing to stop a compiler being a great
>>>> deal more sophisticated than that, and doing the format-string
>>>> interpretation directly in some way.
>>>
>>> Sure, but in practice the library support for printf is the only
>>> thing that matters. If your library doesn't support %wN, having
>>> the compiler recognize it doesn't help. I'm not sure why you even
>>> mentioned gcc in this context.
>>>
>>
>> I had several reasons (I would want compiler checking of the format
>> before using it, I know the state of support in gcc, and I had
>> mentioned ARM's gcc toolchains as they are the standard choice of
>> toolchains for embedded ARM systems).
>
> [O.T.]
> AFAIK, that's no longer the case. For last 3-4 years Cortex-M MCU
> vendors, in particular STMicro and TI, intensely push clang as a default
> compiler in their free IDEs.
As far as I know, ST uses ARM's gcc build as their normal toolchain. I
haven't looked at TI's development tools for a good while.
But it is certainly the case that clang-based toolchains are gaining in
popularity for non-Linux embedded ARM. I've been looking at them
myself, and see advantages and disadvantages. However, I believe gcc is
still dominated by a large margin, and ARM makes regular releases of
complete toolchain packages (compiler, libraries, debugger, etc.).
> Today, in order to use gcc in the new embedded ARM project, developer
> has to make a conscious effort of rejecting vendor's default. Most
> likely, gcc compiler does not come as part of default installation
> package. It has to be downloaded and installed separately.
> I would guess that overwhelming majority of devs does not bother.
>
My experience is that the majority of microcontroller vendors provide
gcc toolchains as part of their default installations. They used to
have their own gcc toolchain builds, or use third-parties like Code
Sourcery, but these days they usually use an off-the-shelf ARM package.
But several vendors are in a transition period where they are gradually
moving from established Eclipse-based tools towards VS Code tools, and
perhaps clang is either an option or default with their newer IDEs.
Those vendors provide, support and maintain both IDEs at the moment, but
sometimes detailed support for particular microcontrollers only exists
for one of them.
I agree that most developers will use whatever compiler comes as default
with their vendor-supplied IDEs. Personally, I think that's fine for
getting started, or for quick throw-away projects. For anything serious
I prefer to have the build controlled from outside the IDE (by a
makefile), using the toolchain I choose (typically the latest ARM gcc
toolchain when the project starts, then remaining consistent throughout
the lifetime of the project). The IDEs can still be good editors, IDEs,
debuggers, etc.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-13 17:47 +0200 |
| Message-ID | <20260113174727.00000909@yahoo.com> |
| In reply to | #396392 |
On Tue, 13 Jan 2026 14:32:45 +0100
David Brown <david.brown@hesbynett.no> wrote:
> On 13/01/2026 12:45, Michael S wrote:
> > On Tue, 13 Jan 2026 11:09:55 +0100
> > David Brown <david.brown@hesbynett.no> wrote:
> >
> >> On 13/01/2026 09:53, Keith Thompson wrote:
> >>> David Brown <david.brown@hesbynett.no> writes:
> >>>> On 13/01/2026 01:06, Keith Thompson wrote:
> >>>>> David Brown <david.brown@hesbynett.no> writes:
> >>>>> [...]
> >>>>> Context: %wN and %wfN printf length modifier, new in C23.
> >>>>>
> >>>>>> gcc has supported the format, along with much of C23, since gcc
> >>>>>> 13, and ARM's gcc-based toolchain version 13.2 is from October
> >>>>>> 2023. (The current version is 15.2 from December 2025.) But I
> >>>>>> don't know about library support - that is a very different
> >>>>>> matter. (Compiler support for printf really just means
> >>>>>> checking the format specifiers match the parameters.)
> >>>>> Of course printf is implemented in the library, not in the
> >>>>> compiler.
> >>>>
> >>>> Primarily, yes. But like all standard library functions,
> >>>> compilers can have special handling in some ways. This is more
> >>>> obvious for functions like memcpy, where the compiler can often
> >>>> generate significantly better code (specially for small known
> >>>> sizes). As far as I know, the only optimisation gcc does on
> >>>> printf is turn something like printf("Hello\n") into
> >>>> puts("Hello"). Hypothetically, there is nothing to stop a
> >>>> compiler being a great deal more sophisticated than that, and
> >>>> doing the format-string interpretation directly in some way.
> >>>
> >>> Sure, but in practice the library support for printf is the only
> >>> thing that matters. If your library doesn't support %wN, having
> >>> the compiler recognize it doesn't help. I'm not sure why you even
> >>> mentioned gcc in this context.
> >>>
> >>
> >> I had several reasons (I would want compiler checking of the format
> >> before using it, I know the state of support in gcc, and I had
> >> mentioned ARM's gcc toolchains as they are the standard choice of
> >> toolchains for embedded ARM systems).
> >
> > [O.T.]
> > AFAIK, that's no longer the case. For last 3-4 years Cortex-M MCU
> > vendors, in particular STMicro and TI, intensely push clang as a
> > default compiler in their free IDEs.
>
> As far as I know, ST uses ARM's gcc build as their normal toolchain.
> I haven't looked at TI's development tools for a good while.
>
You are right.
I downloaded the latest version of ST CubeIDE (2.0.0).
It claims to support STARM-Clang (not that I figured out how exactly),
but gcc is a default toolchain, same like in 1.x
I played with it for a few minutes then uninstalled as fast as I can.
> But it is certainly the case that clang-based toolchains are gaining
> in popularity for non-Linux embedded ARM. I've been looking at them
> myself, and see advantages and disadvantages. However, I believe gcc
> is still dominated by a large margin, and ARM makes regular releases
> of complete toolchain packages (compiler, libraries, debugger, etc.).
>
> > Today, in order to use gcc in the new embedded ARM project,
> > developer has to make a conscious effort of rejecting vendor's
> > default. Most likely, gcc compiler does not come as part of default
> > installation package. It has to be downloaded and installed
> > separately. I would guess that overwhelming majority of devs does
> > not bother.
>
> My experience is that the majority of microcontroller vendors provide
> gcc toolchains as part of their default installations. They used to
> have their own gcc toolchain builds, or use third-parties like Code
> Sourcery, but these days they usually use an off-the-shelf ARM
> package. But several vendors are in a transition period where they
> are gradually moving from established Eclipse-based tools towards VS
> Code tools, and perhaps clang is either an option or default with
> their newer IDEs. Those vendors provide, support and maintain both
> IDEs at the moment, but sometimes detailed support for particular
> microcontrollers only exists for one of them.
>
> I agree that most developers will use whatever compiler comes as
> default with their vendor-supplied IDEs. Personally, I think that's
> fine for getting started, or for quick throw-away projects. For
> anything serious I prefer to have the build controlled from outside
> the IDE (by a makefile), using the toolchain I choose (typically the
> latest ARM gcc toolchain when the project starts, then remaining
> consistent throughout the lifetime of the project). The IDEs can
> still be good editors, IDEs, debuggers, etc.
>
For me Eclipse-based IDE is slower and harder to use than command line
in any situation.
Although I am ready to admit that TI did better job than most of
turning Eclipse into something almost palatable.
Still, even Eclipse in form of TI's CCS is an obstacle for me rather
than help.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-12 04:27 -0800 |
| Message-ID | <87qzrvow2l.fsf@example.invalid> |
| In reply to | #396361 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> C23 includes length specifiers with explicit bit counts, so "%w32u" is
> for an unsigned integer argument of 32 bits:
>
> """
> wN Specifies that a following b, B, d, i, o, u, x, or X conversion
> specifier applies to an integer argument with a specific width
> where N is a positive decimal integer with no leading zeros
> (the argument will have been promoted according to the integer
> promotions, but its value shall be converted to the unpromoted
> type); or that a following n conversion specifier applies to a
> pointer to an integer type argument with a width of N bits. All
> minimum-width integer types (7.22.1.2) and exact-width integer
> types (7.22.1.1) defined in the header <stdint.h> shall be
> supported. Other supported values of N are implementation-defined.
> """
>
> That looks to me that it would be a correct specifier for uint32_t,
Yes, so for example this:
uint32_t n = 42;
printf("n = %w32u\n", n);
is correct, if I'm reading it correctly. It's also correct for
uint_least32_t, which is expected to be the same type as uint32_t
if the latter exists. There's also support for the [u]int_fastN_t
types, using for example "%wf32u" in place of "%w32u".
> and should also be fully defined behaviour for unsigned int and
> unsigned long if these are 32 bits wide.
No, I don't think C23 says that. If int and long happen to be the same
width, they are still incompatible, and there is no printf format
specifier that has defined behavior for both.
That first sentence is a bit ambiguous
wN Specifies that a following b, B, d, i, o, u, x, or X conversion
specifier applies to an integer argument with a specific width ...
but I don't think it means that it must accept *any* integer type
of the specified width.
Later in the same paragraph, it says that all [u]intN_t and
[u]int_leastN_t types shall be supported -- all such *types*, not
all such *widths*. And it doesn't say that the predefined types
shall be supported.
Paragraph 9 says:
fprintf shall behave as if it uses va_arg with a type argument
naming the type resulting from applying the default argument
promotions to the type corresponding to the conversion specification
and then converting the result of the va_arg expansion to the type
corresponding to the conversion specification.
And in the description for the va_arg macro (whose second argument
is a type name):
If *type* is not compatible with the type of the actual
next argument (as promoted according to the default argument
promotions), the behavior is undefined, except for the following
cases: ...
Corresponding signed and unsigned types are supported if the value
is representable in both, but there's no provision for mixing int
and long even if they have the same width.
If printf is implemented using <stdarg.h>, what type name can it
pass to the va_arg() macro given a "%w32u" specification? It can
only pass uint32_t or uint_least32_t (or it can pass unsigned int
or unsigned long *if* that type is compatible with the uint32_t).
(And C23 adds a requirement that [u]int_leastN_t is the same type as
[u]intN_t if the latter exists; perhaps this is why.)
Prior to C17, there is no conversion specification that's valid for
both int and long, even if they're the same width. Changing that
in C23 would have been a significant change, but there's no mention
of it, even in a footnote.
The "%w..." format specifiers are simpler (and IMHO less ugly)
than the macros in <inttypes.h>, but they don't add any fundamental
new capability.
Given the format specifier "%w32u", the corresponding argument must
be of type uint32_t, or it can be of type int32_t and representable
in both, or it can be of a type compatible with [u]int32_t. I expect
that in most or all implementations, the undefined behavior of
passing an incompatible type with the same width and representation
will appear as if it "worked", but a compile-time warning is likely
if the format is a string literal.
And of course if you want to print a uint32_t value, you can always
cast it to unsigned long and use "%u".
--
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-01-12 17:57 +0100 |
| Message-ID | <10k395j$2ft9n$1@dont-email.me> |
| In reply to | #396371 |
On 12/01/2026 13:27, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> C23 includes length specifiers with explicit bit counts, so "%w32u" is
>> for an unsigned integer argument of 32 bits:
>>
>> """
>> wN Specifies that a following b, B, d, i, o, u, x, or X conversion
>> specifier applies to an integer argument with a specific width
>> where N is a positive decimal integer with no leading zeros
>> (the argument will have been promoted according to the integer
>> promotions, but its value shall be converted to the unpromoted
>> type); or that a following n conversion specifier applies to a
>> pointer to an integer type argument with a width of N bits. All
>> minimum-width integer types (7.22.1.2) and exact-width integer
>> types (7.22.1.1) defined in the header <stdint.h> shall be
>> supported. Other supported values of N are implementation-defined.
>> """
>>
>> That looks to me that it would be a correct specifier for uint32_t,
>
> Yes, so for example this:
>
> uint32_t n = 42;
> printf("n = %w32u\n", n);
>
> is correct, if I'm reading it correctly. It's also correct for
> uint_least32_t, which is expected to be the same type as uint32_t
> if the latter exists. There's also support for the [u]int_fastN_t
> types, using for example "%wf32u" in place of "%w32u".
>
>> and should also be fully defined behaviour for unsigned int and
>> unsigned long if these are 32 bits wide.
>
> No, I don't think C23 says that. If int and long happen to be the same
> width, they are still incompatible, and there is no printf format
> specifier that has defined behavior for both.
>
> That first sentence is a bit ambiguous
>
> wN Specifies that a following b, B, d, i, o, u, x, or X conversion
> specifier applies to an integer argument with a specific width ...
>
> but I don't think it means that it must accept *any* integer type
> of the specified width.
That's the part that I am not at all sure about - it is, as you say,
ambiguous. It also refers to "a pointer to an integer type argument
with a width of N bits" (in the context of an "n" specifier) - that
sounds like "%w32n" would be happy with a "uint32_t *", "unsigned int *"
or "unsigned long int *" pointer (when the integer types are all 32
bit). It would be strange for printf to be happy with clearly
incompatible pointer types when the integer sizes are the same, but not
be happy with integer values when the sizes are the same.
But my interpretation here could well be wrong. Only the [u]intNN_t and
[u]int_leastNN_t types are explicitly and clearly accepted here.
>
> Later in the same paragraph, it says that all [u]intN_t and
> [u]int_leastN_t types shall be supported -- all such *types*, not
> all such *widths*. And it doesn't say that the predefined types
> shall be supported.
>
> Paragraph 9 says:
>
> fprintf shall behave as if it uses va_arg with a type argument
> naming the type resulting from applying the default argument
> promotions to the type corresponding to the conversion specification
> and then converting the result of the va_arg expansion to the type
> corresponding to the conversion specification.
>
> And in the description for the va_arg macro (whose second argument
> is a type name):
>
> If *type* is not compatible with the type of the actual
> next argument (as promoted according to the default argument
> promotions), the behavior is undefined, except for the following
> cases: ...
>
> Corresponding signed and unsigned types are supported if the value
> is representable in both, but there's no provision for mixing int
> and long even if they have the same width.
>
> If printf is implemented using <stdarg.h>, what type name can it
> pass to the va_arg() macro given a "%w32u" specification? It can
> only pass uint32_t or uint_least32_t (or it can pass unsigned int
> or unsigned long *if* that type is compatible with the uint32_t).
> (And C23 adds a requirement that [u]int_leastN_t is the same type as
> [u]intN_t if the latter exists; perhaps this is why.)
>
> Prior to C17, there is no conversion specification that's valid for
> both int and long, even if they're the same width. Changing that
> in C23 would have been a significant change, but there's no mention
> of it, even in a footnote.
>
> The "%w..." format specifiers are simpler (and IMHO less ugly)
> than the macros in <inttypes.h>, but they don't add any fundamental
> new capability.
>
> Given the format specifier "%w32u", the corresponding argument must
> be of type uint32_t, or it can be of type int32_t and representable
> in both, or it can be of a type compatible with [u]int32_t. I expect
> that in most or all implementations, the undefined behavior of
> passing an incompatible type with the same width and representation
> will appear as if it "worked", but a compile-time warning is likely
> if the format is a string literal.
>
> And of course if you want to print a uint32_t value, you can always
> cast it to unsigned long and use "%u".
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-02-03 17:19 -0800 |
| Message-ID | <86ikcdi9v5.fsf@linuxsc.com> |
| In reply to | #396371 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>
>> C23 includes length specifiers with explicit bit counts, so "%w32u" is
>> for an unsigned integer argument of 32 bits:
>>
>> """
>> wN Specifies that a following b, B, d, i, o, u, x, or X conversion
>> specifier applies to an integer argument with a specific width
>> where N is a positive decimal integer with no leading zeros
>> (the argument will have been promoted according to the integer
>> promotions, but its value shall be converted to the unpromoted
>> type); or that a following n conversion specifier applies to a
>> pointer to an integer type argument with a width of N bits. All
>> minimum-width integer types (7.22.1.2) and exact-width integer
>> types (7.22.1.1) defined in the header <stdint.h> shall be
>> supported. Other supported values of N are implementation-defined.
>> """
>>
>> That looks to me that it would be a correct specifier for uint32_t,
>
> Yes, so for example this:
>
> uint32_t n = 42;
> printf("n = %w32u\n", n);
>
> is correct, if I'm reading it correctly. It's also correct for
> uint_least32_t, which is expected to be the same type as uint32_t
> if the latter exists. There's also support for the [u]int_fastN_t
> types, using for example "%wf32u" in place of "%w32u".
>
>> and should also be fully defined behaviour for unsigned int and
>> unsigned long if these are 32 bits wide.
>
> No, I don't think C23 says that.
Right, it doesn't.
> If int and long happen to be the same
> width, they are still incompatible, and there is no printf format
> specifier that has defined behavior for both.
>
> That first sentence is a bit ambiguous
>
> wN Specifies that a following b, B, d, i, o, u, x, or X conversion
> specifier applies to an integer argument with a specific width ...
>
> but I don't think it means that it must accept *any* integer type
> of the specified width.
As I read the standard there is no ambiguity. The first sentence
says what the length modifier means. The second sentence says
which types (if any) correspond to the description in the first
sentence.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-03 18:19 -0800 |
| Message-ID | <87qzr1p7we.fsf@example.invalid> |
| In reply to | #396583 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>
>>> C23 includes length specifiers with explicit bit counts, so "%w32u" is
>>> for an unsigned integer argument of 32 bits:
>>>
>>> """
>>> wN Specifies that a following b, B, d, i, o, u, x, or X conversion
>>> specifier applies to an integer argument with a specific width
>>> where N is a positive decimal integer with no leading zeros
>>> (the argument will have been promoted according to the integer
>>> promotions, but its value shall be converted to the unpromoted
>>> type); or that a following n conversion specifier applies to a
>>> pointer to an integer type argument with a width of N bits. All
>>> minimum-width integer types (7.22.1.2) and exact-width integer
>>> types (7.22.1.1) defined in the header <stdint.h> shall be
>>> supported. Other supported values of N are implementation-defined.
>>> """
>>>
>>> That looks to me that it would be a correct specifier for uint32_t,
>>
>> Yes, so for example this:
>>
>> uint32_t n = 42;
>> printf("n = %w32u\n", n);
>>
>> is correct, if I'm reading it correctly. It's also correct for
>> uint_least32_t, which is expected to be the same type as uint32_t
>> if the latter exists. There's also support for the [u]int_fastN_t
>> types, using for example "%wf32u" in place of "%w32u".
>>
>>> and should also be fully defined behaviour for unsigned int and
>>> unsigned long if these are 32 bits wide.
>>
>> No, I don't think C23 says that.
>
> Right, it doesn't.
>
>> If int and long happen to be the same
>> width, they are still incompatible, and there is no printf format
>> specifier that has defined behavior for both.
>>
>> That first sentence is a bit ambiguous
>>
>> wN Specifies that a following b, B, d, i, o, u, x, or X conversion
>> specifier applies to an integer argument with a specific width ...
>>
>> but I don't think it means that it must accept *any* integer type
>> of the specified width.
>
> As I read the standard there is no ambiguity. The first sentence
> says what the length modifier means. The second sentence says
> which types (if any) correspond to the description in the first
> sentence.
The descriptions for all the other length modifiers name the types
to which they apply in the first sentence. "hh" applies to signed
char or unsigned char, "l" applies to long int or unsigned long int,
"z" applies to size_t, and so forth. The first sentence of the
description for "wN" says it "applies to an integer argument with
a specific width".
The intent is that "%w32d" applies to an argument of type
int_least32_t or int32_t (if the latter exists, it must be the same
type as the former).
Suppose, hypothetically, that it had been the intent that "%w32d"
applies to *any* signed integer type with a width of 32 bits (e.g.,
both int and long if both are 32 bits wide). I think that the
current wording could express that intent. The second sentence
could taken as a clarification rather than a restriction. (An
irrelevant aside: That might actually be a nice feature.)
Assume an implementation with 32-bit int, 32-bit long, and 64-bit
long long, where int32_t and int64_t are int and long long,
respectively (e.g., "gcc -m32" with glibc on 64-bit Ubuntu), so
none of the intN_t types are defined as long. Then this:
printf("%w32d\n", 0L);
has undefined behavior if we assume (as I do) that "%w32d" applies
only to the type defined as int32_t (and int_least32_t). But the
0L argument *is* "an integer argument with a specific width", and
the following sentence "All minimum-width integer types (7.22.1.2)
and exact-width integer types (7.22.1.1) defined in the header
<stdint.h> shall be supported." does not contradict that.
I think the phrase "an integer argument with a specific width" was
an attempt to describe a specific set of types, but it was worded
in a way that applies a larger set of types. I think the following
sentence is not sufficiently clear in its attempt to restrict the
list of applicable types.
I understand the intent. Adding a format string that can apply
to distinct incompatible types would be a major change that would
surely be discussed in greater detail. But the current wording
does not clearly express that intent, and one or more people here
have, quite understandably, interpreted the wording in a way that's
inconsistent with the presumed intent.
The description of wfN is a bit clearer, but could also use some
clarification that "a fastest minimum-width integer argument with
a specific width" refers specifically to the [u]int_fastN_t types.
I merely suggest a clarification, either a change in wording or
a footnote.
--
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-03-01 21:05 -0800 |
| Message-ID | <86h5qyg6sw.fsf@linuxsc.com> |
| In reply to | #396584 |
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:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>
>>>> C23 includes length specifiers with explicit bit counts, so "%w32u" is
>>>> for an unsigned integer argument of 32 bits:
>>>>
>>>> """
>>>> wN Specifies that a following b, B, d, i, o, u, x, or X conversion
>>>> specifier applies to an integer argument with a specific width
>>>> where N is a positive decimal integer with no leading zeros
>>>> (the argument will have been promoted according to the integer
>>>> promotions, but its value shall be converted to the unpromoted
>>>> type); or that a following n conversion specifier applies to a
>>>> pointer to an integer type argument with a width of N bits. All
>>>> minimum-width integer types (7.22.1.2) and exact-width integer
>>>> types (7.22.1.1) defined in the header <stdint.h> shall be
>>>> supported. Other supported values of N are implementation-defined.
>>>> """
>>>>
>>>> That looks to me that it would be a correct specifier for uint32_t,
>>>
>>> Yes, so for example this:
>>>
>>> uint32_t n = 42;
>>> printf("n = %w32u\n", n);
>>>
>>> is correct, if I'm reading it correctly. It's also correct for
>>> uint_least32_t, which is expected to be the same type as uint32_t
>>> if the latter exists. There's also support for the [u]int_fastN_t
>>> types, using for example "%wf32u" in place of "%w32u".
>>>
>>>> and should also be fully defined behaviour for unsigned int and
>>>> unsigned long if these are 32 bits wide.
>>>
>>> No, I don't think C23 says that.
>>
>> Right, it doesn't.
>>
>>> If int and long happen to be the same
>>> width, they are still incompatible, and there is no printf format
>>> specifier that has defined behavior for both.
>>>
>>> That first sentence is a bit ambiguous
>>>
>>> wN Specifies that a following b, B, d, i, o, u, x, or X conversion
>>> specifier applies to an integer argument with a specific width ...
>>>
>>> but I don't think it means that it must accept *any* integer type
>>> of the specified width.
>>
>> As I read the standard there is no ambiguity. The first sentence
>> says what the length modifier means. The second sentence says
>> which types (if any) correspond to the description in the first
>> sentence.
>
> The descriptions for all the other length modifiers name the types
> to which they apply in the first sentence. "hh" applies to signed
> char or unsigned char, "l" applies to long int or unsigned long int,
> "z" applies to size_t, and so forth. The first sentence of the
> description for "wN" says it "applies to an integer argument with
> a specific width".
>
> The intent is that "%w32d" applies to an argument of type
> int_least32_t or int32_t (if the latter exists, it must be the same
> type as the former).
>
> Suppose, hypothetically, that it had been the intent that "%w32d"
> applies to *any* signed integer type with a width of 32 bits (e.g.,
> both int and long if both are 32 bits wide). I think that the
> current wording could express that intent. The second sentence
> could taken as a clarification rather than a restriction. (An
> irrelevant aside: That might actually be a nice feature.)
>
> Assume an implementation with 32-bit int, 32-bit long, and 64-bit
> long long, where int32_t and int64_t are int and long long,
> respectively (e.g., "gcc -m32" with glibc on 64-bit Ubuntu), so
> none of the intN_t types are defined as long. Then this:
>
> printf("%w32d\n", 0L);
>
> has undefined behavior if we assume (as I do) that "%w32d" applies
> only to the type defined as int32_t (and int_least32_t). But the
> 0L argument *is* "an integer argument with a specific width", and
> the following sentence "All minimum-width integer types (7.22.1.2)
> and exact-width integer types (7.22.1.1) defined in the header
> <stdint.h> shall be supported." does not contradict that.
>
> I think the phrase "an integer argument with a specific width" was
> an attempt to describe a specific set of types, but it was worded
> in a way that applies a larger set of types. I think the following
> sentence is not sufficiently clear in its attempt to restrict the
> list of applicable types.
>
> I understand the intent. Adding a format string that can apply
> to distinct incompatible types would be a major change that would
> surely be discussed in greater detail. But the current wording
> does not clearly express that intent, [...]
In my opinion it does.
[toc] | [prev] | [next] | [standalone]
| From | "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-13 21:24 -0500 |
| Message-ID | <10k6uog$15aeb$7@dont-email.me> |
| In reply to | #396343 |
On 2026-01-11 08:32, Michael S wrote:
> On Sun, 11 Jan 2026 04:59:47 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>> On Sat, 10 Jan 2026 22:02:03 -0500
>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote:
>>>> On 2026-01-09 07:18, Michael S wrote:
>>>>> On Thu, 8 Jan 2026 19:31:13 -0500
>>>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu>
>>>>> wrote:
>>>> ...
>>>>>> I'd have no problem with your approach if you hadn't falsely
>>>>>> claimed that "It is correct on all platforms".
>>>>>
>>>>> Which I didn't.
>>>>
>>>> On 2026-01-07 19:38, Michael S wrote:
>>>> ...
>>>> > No, it is correct on all implementation.
>>>
>>> The quote is taken out of context.
>>> The context was that on platforms that have properties (a) and (b)
>>> (see below) printing variables declared as uint32_t via %u is
>>> probably UB according to the Standard (I don't know for sure,
>>> however it is probable),
...>>
>> I'm sure. uint32_t is an alias for some predefined integer type.
>>
>> This:
>> uint32_t n = 42;
>> printf("%u\n", n);
>> has undefined behavior *unless* uint32_t happens to an alias for
>> unsigned int in the current implementation -- not just any 32-bit
>> unsigned integer type, only unsigned int.
>>
>> If uint32_t is an alias for unsigned long (which implies that
>> unsigned long is exactly 32 bits), then the call's behavior is
>> undefined. (It might happen to "work".)
>>
>
> What exactly, assuming that conditions (a) and (b) fulfilled, should
> implementation do to prevent it from working?
> I mean short of completely crazy things that will make maintainer
> immediately fired?
I'm quite positive that you would consider anything that might give
unexpected behavior to such code to be "crazy". The simplest example I
can think of is that unsigned int is big-endian, while unsigned long is
little-endian, and I would even agree that such an implementation would
be peculiar, but such an implementation could be fully conforming to the
C standard.
>> If uint32_t and unsigned long have different sizes, it still might
>> happen happen to "work", depending on calling conventions. Passing a
>> 32-bit argument and telling printf to expect a 64-bit value clearly
>> has undefined behavior, but perhaps both happen to be passed in 64-bit
>> registers, for example.
>>
>
> And that is sort of intimate knowledge of the ABI that I don't want to
> exploit, as already mentioned in my other post in this sub-thread.
Which is precisely what's wrong about your approach - it relies upon
intimate knowledge of the ABI. Specifically, it relies on unsigned int
and unsigned long happening to have exactly the same size and
representation.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-14 09:26 +0100 |
| Message-ID | <10k7jvv$3q0mm$1@dont-email.me> |
| In reply to | #396401 |
On 14/01/2026 03:24, James Russell Kuyper Jr. wrote:
> On 2026-01-11 08:32, Michael S wrote:
>> On Sun, 11 Jan 2026 04:59:47 -0800
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> Michael S <already5chosen@yahoo.com> writes:
>>>> On Sat, 10 Jan 2026 22:02:03 -0500
>>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote:
>>>>> On 2026-01-09 07:18, Michael S wrote:
>>>>>> On Thu, 8 Jan 2026 19:31:13 -0500
>>>>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu>
>>>>>> wrote:
>>>>> ...
>>>>>>> I'd have no problem with your approach if you hadn't falsely
>>>>>>> claimed that "It is correct on all platforms".
>>>>>>
>>>>>> Which I didn't.
>>>>>
>>>>> On 2026-01-07 19:38, Michael S wrote:
>>>>> ...
>>>>> > No, it is correct on all implementation.
>>>>
>>>> The quote is taken out of context.
>>>> The context was that on platforms that have properties (a) and (b)
>>>> (see below) printing variables declared as uint32_t via %u is
>>>> probably UB according to the Standard (I don't know for sure,
>>>> however it is probable),
> ...>>
>>> I'm sure. uint32_t is an alias for some predefined integer type.
>>>
>>> This:
>>> uint32_t n = 42;
>>> printf("%u\n", n);
>>> has undefined behavior *unless* uint32_t happens to an alias for
>>> unsigned int in the current implementation -- not just any 32-bit
>>> unsigned integer type, only unsigned int.
>>>
>>> If uint32_t is an alias for unsigned long (which implies that
>>> unsigned long is exactly 32 bits), then the call's behavior is
>>> undefined. (It might happen to "work".)
>>>
>>
>> What exactly, assuming that conditions (a) and (b) fulfilled, should
>> implementation do to prevent it from working?
>> I mean short of completely crazy things that will make maintainer
>> immediately fired?
>
> I'm quite positive that you would consider anything that might give
> unexpected behavior to such code to be "crazy". The simplest example I
> can think of is that unsigned int is big-endian, while unsigned long is
> little-endian, and I would even agree that such an implementation would
> be peculiar, but such an implementation could be fully conforming to the
> C standard.
>
Would it be allowed (in the sense of being possible in a hypothetical
but fully conforming implementation) to have "unsigned long" be 32-bit,
without padding, while "unsigned int" is 64-bit wide with 32 value bits
and 32 padding bits? A cpu might be able to handle 64-bit lumps faster
than 32-bit lumps and choose such a setup to make "unsigned int" as fast
as it can. (uint32_t in this case would be an alias for "unsigned
long", as it can't have padding bits.)
(I realise this is swapping your pink unicorn C implementation for a
green unicorn C implementation, but sometimes it is fun to see how weird
you can imagine while still being able to support conforming C.)
>>> If uint32_t and unsigned long have different sizes, it still might
>>> happen happen to "work", depending on calling conventions. Passing a
>>> 32-bit argument and telling printf to expect a 64-bit value clearly
>>> has undefined behavior, but perhaps both happen to be passed in 64-bit
>>> registers, for example.
>>>
>>
>> And that is sort of intimate knowledge of the ABI that I don't want to
>> exploit, as already mentioned in my other post in this sub-thread.
>
> Which is precisely what's wrong about your approach - it relies upon
> intimate knowledge of the ABI. Specifically, it relies on unsigned int
> and unsigned long happening to have exactly the same size and
> representation.
>
I don't think there is anything intrinsically wrong with writing code
that makes assumptions about the target ABI - non-portable code has its
essential place in programming. But there /is/ something wrong about
making assumptions about an ABI while claiming you are writing portable
code that does not make such assumptions. And there is something that
is at least "stylistically questionable" about needlessly and wantonly
doing so. By all means write code that relies on the specifics of the
target or compiler, but do so knowingly, do so only when you have good
reason for it, and do so in a way that is clear to anyone later trying
to re-use the code on some other system.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-14 14:53 -0800 |
| Message-ID | <87tswnolgw.fsf@example.invalid> |
| In reply to | #396412 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Would it be allowed (in the sense of being possible in a hypothetical
> but fully conforming implementation) to have "unsigned long" be
> 32-bit, without padding, while "unsigned int" is 64-bit wide with 32
> value bits and 32 padding bits? A cpu might be able to handle 64-bit
> lumps faster than 32-bit lumps and choose such a setup to make
> "unsigned int" as fast as it can. (uint32_t in this case would be an
> alias for "unsigned long", as it can't have padding bits.)
The *width* of an integer type is the number of value bits plus the sign
bit, if any, so "64-bit wide" is an incorrect description.
What would be possible is:
- CHAR_BIT * sizeof (unsigned int) == 64
- UINT_WIDTH == 32 (32 padding bits)
- CHAR_BIT * sizeof (unsigned long) == 32
- ULONG_WIDTH == 32 (no padding bits)
The *_WIDTH macros are new in C23.
[...]
--
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-01-15 08:29 +0100 |
| Message-ID | <10ka510$jgf1$1@dont-email.me> |
| In reply to | #396423 |
On 14/01/2026 23:53, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Would it be allowed (in the sense of being possible in a hypothetical >> but fully conforming implementation) to have "unsigned long" be >> 32-bit, without padding, while "unsigned int" is 64-bit wide with 32 >> value bits and 32 padding bits? A cpu might be able to handle 64-bit >> lumps faster than 32-bit lumps and choose such a setup to make >> "unsigned int" as fast as it can. (uint32_t in this case would be an >> alias for "unsigned long", as it can't have padding bits.) > > The *width* of an integer type is the number of value bits plus the sign > bit, if any, so "64-bit wide" is an incorrect description. > Sorry, my terminology was imprecise. I had meant 32 bits wide (value bits) but a size of 64 bits (including padding). > What would be possible is: > > - CHAR_BIT * sizeof (unsigned int) == 64 > - UINT_WIDTH == 32 (32 padding bits) > - CHAR_BIT * sizeof (unsigned long) == 32 > - ULONG_WIDTH == 32 (no padding bits) > > The *_WIDTH macros are new in C23. > > [...] > So you agree that it would be possible? (I'm sure we agree that it is very unlikely in practice!)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-14 11:03 +0200 |
| Message-ID | <20260114110333.0000053e@yahoo.com> |
| In reply to | #396401 |
On Tue, 13 Jan 2026 21:24:16 -0500
"James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote:
> On 2026-01-11 08:32, Michael S wrote:
> > On Sun, 11 Jan 2026 04:59:47 -0800
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >
> >> Michael S <already5chosen@yahoo.com> writes:
> >>> On Sat, 10 Jan 2026 22:02:03 -0500
> >>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu>
> >>> wrote:
> >>>> On 2026-01-09 07:18, Michael S wrote:
> >>>>> On Thu, 8 Jan 2026 19:31:13 -0500
> >>>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu>
> >>>>> wrote:
> >>>> ...
> >>>>>> I'd have no problem with your approach if you hadn't falsely
> >>>>>> claimed that "It is correct on all platforms".
> >>>>>
> >>>>> Which I didn't.
> >>>>
> >>>> On 2026-01-07 19:38, Michael S wrote:
> >>>> ...
> >>>> > No, it is correct on all implementation.
> >>>
> >>> The quote is taken out of context.
> >>> The context was that on platforms that have properties (a) and (b)
> >>> (see below) printing variables declared as uint32_t via %u is
> >>> probably UB according to the Standard (I don't know for sure,
> >>> however it is probable),
> ...>>
> >> I'm sure. uint32_t is an alias for some predefined integer type.
> >>
> >> This:
> >> uint32_t n = 42;
> >> printf("%u\n", n);
> >> has undefined behavior *unless* uint32_t happens to an alias for
> >> unsigned int in the current implementation -- not just any 32-bit
> >> unsigned integer type, only unsigned int.
> >>
> >> If uint32_t is an alias for unsigned long (which implies that
> >> unsigned long is exactly 32 bits), then the call's behavior is
> >> undefined. (It might happen to "work".)
> >>
> >
> > What exactly, assuming that conditions (a) and (b) fulfilled, should
> > implementation do to prevent it from working?
> > I mean short of completely crazy things that will make maintainer
> > immediately fired?
>
> I'm quite positive that you would consider anything that might give
> unexpected behavior to such code to be "crazy". The simplest example
> I can think of is that unsigned int is big-endian, while unsigned
> long is little-endian, and I would even agree that such an
> implementation would be peculiar, but such an implementation could be
> fully conforming to the C standard.
>
You are inventive!
> >> If uint32_t and unsigned long have different sizes, it still might
> >> happen happen to "work", depending on calling conventions.
> >> Passing a 32-bit argument and telling printf to expect a 64-bit
> >> value clearly has undefined behavior, but perhaps both happen to
> >> be passed in 64-bit registers, for example.
> >>
> >
> > And that is sort of intimate knowledge of the ABI that I don't want
> > to exploit, as already mentioned in my other post in this
> > sub-thread.
>
> Which is precisely what's wrong about your approach - it relies upon
> intimate knowledge of the ABI. Specifically, it relies on unsigned
> int and unsigned long happening to have exactly the same size and
> representation.
>
I consider the latter a basic knowledge of ABI rather than an intimate.
For me programming feels uncomfortable without such knowledge. That is,
I can manage without, but do not want to.
Your mileage appears to vary.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-14 22:19 -0500 |
| Message-ID | <2da00117-65e2-410e-a095-b2ac2f994934@alumni.caltech.edu> |
| In reply to | #396415 |
On 2026-01-14 04:03, Michael S wrote: > On Tue, 13 Jan 2026 21:24:16 -0500 > "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: ... >> I'm quite positive that you would consider anything that might give >> unexpected behavior to such code to be "crazy". The simplest example >> I can think of is that unsigned int is big-endian, while unsigned >> long is little-endian, and I would even agree that such an >> implementation would be peculiar, but such an implementation could be >> fully conforming to the C standard. >> > > You are inventive! As a programmer, I paid close attention to what was and was not guaranteed about the software that I used. As a result, I've noticed many things, such as the fact that the standard imposes no requirements on the order of the bytes (or even of the bits) that are used to represent arithmetic values. ... >> Which is precisely what's wrong about your approach - it relies upon >> intimate knowledge of the ABI. Specifically, it relies on unsigned >> int and unsigned long happening to have exactly the same size and >> representation. >> > > I consider the latter a basic knowledge of ABI rather than an intimate. > For me programming feels uncomfortable without such knowledge. That is, > I can manage without, but do not want to. > Your mileage appears to vary. I've spent most of my career working under rules that explicitly prohibited me from writing code that depends upon such details. As a result, I actually have relatively little knowledge of how any particular implementation of C that I used decided to handle issues that the C standard left unspecified. I've always written my code so that it would do what it's supposed to do, regardless of which choices any given implementation made about things that are unspecified.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-15 11:02 +0200 |
| Message-ID | <20260115110200.00004d28@yahoo.com> |
| In reply to | #396424 |
On Wed, 14 Jan 2026 22:19:34 -0500 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 2026-01-14 04:03, Michael S wrote: > > On Tue, 13 Jan 2026 21:24:16 -0500 > > "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: > ... > >> I'm quite positive that you would consider anything that might give > >> unexpected behavior to such code to be "crazy". The simplest > >> example I can think of is that unsigned int is big-endian, while > >> unsigned long is little-endian, and I would even agree that such an > >> implementation would be peculiar, but such an implementation could > >> be fully conforming to the C standard. > >> > > > > You are inventive! > > As a programmer, I paid close attention to what was and was not > guaranteed about the software that I used. As a result, I've noticed > many things, such as the fact that the standard imposes no > requirements on the order of the bytes (or even of the bits) that are > used to represent arithmetic values. > Luckily apart from requirements of the Standard, compilers, except for toy/hobby ones, are constrained by need to have user. That places a bounds on creativity of their authors. > ... > >> Which is precisely what's wrong about your approach - it relies > >> upon intimate knowledge of the ABI. Specifically, it relies on > >> unsigned int and unsigned long happening to have exactly the same > >> size and representation. > >> > > > > I consider the latter a basic knowledge of ABI rather than an > > intimate. For me programming feels uncomfortable without such > > knowledge. That is, I can manage without, but do not want to. > > Your mileage appears to vary. > I've spent most of my career working under rules that explicitly > prohibited me from writing code that depends upon such details. As a > result, I actually have relatively little knowledge of how any > particular implementation of C that I used decided to handle issues > that the C standard left unspecified. I've always written my code so > that it would do what it's supposed to do, regardless of which > choices any given implementation made about things that are > unspecified. > I don't have a lot of 1st hand experience of porting code between seriously diverse systems. From the people that have such experience I always hear the same thing: portability of program that was never actually ported is an illusion. Fine details of sort that we discuss in this subthread are rather small part of the reason behind it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-01-11 11:58 -0800 |
| Message-ID | <86v7h7ly4o.fsf@linuxsc.com> |
| In reply to | #396342 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Michael S <already5chosen@yahoo.com> writes: > >> On Sat, 10 Jan 2026 22:02:03 -0500 >> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: >> >>> On 2026-01-09 07:18, Michael S wrote: >>> >>>> On Thu, 8 Jan 2026 19:31:13 -0500 >>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: >>> >>> ... >>> >>>>> I'd have no problem with your approach if you hadn't falsely >>>>> claimed that "It is correct on all platforms". >>>> >>>> Which I didn't. >>> >>> On 2026-01-07 19:38, Michael S wrote: >>> ... >>> >>>> No, it is correct on all implementation. >> >> The quote is taken out of context. >> The context was that on platforms that have properties (a) and (b) (see >> below) printing variables declared as uint32_t via %u is probably UB >> according to the Standard (I don't know for sure, however it is >> probable), > > I'm sure. uint32_t is an alias for some predefined integer type. Very likely, but I don't think the C standard requires it. TTBOMU the C standard allows the possibility of an implementation where uint32_t is type distinct from any other nameable type, and yet the implementation could still be conforming.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-12 08:28 +0100 |
| Message-ID | <10k27qn$25sqv$2@dont-email.me> |
| In reply to | #396350 |
On 11/01/2026 20:58, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Sat, 10 Jan 2026 22:02:03 -0500 >>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: >>> >>>> On 2026-01-09 07:18, Michael S wrote: >>>> >>>>> On Thu, 8 Jan 2026 19:31:13 -0500 >>>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: >>>> >>>> ... >>>> >>>>>> I'd have no problem with your approach if you hadn't falsely >>>>>> claimed that "It is correct on all platforms". >>>>> >>>>> Which I didn't. >>>> >>>> On 2026-01-07 19:38, Michael S wrote: >>>> ... >>>> >>>>> No, it is correct on all implementation. >>> >>> The quote is taken out of context. >>> The context was that on platforms that have properties (a) and (b) (see >>> below) printing variables declared as uint32_t via %u is probably UB >>> according to the Standard (I don't know for sure, however it is >>> probable), >> >> I'm sure. uint32_t is an alias for some predefined integer type. > > Very likely, but I don't think the C standard requires it. TTBOMU > the C standard allows the possibility of an implementation where > uint32_t is type distinct from any other nameable type, and yet > the implementation could still be conforming. gcc for the AVR (or more accurately, the avrlibc library for the AVR port of gcc) defines the various <stdint.h> types as "int" or "unsigned int" with special modes giving their lengths (using a gcc-specific extension). I am never quite sure about the compatibility of these types and other identically sized integer types.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-01-11 11:51 -0800 |
| Message-ID | <86zf6kkjw0.fsf@linuxsc.com> |
| In reply to | #396341 |
Michael S <already5chosen@yahoo.com> writes: > On Sat, 10 Jan 2026 22:02:03 -0500 > "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: > >> On 2026-01-09 07:18, Michael S wrote: >> >>> On Thu, 8 Jan 2026 19:31:13 -0500 >>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: >> >> ... >> >>>> I'd have no problem with your approach if you hadn't falsely >>>> claimed that "It is correct on all platforms". >>> >>> Which I didn't. >> >> On 2026-01-07 19:38, Michael S wrote: >> ... >> >>> No, it is correct on all implementation. >> > > The quote is taken out of context. > The context was that on platforms that have properties (a) and (b) (see > below) printing variables declared as uint32_t via %u is probably UB > according to the Standard (I don't know for sure, however it is > probable), but it can't cause troubles with production C compiler. Or > with any C compiler that is made in intention of being used rather than > crafted to prove theoretical points. > Properties are: > a) uint32_t aliased to 'unsigned long' > b) 'unsigned int' is at least 32-bit wide. It seems unlikely that any implementation would make such a choice. Can you name one that does?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-11 23:51 +0200 |
| Message-ID | <20260111235104.00001463@yahoo.com> |
| In reply to | #396349 |
On Sun, 11 Jan 2026 11:51:43 -0800 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Sat, 10 Jan 2026 22:02:03 -0500 > > "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: > > > >> On 2026-01-09 07:18, Michael S wrote: > >> > >>> On Thu, 8 Jan 2026 19:31:13 -0500 > >>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> > >>> wrote: > >> > >> ... > >> > >>>> I'd have no problem with your approach if you hadn't falsely > >>>> claimed that "It is correct on all platforms". > >>> > >>> Which I didn't. > >> > >> On 2026-01-07 19:38, Michael S wrote: > >> ... > >> > >>> No, it is correct on all implementation. > >> > > > > The quote is taken out of context. > > The context was that on platforms that have properties (a) and (b) > > (see below) printing variables declared as uint32_t via %u is > > probably UB according to the Standard (I don't know for sure, > > however it is probable), but it can't cause troubles with > > production C compiler. Or with any C compiler that is made in > > intention of being used rather than crafted to prove theoretical > > points. Properties are: > > a) uint32_t aliased to 'unsigned long' > > b) 'unsigned int' is at least 32-bit wide. > > It seems unlikely that any implementation would make such a > choice. Can you name one that does? Four out of four target for which I write C programs for living in this decade: - Altera Nios2 (nios2-elf-gcc) - Arm Cortex-M bare metal (arm-none-eabi-gcc) - Win32-i386, various compilers - Win64-Amd64,various compilers Well, if I would be pedantic, then in this decade I also wrote several programs for Arm32 Linux, where I don't know whether uint32_t is alias of 'unsigned int' or 'unsigned long', few programs for AMD64 Linux, where I know that uint32_t is an alias of 'unsigned long' and may be one program for ARM64 Linux that is the same as AMD64 Linux. But all those outliers together constitute a tiny fraction of the code that I wrote recently.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-11 22:47 -0800 |
| Message-ID | <874iorqqcz.fsf@example.invalid> |
| In reply to | #396352 |
Michael S <already5chosen@yahoo.com> writes:
> On Sun, 11 Jan 2026 11:51:43 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Michael S <already5chosen@yahoo.com> writes:
[...]
>> > Properties are:
>> > a) uint32_t aliased to 'unsigned long'
>> > b) 'unsigned int' is at least 32-bit wide.
>>
>> It seems unlikely that any implementation would make such a
>> choice. Can you name one that does?
>
> Four out of four target for which I write C programs for living in this
> decade:
> - Altera Nios2 (nios2-elf-gcc)
> - Arm Cortex-M bare metal (arm-none-eabi-gcc)
> - Win32-i386, various compilers
> - Win64-Amd64,various compilers
I find that surprising. I just tried a test program that prints
the name of the type uint32_t is an alias for (using _Generic),
and it's alias to unsigned int on every implementation I tried.
(Your properties are limited to systems with 32-bit int and long.)
For an implementation where int and long are both 32 bits, it
wouldn't have surprised me for uint32_t to be an alias either for
unsigned int or for unsigned long, and I wouldn't care either way
beyond idle curiosity, but all the implementations I've tried choose
to use unsigned int.
> Well, if I would be pedantic, then in this decade I also wrote several
> programs for Arm32 Linux, where I don't know whether uint32_t is alias
> of 'unsigned int' or 'unsigned long', few programs for AMD64 Linux,
> where I know that uint32_t is an alias of 'unsigned long' and may be one
> program for ARM64 Linux that is the same as AMD64 Linux.
> But all those outliers together constitute a tiny fraction of the code
> that I wrote recently.
One advantage of my approach is that I don't have to know or care
what the underlying type of uint32_t is.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web