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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-09 11:27 -0800 |
| Message-ID | <87pl7ioac9.fsf@example.invalid> |
| In reply to | #396324 |
wij <wyniijj5@gmail.com> writes:
> On Fri, 2026-01-09 at 13:49 +0100, David Brown wrote:
[...]
>> I have a lot of trouble understanding why you would go out of your way
>> to knowingly write incorrect code - prioritising tiny, irrelevant
>> savings in source code space over correct, guaranteed, portable code
>> that can be automatically checked by tools.
>
> Snipet from ClassGuidelines.txt
> ...
> wrd(or notation)
> This function converts the argument object (a type, class,..) to text
[SNIP]
> My reply might not be directly in the topic of current post. Just jumpped in
> to reply.
Huh?? "ClassGuideline.txt" (which I managed to find on Sourceforge)
is a set of guidelines for C++ programming, apparently something
you wrote. As far as I can tell, it has nothing to do with the
current discussion or with the topic of this newsgroup. Why did
you mention it here?
> It looks to me the format character MUST match the type passed to
> printf, otherwise UB.
It doesn't just look to you that way. The C standard says
so explicitly. C17 and earlier says "If any argument is not
the correct type for the corresponding conversion specification,
the behavior is undefined." C23 changed the wording, saying that
fprintf shall behave as if it uses va_arg; the description of va_arg
says the behavior is undefined if the wrong type is used.
Note that the description of va_arg allows, for example, using
unsigned int for an argument of type int or vice versa *if* the
value is within the range of both. If it had been the intent to
allow incompatible types that happen to have the same size and
representation, the standard would have said so.
--
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 | "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-10 22:02 -0500 |
| Message-ID | <10jv3rb$15aea$2@dont-email.me> |
| In reply to | #396319 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-11 13:20 +0200 |
| Message-ID | <20260111132015.000026ad@yahoo.com> |
| In reply to | #396337 |
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. I never claimed that it is good idea on targets with 'unsigned int' that is narrower.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-11 04:59 -0800 |
| Message-ID | <87ikd82tks.fsf@example.invalid> |
| 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),
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".)
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.
> 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'
Not guaranteed by the language (and not true on the implementations
I use most often).
> b) 'unsigned int' is at least 32-bit wide.
Not guaranteed by the language (though it happens to be guaranteed by
POSIX).
> I never claimed that it is good idea on targets with 'unsigned int'
> that is narrower.
I claim that it's not a good idea on any target.
I find it *much* easier to write portable code than to spend time
figuring out what non-portable code will happens to work on the
platforms I happen to care about today.
uint32_t n = 42;
printf("%lu\n", (unsigned long)n);
unsigned long is guaranteed by the language to be at least 32 bits.
The conversion is guaranteed not to lose information. The format
matches the type of the argument. And the code will work correctly
on any conforming hosted implementation. (It might involve an
unnecessary 32 to 64 bit conversion, but given the overhead of
printf, that's unlikely to be a problem -- and if it is, I can use
the appropriate macro from <inttypes.h>.)
And to my eyes, using "%u" with a uint32_t argument is *ugly*.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-11 15:32 +0200 |
| Message-ID | <20260111153201.000075f9@yahoo.com> |
| In reply to | #396342 |
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?
> 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.
> > 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'
>
> Not guaranteed by the language (and not true on the implementations
> I use most often).
>
Did I ever say that it is guaranteed by the language or that it is
universal in any other way?
Normally you have much better reading comprehension than one that you
demonstrate in this discussion. I'd guess that it's because I somehow
caused you to become angry.
> > b) 'unsigned int' is at least 32-bit wide.
>
> Not guaranteed by the language (though it happens to be guaranteed by
> POSIX).
>
Did I ever say etc ...
> > I never claimed that it is good idea on targets with 'unsigned int'
> > that is narrower.
>
> I claim that it's not a good idea on any target.
>
> I find it *much* easier to write portable code than to spend time
> figuring out what non-portable code will happens to work on the
> platforms I happen to care about today.
>
> uint32_t n = 42;
> printf("%lu\n", (unsigned long)n);
>
> unsigned long is guaranteed by the language to be at least 32 bits.
> The conversion is guaranteed not to lose information. The format
> matches the type of the argument. And the code will work correctly
> on any conforming hosted implementation. (It might involve an
> unnecessary 32 to 64 bit conversion, but given the overhead of
> printf, that's unlikely to be a problem -- and if it is, I can use
> the appropriate macro from <inttypes.h>.)
>
> And to my eyes, using "%u" with a uint32_t argument is *ugly*.
>
To be fair, it is not ideal.
The solution that I would prefer would be universal adaption of
Microsoft's size specifiers I32 and I64. They are not going to win
beauty competition, but in practice they are a lot more convenient to
use than standard macros and are equally good at carrying programmer's
intentions.
Microsoft has strong influence in committee, but was not able to push
it into C11, where they successfully forced hands of other members on
few much bigger and more controversial issues.
I don't know what it means, May be, there is bold technical reason
behind non-standardization of these size specifiers. Or may be there is
no reason and Microsoft simply never tried.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-11 16:34 +0100 |
| Message-ID | <af157a6f-d436-4e1f-aa27-8e028761440c@hesbynett.no> |
| In reply to | #396343 |
On 11/01/2026 14: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?
If an architecture has 32-bit "unsigned long", then "unsigned int" is
necessarily also 32-bit (since "unsigned int" is always at least 32-bit,
and "unsigned long" cannot be smaller than "unsigned int"). The very
fact that you listed "unsigned int is at least 32-bit wide" as an
assumption shows you are not well versed with the basics of C standards
in this area.
I agree that it is difficult to imagine an implementation where
"uint32_t" is "unsigned long" and where the code example you gave would
not work as expected. But there are countless cases where C programmers
have thought "it doesn't matter if this is UB, the compiler can't
generate code other than the way I think it should". Could some future
implementation on some future architecture do something I don't expect
with the code example here? I am not willing to bet against that
possibility - certainly not for something as petty as skipping a single
letter in the source code.
But to my mind, the prime disadvantage of writing this incorrect code
(besides portability, which is not always a big concern) is that you
block important and useful automated checks. That's just bad
development practice. Don't worry about compiler maintainers getting
fired for doing crazy things - worry about C programmers getting fired
for doing crazy things. (I wouldn't immediately fire someone for
writing code like this, but I'd reject it in a code review, and I'd have
serious concerns about a programmer who knowingly wrote UB without
vastly better justification than you have.)
>
>> 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.
Writing code that is UB but "works as intended" /does/ require an and
rely upon an intimate knowledge of the ABI. You are saying this works
precisely because you know things about the ABI you are using. Writing
correct code will keep it portable and working regardless of the ABI.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-11 18:19 +0200 |
| Message-ID | <20260111181945.00003052@yahoo.com> |
| In reply to | #396344 |
On Sun, 11 Jan 2026 16:34:28 +0100
David Brown <david.brown@hesbynett.no> wrote:
> On 11/01/2026 14: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?
>
> If an architecture has 32-bit "unsigned long", then "unsigned int" is
> necessarily also 32-bit (since "unsigned int" is always at least
> 32-bit,
I am pretty sure that it is wrong.
C Standard does not require for 'unsigned int' to be above 16 bits.
> and "unsigned long" cannot be smaller than "unsigned int").
> The very fact that you listed "unsigned int is at least 32-bit wide"
> as an assumption shows you are not well versed with the basics of C
> standards in this area.
>
I am not well versed in the Standard. But in this particular case you
are the one who doesn't know it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-11 20:25 +0100 |
| Message-ID | <10k0tf8$4v6l$1@dont-email.me> |
| In reply to | #396345 |
On 11/01/2026 17:19, Michael S wrote:
> On Sun, 11 Jan 2026 16:34:28 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 11/01/2026 14: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?
>>
>> If an architecture has 32-bit "unsigned long", then "unsigned int" is
>> necessarily also 32-bit (since "unsigned int" is always at least
>> 32-bit,
>
> I am pretty sure that it is wrong.
> C Standard does not require for 'unsigned int' to be above 16 bits.
>
Sorry, I jumbled that. It is unsigned long that must be at least 32
bits, so your second requirement is not redundant.
>> and "unsigned long" cannot be smaller than "unsigned int").
>> The very fact that you listed "unsigned int is at least 32-bit wide"
>> as an assumption shows you are not well versed with the basics of C
>> standards in this area.
>>
>
> I am not well versed in the Standard. But in this particular case you
> are the one who doesn't know it.
>
I know it, but I still got it wrong here :-(
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-11 15:23 -0800 |
| Message-ID | <87y0m368eg.fsf@example.invalid> |
| In reply to | #396343 |
Michael S <already5chosen@yahoo.com> writes:
> 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?
Most likely nothing. The behavior is undefined, so the standard places
no requirement on implementations either to make it work as some might
expect or to make it fail in some way.
Both gcc and clang will issue compile-time warnings for mismatched
format strings. They do so only if the format string is a string
literal (or perhaps in other cases where the format string is known at
compile time).
>> 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.
So you're unwilling to assume that passing a 32-bit argument while
telling printf to expect a 64-bit argument. Good for you, seriously.
But you're willing to assume that it's ok if the argument and format
string specify different 32-bit types. I'm not.
>> > 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'
>>
>> Not guaranteed by the language (and not true on the implementations
>> I use most often).
>
> Did I ever say that it is guaranteed by the language or that it is
> universal in any other way?
> Normally you have much better reading comprehension than one that you
> demonstrate in this discussion. I'd guess that it's because I somehow
> caused you to become angry.
Let's not make this personal. I don't want to get into an argument
about reading comprehension, but I'll point out that I didn't say that
you said that it's guaranteed by the language. Not everything I write
in a followup is a refutation of what was written in the previous article.
Sometimes I'm simply adding more information.
[...]
>> > I never claimed that it is good idea on targets with 'unsigned int'
>> > that is narrower.
>>
>> I claim that it's not a good idea on any target.
>>
>> I find it *much* easier to write portable code than to spend time
>> figuring out what non-portable code will happens to work on the
>> platforms I happen to care about today.
>>
>> uint32_t n = 42;
>> printf("%lu\n", (unsigned long)n);
>>
>> unsigned long is guaranteed by the language to be at least 32 bits.
>> The conversion is guaranteed not to lose information. The format
>> matches the type of the argument. And the code will work correctly
>> on any conforming hosted implementation. (It might involve an
>> unnecessary 32 to 64 bit conversion, but given the overhead of
>> printf, that's unlikely to be a problem -- and if it is, I can use
>> the appropriate macro from <inttypes.h>.)
>>
>> And to my eyes, using "%u" with a uint32_t argument is *ugly*.
>
> To be fair, it is not ideal.
> The solution that I would prefer would be universal adaption of
> Microsoft's size specifiers I32 and I64. They are not going to win
> beauty competition, but in practice they are a lot more convenient to
> use than standard macros and are equally good at carrying programmer's
> intentions.
The relative beauty of a feature that isn't available hardly seems
relevant.
The ideal solution is to write correct, and preferably portable,
code in the first place. There are often good reasons to write
non-portable code, but I suggest that fiding the correct format
string to be ugly is not one of them.
(Microsoft's documentation says that "I32" prefix applies to an
argument of type __int32 or unsigned __int32. I don't know whether
__int32 is compatible with int, with long, or neither, and I don't
much care. I don't know what Microsoft guarantees about printf
with incompatible types that happen to have the same size.)
> Microsoft has strong influence in committee, but was not able to push
> it into C11, where they successfully forced hands of other members on
> few much bigger and more controversial issues.
> I don't know what it means, May be, there is bold technical reason
> behind non-standardization of these size specifiers. Or may be there is
> no reason and Microsoft simply never tried.
If I write code that depends on assumptions about the current
platform, it still might not work for some possibly unrelated reason.
If I write portable code in the first place and something goes
wrong, I have one less thing to worry about as a possible cause of
the error.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-12 10:50 +0200 |
| Message-ID | <20260112105010.00004fcc@yahoo.com> |
| In reply to | #396355 |
On Sun, 11 Jan 2026 15:23:35 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > > To be fair, it is not ideal. > > The solution that I would prefer would be universal adaption of > > Microsoft's size specifiers I32 and I64. They are not going to win > > beauty competition, but in practice they are a lot more convenient > > to use than standard macros and are equally good at carrying > > programmer's intentions. > > The relative beauty of a feature that isn't available hardly seems > relevant. > > The ideal solution is to write correct, and preferably portable, > code in the first place. There are often good reasons to write > non-portable code, but I suggest that fiding the correct format > string to be ugly is not one of them. > > (Microsoft's documentation says that "I32" prefix applies to an > argument of type __int32 or unsigned __int32. I don't know whether > __int32 is compatible with int, with long, or neither, and I don't > much care. I don't know what Microsoft guarantees about printf > with incompatible types that happen to have the same size.) > Microsoft guarantees that __int32 is compatible with int32_t and that 'unsigned __int32' is compatible with uint32_t. The same goes for 64-bit types. That's sufficient for safe use of format specifier "%I32u" when printing uint32_t variables.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-11 14:56 -0800 |
| Message-ID | <87ecnv3gj2.fsf@example.invalid> |
| In reply to | #396343 |
Michael S <already5chosen@yahoo.com> writes:
> 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?
Most likely nothing. The behavior is undefined, so the standard places
no requirement on implementations either to make it work as some might
expect or to make it fail in some way.
Both gcc and clang will issue compile-time warnings for mismatched
format strings. They do so only if the format string is a string
literal (or perhaps in other cases where the format string is known at
compile time).
>> 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.
So you're unwilling to assume that passing a 32-bit argument while
telling printf to expect a 64-bit argument. Good for you, seriously.
But you're willing to assume that it's ok if the argument and format
string specify different 32-bit types. I'm not.
>> > 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'
>>
>> Not guaranteed by the language (and not true on the implementations
>> I use most often).
>
> Did I ever say that it is guaranteed by the language or that it is
> universal in any other way?
> Normally you have much better reading comprehension than one that you
> demonstrate in this discussion. I'd guess that it's because I somehow
> caused you to become angry.
Let's not make this personal. I don't want to get into an argument
about reading comprehension, but I'll point out that I didn't say that
you said that it's guaranteed by the language. Not everything I write
in a followup is a refutation of what was written in the previous article.
Sometimes I'm simply adding more information.
[...]
>> > I never claimed that it is good idea on targets with 'unsigned int'
>> > that is narrower.
>>
>> I claim that it's not a good idea on any target.
>>
>> I find it *much* easier to write portable code than to spend time
>> figuring out what non-portable code will happens to work on the
>> platforms I happen to care about today.
>>
>> uint32_t n = 42;
>> printf("%lu\n", (unsigned long)n);
>>
>> unsigned long is guaranteed by the language to be at least 32 bits.
>> The conversion is guaranteed not to lose information. The format
>> matches the type of the argument. And the code will work correctly
>> on any conforming hosted implementation. (It might involve an
>> unnecessary 32 to 64 bit conversion, but given the overhead of
>> printf, that's unlikely to be a problem -- and if it is, I can use
>> the appropriate macro from <inttypes.h>.)
>>
>> And to my eyes, using "%u" with a uint32_t argument is *ugly*.
>
> To be fair, it is not ideal.
> The solution that I would prefer would be universal adaption of
> Microsoft's size specifiers I32 and I64. They are not going to win
> beauty competition, but in practice they are a lot more convenient to
> use than standard macros and are equally good at carrying programmer's
> intentions.
The relative beauty of a feature that isn't available hardly seems
relevant.
The ideal solution is to write correct, and preferably portable,
code in the first place. There are often good reasons to write
non-portable code, but I suggest that fiding the correct format
string to be ugly is not one of them.
(Microsoft's documentation says that "I32" prefix applies to an
argument of type __int32 or unsigned __int32. I don't know whether
__int32 is compatible with int, with long, or neither, and I don't
much care. I don't know what Microsoft guarantees about printf
with incompatible types that happen to have the same size.)
> Microsoft has strong influence in committee, but was not able to push
> it into C11, where they successfully forced hands of other members on
> few much bigger and more controversial issues.
> I don't know what it means, May be, there is bold technical reason
> behind non-standardization of these size specifiers. Or may be there is
> no reason and Microsoft simply never tried.
If I write code that depends on assumptions about the current
platform, it still might not work for some reason. If I write
portable code in the first place and something goes wrong, I have
one less thing to worry about as a possible cause of the error.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-11 22:44 -0800 |
| Message-ID | <878qe3qqi9.fsf@example.invalid> |
| In reply to | #396356 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Michael S <already5chosen@yahoo.com> writes:
[...]
>> I mean short of completely crazy things that will make maintainer
>> immediately fired?
>
> Most likely nothing.
[...]
Sorry about the duplicate post (server problems).
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-12 10:51 +0200 |
| Message-ID | <20260112105143.00002ce6@yahoo.com> |
| In reply to | #396357 |
On Sun, 11 Jan 2026 22:44:30 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > > Michael S <already5chosen@yahoo.com> writes: > [...] > >> I mean short of completely crazy things that will make maintainer > >> immediately fired? > > > > Most likely nothing. > [...] > > Sorry about the duplicate post (server problems). > I had my comp.arch post triplicated for the same reason.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-12 08:21 +0100 |
| Message-ID | <10k27e7$25sqv$1@dont-email.me> |
| In reply to | #396356 |
On 11/01/2026 23:56, Keith Thompson wrote: > Michael S <already5chosen@yahoo.com> writes: >> The solution that I would prefer would be universal adaption of >> Microsoft's size specifiers I32 and I64. They are not going to win >> beauty competition, but in practice they are a lot more convenient to >> use than standard macros and are equally good at carrying programmer's >> intentions. > > The relative beauty of a feature that isn't available hardly seems > relevant. > > The ideal solution is to write correct, and preferably portable, > code in the first place. There are often good reasons to write > non-portable code, but I suggest that fiding the correct format > string to be ugly is not one of them. > > (Microsoft's documentation says that "I32" prefix applies to an > argument of type __int32 or unsigned __int32. I don't know whether > __int32 is compatible with int, with long, or neither, and I don't > much care. I don't know what Microsoft guarantees about printf > with incompatible types that happen to have the same size.) > 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, and should also be fully defined behaviour for unsigned int and unsigned long if these are 32 bits wide.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-12 11:06 +0200 |
| Message-ID | <20260112110648.00002626@yahoo.com> |
| In reply to | #396361 |
On Mon, 12 Jan 2026 08:21:43 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 11/01/2026 23:56, Keith Thompson wrote: > > Michael S <already5chosen@yahoo.com> writes: > > >> The solution that I would prefer would be universal adaption of > >> Microsoft's size specifiers I32 and I64. They are not going to win > >> beauty competition, but in practice they are a lot more convenient > >> to use than standard macros and are equally good at carrying > >> programmer's intentions. > > > > The relative beauty of a feature that isn't available hardly seems > > relevant. > > > > The ideal solution is to write correct, and preferably portable, > > code in the first place. There are often good reasons to write > > non-portable code, but I suggest that fiding the correct format > > string to be ugly is not one of them. > > > > (Microsoft's documentation says that "I32" prefix applies to an > > argument of type __int32 or unsigned __int32. I don't know whether > > __int32 is compatible with int, with long, or neither, and I don't > > much care. I don't know what Microsoft guarantees about printf > > with incompatible types that happen to have the same size.) > > > > 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, > and should also be fully defined behaviour for unsigned int and > unsigned long if these are 32 bits wide. > It sounds very good. Except that none of my four targets of major interest supports C23 at the moment. Esp. so at the level of standard library. For one of them (Nios2) in the absence of something VERY unexpected there never be support (gcc stopped support for Nios2 2 or 3 years ago). For the other three, it will take time. I can't even guess how long, except that I know that support versions of arm-none-eabi-gcc lags two years behind "hosted" x86-64 and ARM64 versions, so I can guess that it would take significant time to catch up.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-12 13:26 +0100 |
| Message-ID | <10k2pa0$2al6k$1@dont-email.me> |
| In reply to | #396367 |
On 12/01/2026 10:06, Michael S wrote: > On Mon, 12 Jan 2026 08:21:43 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> On 11/01/2026 23:56, Keith Thompson wrote: >>> Michael S <already5chosen@yahoo.com> writes: >> >>>> The solution that I would prefer would be universal adaption of >>>> Microsoft's size specifiers I32 and I64. They are not going to win >>>> beauty competition, but in practice they are a lot more convenient >>>> to use than standard macros and are equally good at carrying >>>> programmer's intentions. >>> >>> The relative beauty of a feature that isn't available hardly seems >>> relevant. >>> >>> The ideal solution is to write correct, and preferably portable, >>> code in the first place. There are often good reasons to write >>> non-portable code, but I suggest that fiding the correct format >>> string to be ugly is not one of them. >>> >>> (Microsoft's documentation says that "I32" prefix applies to an >>> argument of type __int32 or unsigned __int32. I don't know whether >>> __int32 is compatible with int, with long, or neither, and I don't >>> much care. I don't know what Microsoft guarantees about printf >>> with incompatible types that happen to have the same size.) >>> >> >> 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, >> and should also be fully defined behaviour for unsigned int and >> unsigned long if these are 32 bits wide. >> > > It sounds very good. > > Except that none of my four targets of major interest supports C23 at > the moment. Esp. so at the level of standard library. > 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.) It is an unfortunate fact of developers' lives that we see fun new features in new language standards, but often have to wait years before we can play with them. > For one of them (Nios2) in the absence of something VERY unexpected > there never be support (gcc stopped support for Nios2 2 or 3 years ago). > > For the other three, it will take time. I can't even guess how long, > except that I know that support versions of arm-none-eabi-gcc lags two > years behind "hosted" x86-64 and ARM64 versions, so I can guess that it > would take significant time to catch up. > ARM's gcc-based toolchain builds are not nearly as far behind as they used to be. They have pretty much caught up to current stable gcc releases. <https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-12 16:06 -0800 |
| Message-ID | <87h5sqpea7.fsf@example.invalid> |
| In reply to | #396370 |
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.
gcc has had format checking for %wN and %wfN since release 13, but
that's useless in the absence of library support.
Support in glibc was added 2023-06-19 and released in version 2.39.
Other C library implementations may or may not support it.
[...]
--
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-13 08:56 +0100 |
| Message-ID | <10k4trt$2vi9p$1@dont-email.me> |
| In reply to | #396381 |
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.
>
> gcc has had format checking for %wN and %wfN since release 13, but
> that's useless in the absence of library support.
Yes.
>
> Support in glibc was added 2023-06-19 and released in version 2.39.
> Other C library implementations may or may not support it.
>
glibc is not particularly relevant for non-Linux embedded systems.
newlib (and newlib-nano) are a common choice for such systems, but I
have no idea if it currently has support for those formats.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-13 00:53 -0800 |
| Message-ID | <87cy3dq4fj.fsf@example.invalid> |
| In reply to | #396385 |
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.
>> gcc has had format checking for %wN and %wfN since release 13, but
>> that's useless in the absence of library support.
>
> Yes.
>
>> Support in glibc was added 2023-06-19 and released in version 2.39.
>> Other C library implementations may or may not support it.
>
> glibc is not particularly relevant for non-Linux embedded
> systems. newlib (and newlib-nano) are a common choice for such
> systems, but I have no idea if it currently has support for those
> formats.
Of course, that's why I mentioned other C library implementations.
glibc happens to be the one about which I had some relevant
information.
The versions of musl and dietlibc that I have on my Ubuntu system
don't support %wN. The version of newlib I have on Cygwin also
doesn't support it. PellesC on Windows does.
--
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-13 11:09 +0100 |
| Message-ID | <10k55lj$31r42$1@dont-email.me> |
| In reply to | #396387 |
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). But I had not intended it to be the focus, since
library support is the critical point. (newlibc, as far as I can tell,
does not yet support it.)
>>> gcc has had format checking for %wN and %wfN since release 13, but
>>> that's useless in the absence of library support.
>>
>> Yes.
>>
>>> Support in glibc was added 2023-06-19 and released in version 2.39.
>>> Other C library implementations may or may not support it.
>>
>> glibc is not particularly relevant for non-Linux embedded
>> systems. newlib (and newlib-nano) are a common choice for such
>> systems, but I have no idea if it currently has support for those
>> formats.
>
> Of course, that's why I mentioned other C library implementations.
> glibc happens to be the one about which I had some relevant
> information.
>
Fair enough.
> The versions of musl and dietlibc that I have on my Ubuntu system
> don't support %wN. The version of newlib I have on Cygwin also
> doesn't support it. PellesC on Windows does.
>
musl and dietlibc are not suitable for non-Linux embedded systems
either, but of course it is nice to see the progress of support in
different libraries for different systems. (And newlibc doesn't support
it yet - at least, not according to the online documentation.)
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web