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 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-02-04 22:48 +0200 |
| Message-ID | <20260204224810.00007248@yahoo.com> |
| In reply to | #396592 |
On Wed, 4 Feb 2026 21:09:22 +0100 David Brown <david.brown@hesbynett.no> wrote: > > Changing it to "%g", "double" and "0.0" > covers all integer types and floats and doubles. (Supporting long > doubles is left as an exercise for the reader.) > 'double' is insufficient for integers with magnitude above 2**53. That is, it will print something that is not complete nonsense, but not an exact number that you wanted.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-02-04 22:57 +0200 |
| Message-ID | <20260204225725.000006e7@yahoo.com> |
| In reply to | #396591 |
On Wed, 4 Feb 2026 18:11:34 +0000 Bart <bc@freeuk.com> wrote: > On 04/02/2026 17:12, David Brown wrote: > > > and you want to post about how > > terrible C is and how great your own language is? > > I think pretty much every language except C seems to have solved this. > > How do you do it in Fortran? Also, there are many languages that "solved" it at very high cost of primitivity of their formatting features. E.g. Pascal. I don't remember where Ada stands in this picturee. In case of Ada95 or newer, more like don't know rather then don't remember.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-04 23:24 +0000 |
| Message-ID | <10m0kg0$2ngak$1@dont-email.me> |
| In reply to | #396595 |
On 04/02/2026 20:57, Michael S wrote:
> On Wed, 4 Feb 2026 18:11:34 +0000
> Bart <bc@freeuk.com> wrote:
>
>> On 04/02/2026 17:12, David Brown wrote:
>>
>> > and you want to post about how
>> > terrible C is and how great your own language is?
>>
>> I think pretty much every language except C seems to have solved this.
>>
>>
>
> How do you do it in Fortran?
> Also, there are many languages that "solved" it at very high cost of
> primitivity of their formatting features. E.g. Pascal.
> I don't remember where Ada stands in this picturee. In case of Ada95 or
> newer, more like don't know rather then don't remember.
>
Printing expressions involves two kinds of info other than their values:
(1) The types of the values being printed
(2) The desired layout and appearance
(1) Is always known by the language/compiler/interpreter
(2) Is optional when sensible defaults are used
C's printf scheme always needs both (1) and (2).
Some languages that have adopted C's printf scheme still need (1), but
two I've just tried (Go and OCaml) will report a runtime error if there
is a mismatch.
FORTRAN IV probably had more primitive I/O than C. Ada is also
long-winded: you need to call some type-specific function, but it will
at least be on top of the types too.
Some languages get it right, so that (1) is not needed. Examples from
old languages include the Algols, Pascal and BASIC. This is where you
just do the equivalent of:
print x
in whatever syntax is required. A selection of modern languages where
you don't need that (1) type info is:
Lua, Python, Julia, Rust, Nim, Odin, JavaScript, Zig (types optional)
With C, I don't have a particular problem with the layout features,
other than you /always/ have to provide a format string even with
throwaway code.
The problem is working out and maintaining the format codes, and not
having compile-time checks unless you use a big, slow compiler with the
correct warnings enabled.
Some languages are worse however, despite not needing type codes; this
is Zig, although usually, you'd use an alias for the first part:
@import("std").debug.print("{} {}\n", .{i, x});
The C equivalent is this (when i is i32 and x is f64):
printf("%d %d\n", i, x);
Suddenly C doesn't look so bad!
(I just noticed that the second %d should have been %f, but decided to
leave it: THIS is the problem.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-04 16:04 -0800 |
| Message-ID | <874inw9hu1.fsf@example.invalid> |
| In reply to | #396591 |
Bart <bc@freeuk.com> writes:
[...]
> Meanwhile C11 (_Generic) and C23 ("%w" formats) don't appear to have
> made much impact. It's not fixing it at the right level. But at least
> you can now have a 999-bit type that you probably can't print even if
> you wrote "%w999d"; or can you?
No, the "%wN" and "%wfN" length modifiers cannot (reliably) be
used with bit-precise integer types. The standard requires them to
support the widths of the types defined in <stdint.h>, typically 8,
16, 32, and 64 bits. The standard says that "Other supported values
of N are implementation-defined", but any bit-precise integer type
is incompatible with any of the <stdint.h> types.
In a quick look, I don't see any standard ways to print (or read)
values of bit-precise integer types, either in N3220 (C23 draft)
or in N2783 (latest working draft for C202y). I find this suprising
and disappointing.
--
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-02-04 15:39 -0800 |
| Message-ID | <878qd89iyl.fsf@example.invalid> |
| In reply to | #396588 |
Bart <bc@freeuk.com> writes:
[...]
> The problem is that C expects an exact format-code when trying to use
> *printf functions, and for that you need to know the exact types of
> the expressions being passed. For example:
>
> uintptr_t x; // from above examples
> double y; //
> printf("x * y is %?", x * y); // What's '?'
Since you asked...
'?' is 'f' (or 'g' or 'e', or 'a', or any of those in upper case).
`x * y` is of type double.
When an integer operand is multiplied by (or added to, or ...) a
floating-point operand, the integer operand is converted to the type
of the floating-point operand. The "usual arithmetic conversions"
are moderately complicated, but that particular rule is simple
enough that I didn't have to look it up (though I did double-check
it, no pun intended).
If I didn't know that, I'd look it up. If I wanted something other
than the usual arithmetic conversions, I'd force the result I want
using a cast or casts. And I know it's just an example, but in
real life I'd spend some time thinking about *why* I'm multiplying
a uintptr_t by a double (I can't think of a realistic scenario where
that would be appropriate), and likely concluding that one or both of
the operands should have been of some other type in the first place.
Yes, printf requires an exact type for each argument. Yes, that
can be inconvenient. But updating printf so it can take arguments
of any type and know what to do with them would require changes
to the language that nobody, as far as I know, has proposed.
(Any such proposal that would work only for the *printf functions,
not for arbitrary user-written code, would probably not be accepted.)
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-04 23:52 +0000 |
| Message-ID | <10m0m3b$2ngak$2@dont-email.me> |
| In reply to | #396598 |
On 04/02/2026 23:39, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> The problem is that C expects an exact format-code when trying to use
>> *printf functions, and for that you need to know the exact types of
>> the expressions being passed. For example:
>>
>> uintptr_t x; // from above examples
>> double y; //
>> printf("x * y is %?", x * y); // What's '?'
>
> Since you asked...
>
> '?' is 'f' (or 'g' or 'e', or 'a', or any of those in upper case).
> `x * y` is of type double.
The 'from above examples' applies to both x and y. That means that
'double' /may/ have been redefined like this (from my post):
#ifdef SQLITE_OMIT_FLOATING_POINT
# define double sqlite3_int64
#endif
I don't know what 'sqlite3_int64' is, but it sounds like a signed integer.
I was asked to give examples of conditional types, and thought it best
to do so from actual programs.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-05 12:51 +0100 |
| Message-ID | <10m208p$35jde$1@dont-email.me> |
| In reply to | #396601 |
On 05/02/2026 00:52, Bart wrote:
> On 04/02/2026 23:39, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> The problem is that C expects an exact format-code when trying to use
>>> *printf functions, and for that you need to know the exact types of
>>> the expressions being passed. For example:
>>>
>>> uintptr_t x; // from above examples
>>> double y; //
>>> printf("x * y is %?", x * y); // What's '?'
>>
>> Since you asked...
>>
>> '?' is 'f' (or 'g' or 'e', or 'a', or any of those in upper case).
>> `x * y` is of type double.
>
> The 'from above examples' applies to both x and y. That means that
> 'double' /may/ have been redefined like this (from my post):
>
> #ifdef SQLITE_OMIT_FLOATING_POINT
> # define double sqlite3_int64
> #endif
>
> I don't know what 'sqlite3_int64' is, but it sounds like a signed integer.
>
> I was asked to give examples of conditional types, and thought it best
> to do so from actual programs.
What you have found is an idiocy in SQLITE, not a problem in the C
language or printf. If the macro "SQLITE_OMIT_FLOATING_POINT" is
defined, then the type named "sqlite3_int64" is not an integer type, nor
can it hold arbitrary 64-bit integers (as Michael S pointed out, and I
assume accurately, it can hold 53 bit integers). I do not know what
this type is used for in the code, but something like "sqlite3_bignum"
would be a far better choice of name. And if it is intended that people
print out these values directly, defining "PRsqlite3_bignum" to "%g" or
"%llu" as appropriate would be helpful. (Yes, the resulting printf
statements would be ugly - better ugly and correct than wrong).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-05 11:22 -0800 |
| Message-ID | <87pl6j807j.fsf@example.invalid> |
| In reply to | #396606 |
David Brown <david.brown@hesbynett.no> writes:
> On 05/02/2026 00:52, Bart wrote:
>> On 04/02/2026 23:39, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> The problem is that C expects an exact format-code when trying to use
>>>> *printf functions, and for that you need to know the exact types of
>>>> the expressions being passed. For example:
>>>>
>>>> uintptr_t x; // from above examples
>>>> double y; //
>>>> printf("x * y is %?", x * y); // What's '?'
>>>
>>> Since you asked...
>>>
>>> '?' is 'f' (or 'g' or 'e', or 'a', or any of those in upper case).
>>> `x * y` is of type double.
>>
>> The 'from above examples' applies to both x and y. That means that
>> 'double' /may/ have been redefined like this (from my post):
>>
>> #ifdef SQLITE_OMIT_FLOATING_POINT
>> # define double sqlite3_int64
>> #endif
>>
>> I don't know what 'sqlite3_int64' is, but it sounds like a signed
>> integer. I was asked to give examples of conditional types, and
>> thought it best to do so from actual programs.
>
> What you have found is an idiocy in SQLITE, not a problem in the C
> language or printf. If the macro "SQLITE_OMIT_FLOATING_POINT" is
> defined, then the type named "sqlite3_int64" is not an integer type,
> nor can it hold arbitrary 64-bit integers (as Michael S pointed out,
> and I assume accurately, it can hold 53 bit integers). I do not know
> what this type is used for in the code, but something like
> "sqlite3_bignum" would be a far better choice of name. And if it is
> intended that people print out these values directly, defining
> "PRsqlite3_bignum" to "%g" or "%llu" as appropriate would be helpful.
> (Yes, the resulting printf statements would be ugly - better ugly and
> correct than wrong).
The macro doesn't define "sqlite3_int64", which as far as I can tell is
always an integer type. It redefines "double".
That macro in isolation does seem deeply silly, but I haven't worked on
sqlite3's source code. Apparently the authors found it convenient.
Presumably anyone working on the source code has to keep in mind that
the word "double" doesn't necessarily mean what it normally means. It's
not the way I would have written it. I probably would have defined a
type name that can be either "double" or "sqlite3_int64", depending on
the setting of SQLITE_OMIT_FLOATING_POINT. But I don't know enough
about the sqlite3 source code to be able to meaningfully criticize it.
In almost all contexts, it's perfectly reasonable to assume that the
word "double" in C code refers to the predefined floating-point type.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-06 12:46 +0100 |
| Message-ID | <10m4kbg$3s2o$3@dont-email.me> |
| In reply to | #396611 |
On 05/02/2026 20:22, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 05/02/2026 00:52, Bart wrote:
>>> On 04/02/2026 23:39, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> The problem is that C expects an exact format-code when trying to use
>>>>> *printf functions, and for that you need to know the exact types of
>>>>> the expressions being passed. For example:
>>>>>
>>>>> uintptr_t x; // from above examples
>>>>> double y; //
>>>>> printf("x * y is %?", x * y); // What's '?'
>>>>
>>>> Since you asked...
>>>>
>>>> '?' is 'f' (or 'g' or 'e', or 'a', or any of those in upper case).
>>>> `x * y` is of type double.
>>>
>>> The 'from above examples' applies to both x and y. That means that
>>> 'double' /may/ have been redefined like this (from my post):
>>>
>>> #ifdef SQLITE_OMIT_FLOATING_POINT
>>> # define double sqlite3_int64
>>> #endif
>>>
>>> I don't know what 'sqlite3_int64' is, but it sounds like a signed
>>> integer. I was asked to give examples of conditional types, and
>>> thought it best to do so from actual programs.
>>
>> What you have found is an idiocy in SQLITE, not a problem in the C
>> language or printf. If the macro "SQLITE_OMIT_FLOATING_POINT" is
>> defined, then the type named "sqlite3_int64" is not an integer type,
>> nor can it hold arbitrary 64-bit integers (as Michael S pointed out,
>> and I assume accurately, it can hold 53 bit integers). I do not know
>> what this type is used for in the code, but something like
>> "sqlite3_bignum" would be a far better choice of name. And if it is
>> intended that people print out these values directly, defining
>> "PRsqlite3_bignum" to "%g" or "%llu" as appropriate would be helpful.
>> (Yes, the resulting printf statements would be ugly - better ugly and
>> correct than wrong).
>
> The macro doesn't define "sqlite3_int64", which as far as I can tell is
> always an integer type. It redefines "double".
You are right - I was reading it as a typedef.
Redefining "double" with a macro expanding to an integer type (if that
is what "sqlite3_int64" is) is an even worse idea than my misinterpretation!
>
> That macro in isolation does seem deeply silly, but I haven't worked on
> sqlite3's source code. Apparently the authors found it convenient.
> Presumably anyone working on the source code has to keep in mind that
> the word "double" doesn't necessarily mean what it normally means. It's
> not the way I would have written it. I probably would have defined a
> type name that can be either "double" or "sqlite3_int64", depending on
> the setting of SQLITE_OMIT_FLOATING_POINT. But I don't know enough
> about the sqlite3 source code to be able to meaningfully criticize it.
>
I think we all know enough about C to criticise this. Defining a macro
with the name of a keyword is UB - even if we assume that all people
reading the sqlite code understand what is going on.
> In almost all contexts, it's perfectly reasonable to assume that the
> word "double" in C code refers to the predefined floating-point type.
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-02-06 02:25 -0800 |
| Message-ID | <861piyi2y6.fsf@linuxsc.com> |
| In reply to | #396588 |
Bart <bc@freeuk.com> writes:
> On 04/02/2026 14:22, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> On 03/02/2026 15:47, Tim Rentsch wrote:
>>
>> [...]
>>
>>>> If variable 'u' is declared as uint32_t, a way to print it that is
>>>> easy and also type-safe is
>>>>
>>>> printf( " u is %lu\n", u+0LU );
>>>
>>> What about a compound expression of several variables of mixed
>>> integer types, possibly even mixed with floats, some of whose types
>>> might either be conditional (depending on some macro), or opaque?
>>
>> What is an example of a conditional/macro-dependent type?
>
> Example from SDL2:
>
> #if defined(_MSC_VER) && (_MSC_VER < 1600)
> ...
> #ifndef _UINTPTR_T_DEFINED
> #ifdef _WIN64
> typedef unsigned __int64 uintptr_t;
> #else
> typedef unsigned int uintptr_t;
> ...
>
> Example from SQLITE3:
>
> #ifdef SQLITE_OMIT_FLOATING_POINT
> # define double sqlite3_int64
> #endif
>
>
>> Also what sort of opaque types do you have in mind?
>
> Things like time_t and clock_t, or the equivalent from libraries.
>
> Yes you could hunt down the exact underlying type (for clock_t in one
> case, it was under 6 layers of typedefs and macros), but that would be
> for a specific set of headers.
>
> For system headers, somebody could be using a header with different
> definitions. For user-libraries, it might be a slightly different
> version.
>
>
>> What is the problem you want to solve here?
>
> The problem is that C expects an exact format-code when trying to use
> *printf functions, and for that you need to know the exact types of
> the expressions being passed. For example:
>
> uintptr_t x; // from above examples
> double y; //
> printf("x * y is %?", x * y); // What's '?'
I understand. Thank you for the explanation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-03 14:43 -0800 |
| Message-ID | <87zf5pphwd.fsf@example.invalid> |
| In reply to | #396575 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> If variable 'u' is declared as uint32_t, a way to print it that is
> easy and also type-safe is
>
> printf( " u is %lu\n", u+0LU );
I prefer
printf("u is %lu\n", (unsigned)long_u);
I find it clearer.
Anticipating your reply, this is my personal preference, my opinion,
not backed up by any objective research.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-03 23:06 +0000 |
| Message-ID | <10ltv1i$1svhi$1@dont-email.me> |
| In reply to | #396579 |
On 03/02/2026 22:43, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>> If variable 'u' is declared as uint32_t, a way to print it that is
>> easy and also type-safe is
>>
>> printf( " u is %lu\n", u+0LU );
>
> I prefer
>
> printf("u is %lu\n", (unsigned)long_u);
>
> I find it clearer.
Is there a typo in there, or is the variable actually called 'long_u'?
Then the message doesn't match.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-03 15:33 -0800 |
| Message-ID | <87v7gdpfl3.fsf@example.invalid> |
| In reply to | #396580 |
Bart <bc@freeuk.com> writes:
> On 03/02/2026 22:43, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>> If variable 'u' is declared as uint32_t, a way to print it that is
>>> easy and also type-safe is
>>>
>>> printf( " u is %lu\n", u+0LU );
>>
>> I prefer
>>
>> printf("u is %lu\n", (unsigned)long_u);
>>
>> I find it clearer.
>
> Is there a typo in there, or is the variable actually called 'long_u'?
> Then the message doesn't match.
Yes, that was a typo, a misplaced ')' (not sure how the '_' got there).
Thanks for catching it.
The version I prefer (and I tested it this time) is:
printf("u is %lu\n", (unsigned long)u);
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-13 22:17 -0500 |
| Message-ID | <10k71rl$15aeb$10@dont-email.me> |
| In reply to | #396341 |
On 2026-01-11 06:20, Michael S wrote: > 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. I've looked for a previous restriction of this discussion to cases covered by a) and b) above. The closest I could find is the following: > 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. Note several points: that is a period after the first use of "uint32_t", so "the case" you're specifying ends there. I read the next three lines as information about your working environment, not restrictions on the claimed validity of your preference for "%u" over "%lu". There is no mention of a restriction on the size of "unsigned int".
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-14 11:10 +0200 |
| Message-ID | <20260114111038.0000258e@yahoo.com> |
| In reply to | #396404 |
On Tue, 13 Jan 2026 22:17:09 -0500 "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: > On 2026-01-11 06:20, Michael S wrote: > > 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. > > I've looked for a previous restriction of this discussion to cases > covered by a) and b) above. The closest I could find is the following: > > > 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. > > Note several points: that is a period after the first use of > "uint32_t", so "the case" you're specifying ends there. I read the > next three lines as information about your working environment, not > restrictions on the claimed validity of your preference for "%u" over > "%lu". There is no mention of a restriction on the size of "unsigned > int". > > Ignoring for a minute that what I claimed about 32-bit Linux is at best non-universal and at worst universally wrong, how would you formulate what I meant? My knowledge of English punctuation rules is rather minimal and even less than that for its US American variant.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-15 06:10 -0500 |
| Message-ID | <10kahv8$f3eq$2@dont-email.me> |
| In reply to | #396416 |
On 2026-01-14 04:10, Michael S wrote: > On Tue, 13 Jan 2026 22:17:09 -0500 > "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: > >> On 2026-01-11 06:20, Michael S wrote: >>> 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. >> >> I've looked for a previous restriction of this discussion to cases >> covered by a) and b) above. The closest I could find is the following: >> >>> 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. >> >> Note several points: that is a period after the first use of >> "uint32_t", so "the case" you're specifying ends there. I read the >> next three lines as information about your working environment, not >> restrictions on the claimed validity of your preference for "%u" over >> "%lu". There is no mention of a restriction on the size of "unsigned >> int". >> >> > > Ignoring for a minute that what I claimed about 32-bit Linux is > at best non-universal and at worst universally wrong, how would you > formulate what I meant? > My knowledge of English punctuation rules is rather minimal and even > less than that for its US American variant. I'm not sure exactly what you intended. And, as I mentioned in another sub-thread, I've worked for most of my career under rules that prohibited me from writing code that depends upon the kinds of details that you're talking about - as a result, I've had little reason to familiarize myself with those details. However, I can say that using "%u" to print a value of unsigned long type has no chance of working unless unsigned int and unsigned long have the same size and representation. Even if they do, the behavior is still undefined, but there's a pretty good chance it will work. How could it fail? As an extension, an implementation could define an ABI for use with variadic functions that adds a tag to each value indicating its type, and could add a feature to <stdarg.h> to access those tags. The printf() and scanf() families of functions could use that feature to check for compatibility between the type specified by the forma specifier, and the actual type of the corresponding argument. Upon finding a mismatch, it could issue run-time diagnostic or even abort your program. Such an implementation would be allowed by the fact the behavior of your program is undefined when there is such a mismatch.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-15 04:00 -0800 |
| Message-ID | <87ms2fnkzq.fsf@example.invalid> |
| In reply to | #396428 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> I'm not sure exactly what you intended. And, as I mentioned in another
> sub-thread, I've worked for most of my career under rules that
> prohibited me from writing code that depends upon the kinds of details
> that you're talking about - as a result, I've had little reason to
> familiarize myself with those details. However, I can say that using
> "%u" to print a value of unsigned long type has no chance of working
> unless unsigned int and unsigned long have the same size and
> representation. Even if they do, the behavior is still undefined, but
> there's a pretty good chance it will work.
[...]
On one implementation (gcc, glibc, 64 bits), it *can* "work":
```
#include <stdio.h>
int main(void) {
unsigned long x = 123456789;
printf("sizeof (unsigned) = %zu\n", sizeof (unsigned));
printf("sizeof (unsigned long) = %zu\n", sizeof (unsigned long));
printf("x = %u\n", x);
}
```
The output on my system (after some compiler warnings):
```
sizeof (unsigned) = 4
sizeof (unsigned long) = 8
x = 123456789
```
Apparently printf tries to grab a 32-bit value and happens to get
the low-order 32 bits of the 64-bit value that was passed. A value
exceeding LONG_MAX is not printed correctly, but in principle it
could be.
Of course I do not advocate doing this other than as a test of an
implementation's behavior.
J.B.S. Haldane famously said that "The Universe is not only queerer
than we suppose, but queerer than we can suppose." The same is
true of undefined behavior.
--
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 Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-15 20:08 -0500 |
| Message-ID | <10kc31m$17vvl$1@dont-email.me> |
| In reply to | #396430 |
On 2026-01-15 07:00, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [...]
>> I'm not sure exactly what you intended. And, as I mentioned in another
>> sub-thread, I've worked for most of my career under rules that
>> prohibited me from writing code that depends upon the kinds of details
>> that you're talking about - as a result, I've had little reason to
>> familiarize myself with those details. However, I can say that using
>> "%u" to print a value of unsigned long type has no chance of working
>> unless unsigned int and unsigned long have the same size and
>> representation. Even if they do, the behavior is still undefined, but
>> there's a pretty good chance it will work.
> [...]
>
> On one implementation (gcc, glibc, 64 bits), it *can* "work":
>
> ```
> #include <stdio.h>
> int main(void) {
> unsigned long x = 123456789;
> printf("sizeof (unsigned) = %zu\n", sizeof (unsigned));
> printf("sizeof (unsigned long) = %zu\n", sizeof (unsigned long));
> printf("x = %u\n", x);
> }
> ```
>
> The output on my system (after some compiler warnings):
>
> ```
> sizeof (unsigned) = 4
> sizeof (unsigned long) = 8
> x = 123456789
> ```
>
> Apparently printf tries to grab a 32-bit value and happens to get
> the low-order 32 bits of the 64-bit value that was passed. A value
> exceeding LONG_MAX is not printed correctly, but in principle it
> could be.
I knew about that possibility, and had intended to word my comment to
cover it, but I forgot. Thanks for covering it. The key point is that
this only works for a large but limited range of values - it cannot work
in general.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-15 18:17 -0800 |
| Message-ID | <87ikd29u7h.fsf@example.invalid> |
| In reply to | #396435 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2026-01-15 07:00, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> [...]
>>> I'm not sure exactly what you intended. And, as I mentioned in another
>>> sub-thread, I've worked for most of my career under rules that
>>> prohibited me from writing code that depends upon the kinds of details
>>> that you're talking about - as a result, I've had little reason to
>>> familiarize myself with those details. However, I can say that using
>>> "%u" to print a value of unsigned long type has no chance of working
>>> unless unsigned int and unsigned long have the same size and
>>> representation. Even if they do, the behavior is still undefined, but
>>> there's a pretty good chance it will work.
>> [...]
>>
>> On one implementation (gcc, glibc, 64 bits), it *can* "work":
>>
>> ```
>> #include <stdio.h>
>> int main(void) {
>> unsigned long x = 123456789;
>> printf("sizeof (unsigned) = %zu\n", sizeof (unsigned));
>> printf("sizeof (unsigned long) = %zu\n", sizeof (unsigned long));
>> printf("x = %u\n", x);
>> }
>> ```
>>
>> The output on my system (after some compiler warnings):
>>
>> ```
>> sizeof (unsigned) = 4
>> sizeof (unsigned long) = 8
>> x = 123456789
>> ```
>>
>> Apparently printf tries to grab a 32-bit value and happens to get
>> the low-order 32 bits of the 64-bit value that was passed. A value
>> exceeding LONG_MAX is not printed correctly, but in principle it
>> could be.
>
> I knew about that possibility, and had intended to word my comment to
> cover it, but I forgot. Thanks for covering it. The key point is that
> this only works for a large but limited range of values - it cannot work
> in general.
I suppose it depends on just what you mean by "in general".
A conforming implementation *could* always print the mathematically
correct value of a 64-bit unsigned long argument when printf is
called with a 32-bit "%u" format. I could speculate about how
this might work, but it doesn't really matter. Probably few if
any implementations behave this way, but the nature of undefined
behavior is that there is no behavior that violates the C standard.
And of course the best advice is "don't do that".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-09 09:25 +0100 |
| Message-ID | <10jqe1c$252te$1@dont-email.me> |
| In reply to | #396288 |
On 08/01/2026 01:38, Michael S wrote: > > 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 can have the opinion that any two integer types of the same size /should/ be fully interchangeable in C. That's a reasonable opinion, and you are not the only one to think that way. But the C language is defined differently. There are a number of situations where different integer types have the same size (and range and representation), yet are different types. On most 32-bit platforms, "long" is the same size as either "int" or "long long". But it is not type-compatible with either. "uint32_t" will probably be an alias for either "unsigned int" or "unsigned long" (but could on some platforms be an alias for "unsigned char", "char", "unsigned short", or an extended integer type). It does not really matter if you think the C language works the way you would like it to - when you program in C, the C standard is the contract between you and the compiler. We all have aspects of C that we dislike, and I am sure the same applies to compiler writers, but we all agree to stick to a common definition of the language. If you try to code in some C-like language that works the way /you/ would like it to, you will run into trouble when the compiler interprets your code differently from how you had intended. Use the types as the standard specifies. If the standard says "use %lu for this type, and %u for that type", then do that. If the standard says "pointers to unsigned int are incompatible with pointers to unsigned long, even if the integer types are the same size", then don't mix such pointer types. It's not that hard. Yes, occasionally it can be a little inconvenient or "ugly", but writing correct code pays off.
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web