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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-01-08 13:05 -0800 |
| Message-ID | <86v7hbn7cc.fsf@linuxsc.com> |
| In reply to | #396306 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> writes: >> >>> On 2026-01-07 08:06, Tim Rentsch wrote: >>> >>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>> >>>>> Michael S <already5chosen@yahoo.com> writes: >>>>> >>>>>> On Tue, 6 Jan 2026 10:31:41 -0500 >>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>>>>> >>>>>>> If you know that an expression has one of the standard-named >>>>>>> types or typedefs for with there is a corresponding printf() >>>>>>> specifier, you should use that specifier. Otherwise, if you >>>>>>> know that an expression has one of the types declared in >>>>>>> <stdint.h>, you should use the corresponding macro #defined in >>>>>>> <inttypes.h> to print it. >>>>>> >>>>>> I should? Really? >>>>>> Sorry, James, but you have no authority to make such statements. >>>>> >>>>> James is paraphrasing the C standard. >>>> >>>> Really? What passage in the C standard is being paraphrased? >>> >>> This is advice, not paraphrased text from the C standard. [...] >> >> I was responding to Scotty Lurndal's statement that the C >> standard was being paraphrased (by someone, it didn't matter to >> me who). I don't care about whether his statement is true; my >> interest is only in what part of the C standard he thinks is >> being paraphrased. He is in a position to answer that question, >> and more to the point he is the only person who is. > > It's pretty clear that the standard describes the printf > function and the methods used to match the format characters > to the data types of the arguments. The fact that James > framed that as advice doesn't change interpretation of > the text of the standard, whether or not you consider > that to be a paraphrase. > > > "The main rules for paraphrasing are to fully understand the > original text, restate its core idea in your own words and > sentence structure, use synonyms, and always cite the original > source to avoid plagiarism, even if the wording is different. I see where the C standard says the macros in inttypes.h are suitable for use with printf (and scanf). That isn't at all the same as saying people should use them. Just because something can be done doesn't mean it should be done. James's statement "you should use the corresponding macro" is not a paraphrase, it's a statement of his opinion. > And it is spelled "Scott". Yes, that was an inadvertent typo, and I had already posted a correction.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-01-09 16:26 +0000 |
| Message-ID | <e%98R.944798$PGrb.631504@fx10.iad> |
| In reply to | #396309 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>> I was responding to Scotty Lurndal's statement that the C >>> standard was being paraphrased (by someone, it didn't matter to >>> me who). I don't care about whether his statement is true; my >>> interest is only in what part of the C standard he thinks is >>> being paraphrased. He is in a position to answer that question, >>> and more to the point he is the only person who is. >> >> It's pretty clear that the standard describes the printf >> function and the methods used to match the format characters >> to the data types of the arguments. The fact that James >> framed that as advice doesn't change interpretation of >> the text of the standard, whether or not you consider >> that to be a paraphrase. >> >> >> "The main rules for paraphrasing are to fully understand the >> original text, restate its core idea in your own words and >> sentence structure, use synonyms, and always cite the original >> source to avoid plagiarism, even if the wording is different. > >I see where the C standard says the macros in inttypes.h are >suitable for use with printf (and scanf). That isn't at all >the same as saying people should use them. Why on earth would the put them there if they didn't expect them to be used? > Just because >something can be done doesn't mean it should be done. Sigh.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-02-03 05:38 -0800 |
| Message-ID | <86qzr2hrqe.fsf@linuxsc.com> |
| In reply to | #396325 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >>>> >>>> I was responding to Scotty Lurndal's statement that the C >>>> standard was being paraphrased (by someone, it didn't matter to >>>> me who). I don't care about whether his statement is true; my >>>> interest is only in what part of the C standard he thinks is >>>> being paraphrased. He is in a position to answer that question, >>>> and more to the point he is the only person who is. >>> >>> It's pretty clear that the standard describes the printf >>> function and the methods used to match the format characters >>> to the data types of the arguments. The fact that James >>> framed that as advice doesn't change interpretation of >>> the text of the standard, whether or not you consider >>> that to be a paraphrase. >>> >>> >>> "The main rules for paraphrasing are to fully understand the >>> original text, restate its core idea in your own words and >>> sentence structure, use synonyms, and always cite the original >>> source to avoid plagiarism, even if the wording is different. >> >> I see where the C standard says the macros in inttypes.h are >> suitable for use with printf (and scanf). That isn't at all >> the same as saying people should use them. > > Why on earth would the put them there if they didn't expect > them to be used? Expecting they will be used in some cases is different than saying they should be used in all cases.
[toc] | [prev] | [next] | [standalone]
| From | "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-10 22:40 -0500 |
| Message-ID | <10jv63u$15aeb$3@dont-email.me> |
| In reply to | #396306 |
On 2026-01-08 13:36, Scott Lurndal wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> writes: >> >>> On 2026-01-07 08:06, Tim Rentsch wrote: >>> >>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>> >>>>> Michael S <already5chosen@yahoo.com> writes: >>>>> >>>>>> On Tue, 6 Jan 2026 10:31:41 -0500 >>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>>>>> >>>>>>> If you know that an expression has one of the standard-named types or >>>>>>> typedefs for with there is a corresponding printf() specifier, you >>>>>>> should use that specifier. Otherwise, if you know that an expression >>>>>>> has one of the types declared in <stdint.h>, you should use the >>>>>>> corresponding macro #defined in <inttypes.h> to print it. ... >>>>> James is paraphrasing the C standard. ... > It's pretty clear that the standard describes the printf > function and the methods used to match the format characters > to the data types of the arguments. The fact that James > framed that as advice doesn't change interpretation of > the text of the standard, whether or not you consider > that to be a paraphrase. I was advising against the practice of finding out what type uint32_t is a typedef for on the implementation you're currently using, and using the corresponding format specifier rather than the appropriate <inttypes.h> macro. For any given implementation, those will both work equally well, and nothing the standard says favors one over the other. It is the fact that I have, for most of my career, been required to produce highly portable code, which makes me prefer the ugly macros over the simpler specifiers. That is not, in any sense, a paraphrase of anything said in the standard. It is a deduction from what the standard says, applied to my particular working environment. What I didn't notice when I made my original comment is that he wasn't even using the appropriate format specifier, which would have been %lu, but %u, simply because, on the platform he was using, they happened to work equally well.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-06 16:29 -0800 |
| Message-ID | <87h5sy2rlb.fsf@example.invalid> |
| In reply to | #396225 |
Michael S <already5chosen@yahoo.com> writes:
> On Tue, 6 Jan 2026 10:31:41 -0500
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 2026-01-06 04:29, Michael S wrote:
>> > On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
>> > Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>> ...
>> >> Section 7.8 of the C spec defines macros you can use so you don’t
>> >> have to hard-code assumptions about the lengths of integers in
>> >> printf-format strings.
>> >
>> > Did you ever try to use them? They look ugly.
>>
>> Which is more important, correctness or beauty?
>
> It depends.
>
> When I know for sure that incorrectness has no consequences, like
> in case of using %u to print 'unsigned long' on target with 32-bit
> longs, or like using %llu to print 'unsigned long' on target with
> 64-bit longs, then beauty wins. Easily.
Seriously?
An example:
unsigned long n = 42;
printf("%u\n", n); // incorrect
printf("%lu\n", n); // correct
Are you really saying that the second version is so much uglier
than the first that you'd rather write incorrect code?
If unsigned int and unsigned long happen to be the same size, both
are likely to print "42". But what if your code is later compiled
on a system with 32-bit unsigned int and 64-bit unsigned long?
Even if I were certain the code would never be ported (and such
certainty is often unjustified), I'd much rather use the correct
code than waste time figuring out which incorrect code will happen
to "work" on the current system, with the current version of the
compiler and runtime library. Oh, and gcc and clang both warn
about an incorrect format string.
I agree that the macros in <stdint.h> are ugly, and I rarely
use them. If I want to print an integer value whose type I don't
know, I'll probably cast to a predefined type that I know to be
wide enough and use the specifier for that type. Though now that
I think about it, I'm more likely to do that in throwaway code;
for production code, I'd be more likely to use the <stdint.h> macros.
[...]
--
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-06 17:14 -0800 |
| Message-ID | <874ioy2phv.fsf@example.invalid> |
| In reply to | #396236 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> I agree that the macros in <stdint.h> are ugly, and I rarely
> use them. If I want to print an integer value whose type I don't
> know, I'll probably cast to a predefined type that I know to be
> wide enough and use the specifier for that type. Though now that
> I think about it, I'm more likely to do that in throwaway code;
> for production code, I'd be more likely to use the <stdint.h> macros.
Correction: the macros are defined in <inttypes.h>, not <stdint.h>.
(<inttypes.h> includes <stdint.h> and extends 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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-07 14:01 +0200 |
| Message-ID | <20260107140134.000075f1@yahoo.com> |
| In reply to | #396236 |
On Tue, 06 Jan 2026 16:29:04 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Michael S <already5chosen@yahoo.com> writes:
> > On Tue, 6 Jan 2026 10:31:41 -0500
> > James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> >> On 2026-01-06 04:29, Michael S wrote:
> >> > On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
> >> > Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> >> ...
> >> >> Section 7.8 of the C spec defines macros you can use so you
> >> >> don’t have to hard-code assumptions about the lengths of
> >> >> integers in printf-format strings.
> >> >
> >> > Did you ever try to use them? They look ugly.
> >>
> >> Which is more important, correctness or beauty?
> >
> > It depends.
> >
> > When I know for sure that incorrectness has no consequences, like
> > in case of using %u to print 'unsigned long' on target with 32-bit
> > longs, or like using %llu to print 'unsigned long' on target with
> > 64-bit longs, then beauty wins. Easily.
>
> Seriously?
>
> An example:
>
> unsigned long n = 42;
> printf("%u\n", n); // incorrect
> printf("%lu\n", n); // correct
>
> Are you really saying that the second version is so much uglier
> than the first that you'd rather write incorrect code?
>
No, I don't think that it is much uglier. At worst, I think that
correct version is tiny bit uglier. Not enough for beauty to win over
"correctness", even when correctness is non-consequential.
I hoped that you followed the sub-thread from the beginning and did not
lost the context yet. Which is (everywhere except LIN64)
uint32_t n = 42;
printf("n = %u\n", n); // incorrect
printf("n = " PRIu32 "\n", n); // correct
or on LIN64
uint64_t n = 42;
printf("n = %llu\n", n); // incorrect
printf("n = " PRIu64 "\n", n); // correct
Here in my book beauty wins by landslide.
Although really it is not beauty wins. It's ugliness loses.
> If unsigned int and unsigned long happen to be the same size, both
> are likely to print "42". But what if your code is later compiled
> on a system with 32-bit unsigned int and 64-bit unsigned long?
>
> Even if I were certain the code would never be ported (and such
> certainty is often unjustified), I'd much rather use the correct
> code than waste time figuring out which incorrect code will happen
> to "work" on the current system, with the current version of the
> compiler and runtime library. Oh, and gcc and clang both warn
> about an incorrect format string.
>
> I agree that the macros in <stdint.h> are ugly, and I rarely
> use them. If I want to print an integer value whose type I don't
> know, I'll probably cast to a predefined type that I know to be
> wide enough and use the specifier for that type. Though now that
> I think about it, I'm more likely to do that in throwaway code;
> for production code, I'd be more likely to use the <stdint.h> macros.
>
> [...]
>
I am happy that in practice your position is not too different from my
position. It's just that irresistible urge of you to defend "right"
things in NG discussions that creates an appearance of disagreeing.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-07 04:28 -0800 |
| Message-ID | <87v7hdhaju.fsf@example.invalid> |
| In reply to | #396258 |
Michael S <already5chosen@yahoo.com> writes:
> On Tue, 06 Jan 2026 16:29:04 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> > On Tue, 6 Jan 2026 10:31:41 -0500
>> > James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> >> On 2026-01-06 04:29, Michael S wrote:
>> >> > On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
>> >> > Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>> >> ...
>> >> >> Section 7.8 of the C spec defines macros you can use so you
>> >> >> don’t have to hard-code assumptions about the lengths of
>> >> >> integers in printf-format strings.
>> >> >
>> >> > Did you ever try to use them? They look ugly.
>> >>
>> >> Which is more important, correctness or beauty?
>> >
>> > It depends.
>> >
>> > When I know for sure that incorrectness has no consequences, like
>> > in case of using %u to print 'unsigned long' on target with 32-bit
>> > longs, or like using %llu to print 'unsigned long' on target with
>> > 64-bit longs, then beauty wins. Easily.
>>
>> Seriously?
>>
>> An example:
>>
>> unsigned long n = 42;
>> printf("%u\n", n); // incorrect
>> printf("%lu\n", n); // correct
>>
>> Are you really saying that the second version is so much uglier
>> than the first that you'd rather write incorrect code?
>
> No, I don't think that it is much uglier. At worst, I think that
> correct version is tiny bit uglier. Not enough for beauty to win over
> "correctness", even when correctness is non-consequential.
>
> I hoped that you followed the sub-thread from the beginning and did not
> lost the context yet.
The context to which I replied was you favoring beauty over
correctness and using "%u" to print an unsigned long value as
an example.
I find it difficult to express how strongly I disagree.
> Which is (everywhere except LIN64)
> uint32_t n = 42;
> printf("n = %u\n", n); // incorrect
> printf("n = " PRIu32 "\n", n); // correct
printf("n = %lu\n", (unsigned long)n); // also correct
> or on LIN64
> uint64_t n = 42;
> printf("n = %llu\n", n); // incorrect
> printf("n = " PRIu64 "\n", n); // correct
printf("n = %llu\n", (unsigned long long)n); // also correct
As far as I'm concerned, the incorrect versions aren't even worth
considering.
> Here in my book beauty wins by landslide.
> Although really it is not beauty wins. It's ugliness loses.
I don't think much of your book.
[...]
> I am happy that in practice your position is not too different from my
> position. It's just that irresistible urge of you to defend "right"
> things in NG discussions that creates an appearance of disagreeing.
I don't know how you reached the conclusion that our positions are
"not too different". As far as I can tell, they are completely
different. You would knowingly write incorrect code.
Given two alternative pieces of code, I prefer the prettier one
if both are correct (and that is of course a matter of taste).
But if one is incorrect, it doesn't matter how pretty it 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]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-02-03 22:03 -0800 |
| Message-ID | <86a4xphwpy.fsf@linuxsc.com> |
| In reply to | #396260 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Michael S <already5chosen@yahoo.com> writes:
>
>> On Tue, 06 Jan 2026 16:29:04 -0800
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> Michael S <already5chosen@yahoo.com> writes:
>>>
>>>> On Tue, 6 Jan 2026 10:31:41 -0500
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>>
>>>>> On 2026-01-06 04:29, Michael S wrote:
>>>>>
>>>>>> On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
>>>>>> Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>>> Section 7.8 of the C spec defines macros you can use so you
>>>>>>> don?t have to hard-code assumptions about the lengths of
>>>>>>> integers in printf-format strings.
>>>>>>
>>>>>> Did you ever try to use them? They look ugly.
>>>>>
>>>>> Which is more important, correctness or beauty?
>>>>
>>>> It depends.
>>>>
>>>> When I know for sure that incorrectness has no consequences, like
>>>> in case of using %u to print 'unsigned long' on target with 32-bit
>>>> longs, or like using %llu to print 'unsigned long' on target with
>>>> 64-bit longs, then beauty wins. Easily.
>>>
>>> Seriously?
>>>
>>> An example:
>>>
>>> unsigned long n = 42;
>>> printf("%u\n", n); // incorrect
>>> printf("%lu\n", n); // correct
>>>
>>> Are you really saying that the second version is so much uglier
>>> than the first that you'd rather write incorrect code?
>>
>> No, I don't think that it is much uglier. At worst, I think that
>> correct version is tiny bit uglier. Not enough for beauty to win
>> over "correctness", even when correctness is non-consequential.
>>
>> I hoped that you followed the sub-thread from the beginning and
>> did not lost the context yet.
>
> The context to which I replied was you favoring beauty over
> correctness and using "%u" to print an unsigned long value as
> an example.
>
> I find it difficult to express how strongly I disagree.
I think it would be more helpful to readers if you would put your
efforts more into understanding and explaining why you disagree
than into expressing how strongly you disagree.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-01-07 15:45 +0000 |
| Message-ID | <acv7R.1062263$u2q8.617506@fx11.iad> |
| In reply to | #396236 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Michael S <already5chosen@yahoo.com> writes:
>> On Tue, 6 Jan 2026 10:31:41 -0500
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> On 2026-01-06 04:29, Michael S wrote:
>>> > On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
>>> > Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>> ...
>>> >> Section 7.8 of the C spec defines macros you can use so you don’t
>>> >> have to hard-code assumptions about the lengths of integers in
>>> >> printf-format strings.
>>> >
>>> > Did you ever try to use them? They look ugly.
>>>
>>> Which is more important, correctness or beauty?
>>
>> It depends.
>>
>> When I know for sure that incorrectness has no consequences, like
>> in case of using %u to print 'unsigned long' on target with 32-bit
>> longs, or like using %llu to print 'unsigned long' on target with
>> 64-bit longs, then beauty wins. Easily.
>
>Seriously?
>
>An example:
>
> unsigned long n = 42;
> printf("%u\n", n); // incorrect
> printf("%lu\n", n); // correct
>
>Are you really saying that the second version is so much uglier
>than the first that you'd rather write incorrect code?
I suspect he may have been referring to code that needs
to build for both 32-bit and 64-bit targets. One might
typedef 'uint64' to be unsigned long long on both targets
and just use %llu for the format string. BTDT.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-07 13:28 -0800 |
| Message-ID | <87qzs1gliq.fsf@example.invalid> |
| In reply to | #396267 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Michael S <already5chosen@yahoo.com> writes:
>>> On Tue, 6 Jan 2026 10:31:41 -0500
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>> On 2026-01-06 04:29, Michael S wrote:
>>>> > On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
>>>> > Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>> ...
>>>> >> Section 7.8 of the C spec defines macros you can use so you don’t
>>>> >> have to hard-code assumptions about the lengths of integers in
>>>> >> printf-format strings.
>>>> >
>>>> > Did you ever try to use them? They look ugly.
>>>>
>>>> Which is more important, correctness or beauty?
>>>
>>> It depends.
>>>
>>> When I know for sure that incorrectness has no consequences, like
>>> in case of using %u to print 'unsigned long' on target with 32-bit
>>> longs, or like using %llu to print 'unsigned long' on target with
>>> 64-bit longs, then beauty wins. Easily.
>>
>>Seriously?
>>
>>An example:
>>
>> unsigned long n = 42;
>> printf("%u\n", n); // incorrect
>> printf("%lu\n", n); // correct
>>
>>Are you really saying that the second version is so much uglier
>>than the first that you'd rather write incorrect code?
>
> I suspect he may have been referring to code that needs
> to build for both 32-bit and 64-bit targets. One might
> typedef 'uint64' to be unsigned long long on both targets
> and just use %llu for the format string. BTDT.
In the quoted paragraph above, Michael wrote about using %u to print
unsigned long, not about using %u to print some type hidden behind
a typedef. If he didn't mean that, he can say so.
But even if he meant to talk about printing, say, uint64_t values,
my point stands.
I wouldn't define my own "uint64" type. I'd just use "uint64_t",
defined in <stdint.h>. And I'd use one of several *correct* ways
to print uint64_t values.
Michael, if you'd care to clarify, given:
unsigned long n = 42;
printf("%u\n", n); // incorrect
printf("%lu\n", n); // correct
(and assuming that unsigned int and unsigned long are the same width on
the current implementation), do you really prefer the version marked as
"incorrect"?
--
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-08 01:26 +0200 |
| Message-ID | <20260108012620.000041a9@yahoo.com> |
| In reply to | #396281 |
On Wed, 07 Jan 2026 13:28:45 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> >>Michael S <already5chosen@yahoo.com> writes:
> >>> On Tue, 6 Jan 2026 10:31:41 -0500
> >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> >>>> On 2026-01-06 04:29, Michael S wrote:
> >>>> > On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
> >>>> > Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> >>>> ...
> >>>> >> Section 7.8 of the C spec defines macros you can use so you
> >>>> >> don’t have to hard-code assumptions about the lengths of
> >>>> >> integers in printf-format strings.
> >>>> >
> >>>> > Did you ever try to use them? They look ugly.
> >>>>
> >>>> Which is more important, correctness or beauty?
> >>>
> >>> It depends.
> >>>
> >>> When I know for sure that incorrectness has no consequences, like
> >>> in case of using %u to print 'unsigned long' on target with 32-bit
> >>> longs, or like using %llu to print 'unsigned long' on target with
> >>> 64-bit longs, then beauty wins. Easily.
> >>
> >>Seriously?
> >>
> >>An example:
> >>
> >> unsigned long n = 42;
> >> printf("%u\n", n); // incorrect
> >> printf("%lu\n", n); // correct
> >>
> >>Are you really saying that the second version is so much uglier
> >>than the first that you'd rather write incorrect code?
> >
> > I suspect he may have been referring to code that needs
> > to build for both 32-bit and 64-bit targets. One might
> > typedef 'uint64' to be unsigned long long on both targets
> > and just use %llu for the format string. BTDT.
>
> In the quoted paragraph above, Michael wrote about using %u to print
> unsigned long, not about using %u to print some type hidden behind
> a typedef. If he didn't mean that, he can say so.
>
> But even if he meant to talk about printing, say, uint64_t values,
> my point stands.
>
> I wouldn't define my own "uint64" type. I'd just use "uint64_t",
> defined in <stdint.h>. And I'd use one of several *correct* ways
> to print uint64_t values.
>
> Michael, if you'd care to clarify, given:
>
> unsigned long n = 42;
> printf("%u\n", n); // incorrect
> printf("%lu\n", n); // correct
>
> (and assuming that unsigned int and unsigned long are the same width
> on the current implementation), do you really prefer the version
> marked as "incorrect"?
>
I hoped that I already clarified that point more than one time.
Obviously, I hoped wrong.
In the case I am talking about n declared as uint32_t.
uint32_t is an alias of 'unsigned long' on 32-bit embedded targets, on
32-bit Linux, on 32-bit Windows and on 64-bit Windows. It is
alias of 'unsigned int' on 64-bit Linux.
Sometimes I move code between targets by myself, sometimes, rarely,
other people do it. I don't want to have different versions of the code
and I don't want to use ugly standard specifiers. Between two pretty
and working variants I prefer the shorter one. Partly because it is
guaranteed to work correctly on all my targets, including LIN64, but
more importantly (in practice, 64-bit Linux is a very rare target in my
daily routine) just because it is shorter. And I don't care that it is
formally "incorrect" on my more common targets. Or may be not
"formally", but both gcc and clang think so.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-07 16:00 -0800 |
| Message-ID | <87bjj5gei4.fsf@example.invalid> |
| In reply to | #396285 |
Michael S <already5chosen@yahoo.com> writes:
> On Wed, 07 Jan 2026 13:28:45 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>> > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> >>Michael S <already5chosen@yahoo.com> writes:
>> >>> On Tue, 6 Jan 2026 10:31:41 -0500
>> >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> >>>> On 2026-01-06 04:29, Michael S wrote:
>> >>>> > On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
>> >>>> > Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>> >>>> ...
>> >>>> >> Section 7.8 of the C spec defines macros you can use so you
>> >>>> >> don’t have to hard-code assumptions about the lengths of
>> >>>> >> integers in printf-format strings.
>> >>>> >
>> >>>> > Did you ever try to use them? They look ugly.
>> >>>>
>> >>>> Which is more important, correctness or beauty?
>> >>>
>> >>> It depends.
>> >>>
>> >>> When I know for sure that incorrectness has no consequences, like
>> >>> in case of using %u to print 'unsigned long' on target with 32-bit
>> >>> longs, or like using %llu to print 'unsigned long' on target with
>> >>> 64-bit longs, then beauty wins. Easily.
>> >>
>> >>Seriously?
>> >>
>> >>An example:
>> >>
>> >> unsigned long n = 42;
>> >> printf("%u\n", n); // incorrect
>> >> printf("%lu\n", n); // correct
>> >>
>> >>Are you really saying that the second version is so much uglier
>> >>than the first that you'd rather write incorrect code?
>> >
>> > I suspect he may have been referring to code that needs
>> > to build for both 32-bit and 64-bit targets. One might
>> > typedef 'uint64' to be unsigned long long on both targets
>> > and just use %llu for the format string. BTDT.
>>
>> In the quoted paragraph above, Michael wrote about using %u to print
>> unsigned long, not about using %u to print some type hidden behind
>> a typedef. If he didn't mean that, he can say so.
>>
>> But even if he meant to talk about printing, say, uint64_t values,
>> my point stands.
>>
>> I wouldn't define my own "uint64" type. I'd just use "uint64_t",
>> defined in <stdint.h>. And I'd use one of several *correct* ways
>> to print uint64_t values.
>>
>> Michael, if you'd care to clarify, given:
>>
>> unsigned long n = 42;
>> printf("%u\n", n); // incorrect
>> printf("%lu\n", n); // correct
>>
>> (and assuming that unsigned int and unsigned long are the same width
>> on the current implementation), do you really prefer the version
>> marked as "incorrect"?
>
> I hoped that I already clarified that point more than one time.
> Obviously, I hoped wrong.
And you still haven't. I asked a specific question above. What is
your answer? Would you use a "%u" format to print a value that's
defined with type unsigned long? I inferred from what you wrote
that your answer would be yes. If your answer is no, I'll gladly
accept that. (And if so, what you wrote previously was unclear,
but I'm not going to worry about that if you clarify what you meant)
You've previously indicated that you find "%lu" uglier than "%u",
and that that's relevant to which one you would use. Do you still
think so?
I would appreciate direct yes or no answers to both of those
questions.
> In the case I am talking about n declared as uint32_t.
> uint32_t is an alias of 'unsigned long' on 32-bit embedded targets, on
> 32-bit Linux, on 32-bit Windows and on 64-bit Windows. It is
> alias of 'unsigned int' on 64-bit Linux.
> Sometimes I move code between targets by myself, sometimes, rarely,
> other people do it. I don't want to have different versions of the code
> and I don't want to use ugly standard specifiers. Between two pretty
> and working variants I prefer the shorter one. Partly because it is
> guaranteed to work correctly on all my targets, including LIN64, but
> more importantly (in practice, 64-bit Linux is a very rare target in my
> daily routine) just because it is shorter. And I don't care that it is
> formally "incorrect" on my more common targets. Or may be not
> "formally", but both gcc and clang think so.
So you'd write code that happens to work on some implementations rather
than code that's correct on all implementations.
You know that unsigned long is at least 32 bits wide, and therefore that
converting a uint32_t value to unsigned long will not lose information,
and therefore that
uint32_t x = 42;
printf("%lu\n", (unsigned long)x);
will work correctly. You can do this without using the ugly
<inttypes.h> macros. Why wouldn't you?
Sure, you can write code that happens to work on the only implementation
you care about, but in my opinion, aside from being dangerous, it's just
too much work. I don't care whether uint32_t is defined as unsigned int
or unsigned long on a particular implementation, and I don't have to care.
--
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-08 02:38 +0200 |
| Message-ID | <20260108023846.0000260c@yahoo.com> |
| In reply to | #396287 |
On Wed, 07 Jan 2026 16:00:19 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Michael S <already5chosen@yahoo.com> writes:
> > On Wed, 07 Jan 2026 13:28:45 -0800
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >> scott@slp53.sl.home (Scott Lurndal) writes:
> >> > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> >> >>Michael S <already5chosen@yahoo.com> writes:
> >> >>> On Tue, 6 Jan 2026 10:31:41 -0500
> >> >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> >> >>>> On 2026-01-06 04:29, Michael S wrote:
> >> >>>> > On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
> >> >>>> > Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> >> >>>> ...
> >> >>>> >> Section 7.8 of the C spec defines macros you can use so you
> >> >>>> >> don’t have to hard-code assumptions about the lengths of
> >> >>>> >> integers in printf-format strings.
> >> >>>> >
> >> >>>> > Did you ever try to use them? They look ugly.
> >> >>>>
> >> >>>> Which is more important, correctness or beauty?
> >> >>>
> >> >>> It depends.
> >> >>>
> >> >>> When I know for sure that incorrectness has no consequences,
> >> >>> like in case of using %u to print 'unsigned long' on target
> >> >>> with 32-bit longs, or like using %llu to print 'unsigned long'
> >> >>> on target with 64-bit longs, then beauty wins. Easily.
> >> >>
> >> >>Seriously?
> >> >>
> >> >>An example:
> >> >>
> >> >> unsigned long n = 42;
> >> >> printf("%u\n", n); // incorrect
> >> >> printf("%lu\n", n); // correct
> >> >>
> >> >>Are you really saying that the second version is so much uglier
> >> >>than the first that you'd rather write incorrect code?
> >> >
> >> > I suspect he may have been referring to code that needs
> >> > to build for both 32-bit and 64-bit targets. One might
> >> > typedef 'uint64' to be unsigned long long on both targets
> >> > and just use %llu for the format string. BTDT.
> >>
> >> In the quoted paragraph above, Michael wrote about using %u to
> >> print unsigned long, not about using %u to print some type hidden
> >> behind a typedef. If he didn't mean that, he can say so.
> >>
> >> But even if he meant to talk about printing, say, uint64_t values,
> >> my point stands.
> >>
> >> I wouldn't define my own "uint64" type. I'd just use "uint64_t",
> >> defined in <stdint.h>. And I'd use one of several *correct* ways
> >> to print uint64_t values.
> >>
> >> Michael, if you'd care to clarify, given:
> >>
> >> unsigned long n = 42;
> >> printf("%u\n", n); // incorrect
> >> printf("%lu\n", n); // correct
> >>
> >> (and assuming that unsigned int and unsigned long are the same
> >> width on the current implementation), do you really prefer the
> >> version marked as "incorrect"?
> >
> > I hoped that I already clarified that point more than one time.
> > Obviously, I hoped wrong.
>
> And you still haven't. I asked a specific question above. What is
> your answer? Would you use a "%u" format to print a value that's
> defined with type unsigned long? I inferred from what you wrote
> that your answer would be yes. If your answer is no, I'll gladly
> accept that. (And if so, what you wrote previously was unclear,
> but I'm not going to worry about that if you clarify what you meant)
>
When n declared as 'unsigned long' derectly rather than via unint32_t
alias than the answer is 'no'.
> You've previously indicated that you find "%lu" uglier than "%u",
> and that that's relevant to which one you would use. Do you still
> think so?
>
> I would appreciate direct yes or no answers to both of those
> questions.
>
It depends on how n declared.
When it declared as 'unsigned long' then "lu" is not uglier.
When it is defined as uint32_t it is uglier, despite the fact that on
absolute majority of the targets that I care about the latter is an
alias of the former.
> > In the case I am talking about n declared as uint32_t.
> > uint32_t is an alias of 'unsigned long' on 32-bit embedded targets,
> > on 32-bit Linux, on 32-bit Windows and on 64-bit Windows. It is
> > alias of 'unsigned int' on 64-bit Linux.
> > Sometimes I move code between targets by myself, sometimes, rarely,
> > other people do it. I don't want to have different versions of the
> > code and I don't want to use ugly standard specifiers. Between two
> > pretty and working variants I prefer the shorter one. Partly
> > because it is guaranteed to work correctly on all my targets,
> > including LIN64, but more importantly (in practice, 64-bit Linux is
> > a very rare target in my daily routine) just because it is shorter.
> > And I don't care that it is formally "incorrect" on my more common
> > targets. Or may be not "formally", but both gcc and clang think so.
> >
>
> So you'd write code that happens to work on some implementations
> rather than code that's correct on all implementations.
>
No, it is correct on all implementation. Idea that in C, as opposed to
C++, two unsigned integer types of the same size are somehow
different is, IMHO, an abomination. And that is one not especially
common case in which I don't care about opinion of the Standard.
> You know that unsigned long is at least 32 bits wide, and therefore
> that converting a uint32_t value to unsigned long will not lose
> information, and therefore that
>
> uint32_t x = 42;
> printf("%lu\n", (unsigned long)x);
>
> will work correctly. You can do this without using the ugly
> <inttypes.h> macros. Why wouldn't you?
>
If it was named 'ulong' I'd seriously consider such solution. But when
the name of type is not just rather long, but consists of two words as
well, I wouldn't do it.
> Sure, you can write code that happens to work on the only
> implementation you care about, but in my opinion, aside from being
> dangerous, it's just too much work. I don't care whether uint32_t is
> defined as unsigned int or unsigned long on a particular
> implementation, and I don't have to care.
>
I also don't care. Since for more than decade* I didn't have target
with 'int' shorter than 32 bits, I just use %u. It takes me zero
thinking.
BTW, I am always aware of exact sizes of the basic types of the target
that I work on. I don't feel comfotable without such knowledge. That
how my mind works. It has problems with too abstract abstractions.
------
* - or may be a little less than decade, I don't remember in which year
exactly I did last change to project that runs on TI C2000, which is
32-bit CPU, BTW, but TI being TI still had size of int that they
had chosen.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-07 17:36 -0800 |
| Message-ID | <877btshom5.fsf@example.invalid> |
| In reply to | #396288 |
Michael S <already5chosen@yahoo.com> writes:
> On Wed, 07 Jan 2026 16:00:19 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> > On Wed, 07 Jan 2026 13:28:45 -0800
[...]
>> >> Michael, if you'd care to clarify, given:
>> >>
>> >> unsigned long n = 42;
>> >> printf("%u\n", n); // incorrect
>> >> printf("%lu\n", n); // correct
>> >>
>> >> (and assuming that unsigned int and unsigned long are the same
>> >> width on the current implementation), do you really prefer the
>> >> version marked as "incorrect"?
>> >
>> > I hoped that I already clarified that point more than one time.
>> > Obviously, I hoped wrong.
>>
>> And you still haven't. I asked a specific question above. What is
>> your answer? Would you use a "%u" format to print a value that's
>> defined with type unsigned long? I inferred from what you wrote
>> that your answer would be yes. If your answer is no, I'll gladly
>> accept that. (And if so, what you wrote previously was unclear,
>> but I'm not going to worry about that if you clarify what you meant)
>
> When n declared as 'unsigned long' derectly rather than via unint32_t
> alias than the answer is 'no'.
Thank you for answering that.
>> You've previously indicated that you find "%lu" uglier than "%u",
>> and that that's relevant to which one you would use. Do you still
>> think so?
>>
>> I would appreciate direct yes or no answers to both of those
>> questions.
>
> It depends on how n declared.
> When it declared as 'unsigned long' then "lu" is not uglier.
> When it is defined as uint32_t it is uglier, despite the fact that on
> absolute majority of the targets that I care about the latter is an
> alias of the former.
Let me see if I understand you correctly.
uint32_t n = 42;
printf("%u\n", n);
printf("%lu\n", n);
In this context, you find "%lu" uglier than "%u"?
[SNIP]
--
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-08 11:01 +0200 |
| Message-ID | <20260108110144.0000330c@yahoo.com> |
| In reply to | #396289 |
On Wed, 07 Jan 2026 17:36:34 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
> Let me see if I understand you correctly.
>
> uint32_t n = 42;
> printf("%u\n", n);
> printf("%lu\n", n);
>
> In this context, you find "%lu" uglier than "%u"?
>
Yes.
[toc] | [prev] | [next] | [standalone]
| From | "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-08 19:31 -0500 |
| Message-ID | <10jpi8h$15aea$1@dont-email.me> |
| In reply to | #396288 |
On 2026-01-07 19:38, Michael S wrote: > On Wed, 07 Jan 2026 16:00:19 -0800 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: ... >> So you'd write code that happens to work on some implementations >> rather than code that's correct on all implementations. >> > > No, it is correct on all implementation. Idea that in C, as opposed to > C++, two unsigned integer types of the same size are somehow > different is, IMHO, an abomination. And that is one not especially > common case in which I don't care about opinion of the Standard. We're not talking about two unsigned integer types with same size. We're talking about unsigned long, which can be any size >= 32 bits, and uint32_t, which can only be exactly 32 bits. Your code is NOT portable to a platform where unsigned long is greater than 32 bits. ... > I also don't care. Since for more than decade* I didn't have target > with 'int' shorter than 32 bits, I just use %u. It takes me zero > thinking. As a general rule, I find that people who claim a decision requires no thought generally are referring to a decision that should have been made differently if sufficient thought had been put into it. This is a prime example. > BTW, I am always aware of exact sizes of the basic types of the target > that I work on. I don't feel comfotable without such knowledge. That > how my mind works. It has problems with too abstract abstractions. I'd have no problem with your approach if you hadn't falsely claimed that "It is correct on all platforms". There's nothing wrong with code that is intentionally platform specific. Platform-specific code that the author incorrectly believes to be "correct on all platforms" is a problem.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-09 14:18 +0200 |
| Message-ID | <20260109141859.00004f22@yahoo.com> |
| In reply to | #396313 |
On Thu, 8 Jan 2026 19:31:13 -0500 "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: > On 2026-01-07 19:38, Michael S wrote: > > On Wed, 07 Jan 2026 16:00:19 -0800 > > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > ... > >> So you'd write code that happens to work on some implementations > >> rather than code that's correct on all implementations. > >> > > > > No, it is correct on all implementation. Idea that in C, as opposed > > to C++, two unsigned integer types of the same size are somehow > > different is, IMHO, an abomination. And that is one not especially > > common case in which I don't care about opinion of the Standard. > > We're not talking about two unsigned integer types with same size. > We're talking about unsigned long, which can be any size >= 32 bits, > and uint32_t, which can only be exactly 32 bits. Your code is NOT > portable to a platform where unsigned long is greater than 32 bits. > I don't know how you came to discussions of what is possible. My statement was concrete. It was about platforms like Windows (of all flavors) and 2-3 specific 32-bit embedded targets that I currently care about. On all these platforms uint32_t is alias of 'unsigned long' which is 32-bit wide. 'unsigned int' is also 32-bit wide. I claim that *on these platforms* uint32_t and 'unsigned int' are *not* different types. I don't care to what the Standard says about it. I do care about what gcc says about it because I am annoyed by warnings that I consider pointless. Printing uint32_t values on these platforms with %u specifier, apart from advantage of being shorter, has advantage of being undoubtedly correct on LIN64. Unlike printing with %lu. Now, going one step further and using more intimate knowledge of SysV ABI I can argue with myself and prove (could I? I am only 95% sure) that on LIN64 %lu will also always print correct result. But I don't want to take this step. > ... > > I also don't care. Since for more than decade* I didn't have target > > with 'int' shorter than 32 bits, I just use %u. It takes me zero > > thinking. > > As a general rule, I find that people who claim a decision requires > no thought generally are referring to a decision that should have > been made differently if sufficient thought had been put into it. > This is a prime example. > > > BTW, I am always aware of exact sizes of the basic types of the > > target that I work on. I don't feel comfotable without such > > knowledge. That how my mind works. It has problems with too > > abstract abstractions. > > 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. > There's nothing wrong with > code that is intentionally platform specific. Platform-specific code > that the author incorrectly believes to be "correct on all platforms" > is a problem.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-09 13:49 +0100 |
| Message-ID | <10jqthf$2c0jh$1@dont-email.me> |
| In reply to | #396319 |
On 09/01/2026 13:18, Michael S wrote: > On Thu, 8 Jan 2026 19:31:13 -0500 > "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: > >> On 2026-01-07 19:38, Michael S wrote: >>> On Wed, 07 Jan 2026 16:00:19 -0800 >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> ... >>>> So you'd write code that happens to work on some implementations >>>> rather than code that's correct on all implementations. >>>> >>> >>> No, it is correct on all implementation. Idea that in C, as opposed >>> to C++, two unsigned integer types of the same size are somehow >>> different is, IMHO, an abomination. And that is one not especially >>> common case in which I don't care about opinion of the Standard. >> >> We're not talking about two unsigned integer types with same size. >> We're talking about unsigned long, which can be any size >= 32 bits, >> and uint32_t, which can only be exactly 32 bits. Your code is NOT >> portable to a platform where unsigned long is greater than 32 bits. >> > > I don't know how you came to discussions of what is possible. > My statement was concrete. It was about platforms like Windows (of all > flavors) and 2-3 specific 32-bit embedded targets that I currently > care about. > On all these platforms uint32_t is alias of 'unsigned long' which is > 32-bit wide. 'unsigned int' is also 32-bit wide. > I claim that *on these platforms* uint32_t and 'unsigned int' are *not* > different types. I don't care to what the Standard says about it. Of course they are different types. In C, "unsigned int" and "unsigned long" are different types. The standard says so - and it is the standard that defines the language. > I do care about what gcc says about it because I am annoyed by warnings > that I consider pointless. The warnings are not pointless, despite what you might think. And of course gcc is not going to modify its warnings to pander to someone who has their own personal ideas about what C should be. We /all/ have ideas about how C could be better for our own needs. But outside the realm of personal languages where the single user also designed the language and wrote the compiler, you have to work with the language as it is defined. For a clear example of the differences between unsigned int and unsigned long, look at the generated code here: <https://godbolt.org/z/hdjz6Y7vY> That is for embedded 32-bit ARM, where "uint32_t" is "unsigned long", and is the same size as "unsigned int". Then try swapping the compiler to the 32-bit ARM gcc Linux version - here "uint32_t" is "unsigned int", and again the same size as "unsigned long". Look at the differences in the code. It doesn't matter if /you/ think that all 32-bit integer types should be the same - in C, they are not. And therefore in C compilers, they are not the same. > > Printing uint32_t values on these platforms with %u specifier, apart > from advantage of being shorter, has advantage of being undoubtedly > correct on LIN64. Unlike printing with %lu. But printing uint32_t with "%u" on 32-bit EABI ARM is not correct - it is UB. It will /probably/ work, but maybe some day you will come across a situation where it will not. 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.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-01-10 00:17 +0800 |
| Message-ID | <0576c5c443c60da7c60774b669ce965bc9774078.camel@gmail.com> |
| In reply to | #396321 |
On Fri, 2026-01-09 at 13:49 +0100, David Brown wrote:
> On 09/01/2026 13:18, Michael S wrote:
> > On Thu, 8 Jan 2026 19:31:13 -0500
> > "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote:
> >
> > > On 2026-01-07 19:38, Michael S wrote:
> > > > On Wed, 07 Jan 2026 16:00:19 -0800
> > > > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> > > ...
> > > > > So you'd write code that happens to work on some implementations
> > > > > rather than code that's correct on all implementations.
> > > > >
> > > >
> > > > No, it is correct on all implementation. Idea that in C, as opposed
> > > > to C++, two unsigned integer types of the same size are somehow
> > > > different is, IMHO, an abomination. And that is one not especially
> > > > common case in which I don't care about opinion of the Standard.
> > >
> > > We're not talking about two unsigned integer types with same size.
> > > We're talking about unsigned long, which can be any size >= 32 bits,
> > > and uint32_t, which can only be exactly 32 bits. Your code is NOT
> > > portable to a platform where unsigned long is greater than 32 bits.
> > >
> >
> > I don't know how you came to discussions of what is possible.
> > My statement was concrete. It was about platforms like Windows (of all
> > flavors) and 2-3 specific 32-bit embedded targets that I currently
> > care about.
> > On all these platforms uint32_t is alias of 'unsigned long' which is
> > 32-bit wide. 'unsigned int' is also 32-bit wide.
> > I claim that *on these platforms* uint32_t and 'unsigned int' are *not*
> > different types. I don't care to what the Standard says about it.
>
> Of course they are different types. In C, "unsigned int" and "unsigned
> long" are different types. The standard says so - and it is the
> standard that defines the language.
>
> > I do care about what gcc says about it because I am annoyed by warnings
> > that I consider pointless.
>
> The warnings are not pointless, despite what you might think. And of
> course gcc is not going to modify its warnings to pander to someone who
> has their own personal ideas about what C should be. We /all/ have
> ideas about how C could be better for our own needs. But outside the
> realm of personal languages where the single user also designed the
> language and wrote the compiler, you have to work with the language as
> it is defined.
>
> For a clear example of the differences between unsigned int and unsigned
> long, look at the generated code here:
>
> <https://godbolt.org/z/hdjz6Y7vY>
>
> That is for embedded 32-bit ARM, where "uint32_t" is "unsigned long",
> and is the same size as "unsigned int". Then try swapping the compiler
> to the 32-bit ARM gcc Linux version - here "uint32_t" is "unsigned int",
> and again the same size as "unsigned long". Look at the differences in
> the code.
>
> It doesn't matter if /you/ think that all 32-bit integer types should be
> the same - in C, they are not. And therefore in C compilers, they are
> not the same.
>
> >
> > Printing uint32_t values on these platforms with %u specifier, apart
> > from advantage of being shorter, has advantage of being undoubtedly
> > correct on LIN64. Unlike printing with %lu.
>
> But printing uint32_t with "%u" on 32-bit EABI ARM is not correct - it
> is UB. It will /probably/ work, but maybe some day you will come across
> a situation where it will not.
>
> 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
which can be used to construct the 'same' (including verified by
operator==) object.
Note: This function is not mandatory. But in OO design, the text
may include the description of interactions between external
events and sub-classes. This would form the basic proof of
correctness of concept.
My reply might not be directly in the topic of current post. Just jumpped in
to reply. It looks to me the format character MUST match the type passed to
printf, otherwise UB.
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web