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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-12 08:34 +0100 |
| Message-ID | <10k285a$25sqv$3@dont-email.me> |
| In reply to | #396358 |
On 12/01/2026 07:47, Keith Thompson wrote: > Michael S <already5chosen@yahoo.com> writes: >> On Sun, 11 Jan 2026 11:51:43 -0800 >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> Michael S <already5chosen@yahoo.com> writes: > [...] >>>> Properties are: >>>> a) uint32_t aliased to 'unsigned long' >>>> b) 'unsigned int' is at least 32-bit wide. >>> >>> It seems unlikely that any implementation would make such a >>> choice. Can you name one that does? >> >> Four out of four target for which I write C programs for living in this >> decade: >> - Altera Nios2 (nios2-elf-gcc) >> - Arm Cortex-M bare metal (arm-none-eabi-gcc) >> - Win32-i386, various compilers >> - Win64-Amd64,various compilers > > I find that surprising. I just tried a test program that prints > the name of the type uint32_t is an alias for (using _Generic), > and it's alias to unsigned int on every implementation I tried. > (Your properties are limited to systems with 32-bit int and long.) > On 32-bit embedded systems, it is common for uint32_t to be unsigned long, even though unsigned int is the same size. It perhaps comes from the pretty much universal definition of uint32_t as unsigned long for smaller embedded systems where "int" is less than 32 bits. On Linux systems, unsigned int seems more common even on 32-bit systems. Thus 32-bit EABI ARM uses unsigned long, while 32-bit Linux ARM uses unsigned int. (Common, of course, does not mean guaranteed - there are no doubt exceptions to the general pattern.) > For an implementation where int and long are both 32 bits, it > wouldn't have surprised me for uint32_t to be an alias either for > unsigned int or for unsigned long, and I wouldn't care either way > beyond idle curiosity, but all the implementations I've tried choose > to use unsigned int. > >> Well, if I would be pedantic, then in this decade I also wrote several >> programs for Arm32 Linux, where I don't know whether uint32_t is alias >> of 'unsigned int' or 'unsigned long', few programs for AMD64 Linux, >> where I know that uint32_t is an alias of 'unsigned long' and may be one >> program for ARM64 Linux that is the same as AMD64 Linux. >> But all those outliers together constitute a tiny fraction of the code >> that I wrote recently. > > One advantage of my approach is that I don't have to know or care > what the underlying type of uint32_t is. > Indeed. (I also write non-portable code where I /do/ know the underlying type - so I might use "lu" directly for uint32_t. But I know the code will not be used on other targets, and I know I have the correct specifier for the target I am using.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-12 11:24 +0200 |
| Message-ID | <20260112112409.00007207@yahoo.com> |
| In reply to | #396358 |
On Sun, 11 Jan 2026 22:47:40 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > On Sun, 11 Jan 2026 11:51:43 -0800 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: > [...] > >> > Properties are: > >> > a) uint32_t aliased to 'unsigned long' > >> > b) 'unsigned int' is at least 32-bit wide. > >> > >> It seems unlikely that any implementation would make such a > >> choice. Can you name one that does? > > > > Four out of four target for which I write C programs for living in > > this decade: > > - Altera Nios2 (nios2-elf-gcc) > > - Arm Cortex-M bare metal (arm-none-eabi-gcc) > > - Win32-i386, various compilers > > - Win64-Amd64,various compilers > > I find that surprising. I just tried a test program that prints > the name of the type uint32_t is an alias for (using _Generic), > and it's alias to unsigned int on every implementation I tried. > (Your properties are limited to systems with 32-bit int and long.) > > For an implementation where int and long are both 32 bits, it > wouldn't have surprised me for uint32_t to be an alias either for > unsigned int or for unsigned long, and I wouldn't care either way > beyond idle curiosity, but all the implementations I've tried choose > to use unsigned int. > Did you try any implementation that is not based on SysV ABI? > > Well, if I would be pedantic, then in this decade I also wrote > > several programs for Arm32 Linux, where I don't know whether > > uint32_t is alias of 'unsigned int' or 'unsigned long', few > > programs for AMD64 Linux, where I know that uint32_t is an alias of > > 'unsigned long' and may be one program for ARM64 Linux that is the > > same as AMD64 Linux. But all those outliers together constitute a > > tiny fraction of the code that I wrote recently. > > One advantage of my approach is that I don't have to know or care > what the underlying type of uint32_t is. > By 'you approach' you mean casting to 'unsigned long' and using %ld formatter? As I said in other post, ideologically I like it. The only reason I don't adapt that approach myself is because 'unsigned long' is long (many characters). I'd do exactly that in case of int32_t, except that in practice int32_t is very rare in my code and printing it rarer still. [O.T.] When I can, I try to use signed integer types in preference of unsigned types, but those are mostly plain 'int' and ptrdiff_t, occasionally int16_t, rarely 'long'. int32_t and int64_t are very rare.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-12 10:34 +0200 |
| Message-ID | <20260112103448.00003177@yahoo.com> |
| In reply to | #396352 |
On Sun, 11 Jan 2026 23:51:04 +0200 Michael S <already5chosen@yahoo.com> wrote: > On Sun, 11 Jan 2026 11:51:43 -0800 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > Michael S <already5chosen@yahoo.com> writes: > > > > > On Sat, 10 Jan 2026 22:02:03 -0500 > > > "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: > > > > > >> On 2026-01-09 07:18, Michael S wrote: > > >> > > >>> On Thu, 8 Jan 2026 19:31:13 -0500 > > >>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> > > >>> wrote: > > >> > > >> ... > > >> > > >>>> I'd have no problem with your approach if you hadn't falsely > > >>>> claimed that "It is correct on all platforms". > > >>> > > >>> Which I didn't. > > >> > > >> On 2026-01-07 19:38, Michael S wrote: > > >> ... > > >> > > >>> No, it is correct on all implementation. > > >> > > > > > > The quote is taken out of context. > > > The context was that on platforms that have properties (a) and (b) > > > (see below) printing variables declared as uint32_t via %u is > > > probably UB according to the Standard (I don't know for sure, > > > however it is probable), but it can't cause troubles with > > > production C compiler. Or with any C compiler that is made in > > > intention of being used rather than crafted to prove theoretical > > > points. Properties are: > > > a) uint32_t aliased to 'unsigned long' > > > b) 'unsigned int' is at least 32-bit wide. > > > > It seems unlikely that any implementation would make such a > > choice. Can you name one that does? > > Four out of four target for which I write C programs for living in > this decade: > - Altera Nios2 (nios2-elf-gcc) > - Arm Cortex-M bare metal (arm-none-eabi-gcc) > - Win32-i386, various compilers > - Win64-Amd64,various compilers > > Well, if I would be pedantic, then in this decade I also wrote several > programs for Arm32 Linux, where I don't know whether uint32_t is alias > of 'unsigned int' or 'unsigned long', few programs for AMD64 Linux, > where I know that uint32_t is an alias of 'unsigned long' Cut&past mistake here: read " of 'unsigned int' " > and may be > one program for ARM64 Linux that is the same as AMD64 Linux. > But all those outliers together constitute a tiny fraction of the code > that I wrote recently. > >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-02-03 07:47 -0800 |
| Message-ID | <86ms1pj0bc.fsf@linuxsc.com> |
| In reply to | #396352 |
Michael S <already5chosen@yahoo.com> writes:
> On Sun, 11 Jan 2026 11:51:43 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Sat, 10 Jan 2026 22:02:03 -0500
>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote:
>>>
>>>> On 2026-01-09 07:18, Michael S wrote:
>>>>
>>>>> On Thu, 8 Jan 2026 19:31:13 -0500
>>>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu>
>>>>> wrote:
>>>>
>>>> ...
>>>>
>>>>>> I'd have no problem with your approach if you hadn't falsely
>>>>>> claimed that "It is correct on all platforms".
>>>>>
>>>>> Which I didn't.
>>>>
>>>> On 2026-01-07 19:38, Michael S wrote:
>>>> ...
>>>>
>>>>> No, it is correct on all implementation.
>>>>
>>>
>>> The quote is taken out of context.
>>> The context was that on platforms that have properties (a) and (b)
>>> (see below) printing variables declared as uint32_t via %u is
>>> probably UB according to the Standard (I don't know for sure,
>>> however it is probable), but it can't cause troubles with
>>> production C compiler. Or with any C compiler that is made in
>>> intention of being used rather than crafted to prove theoretical
>>> points. Properties are:
>>> a) uint32_t aliased to 'unsigned long'
>>> b) 'unsigned int' is at least 32-bit wide.
>>
>> It seems unlikely that any implementation would make such a
>> choice. Can you name one that does?
>
> Four out of four target for which I write C programs for living in this
> decade:
> - Altera Nios2 (nios2-elf-gcc)
> - Arm Cortex-M bare metal (arm-none-eabi-gcc)
> - Win32-i386, various compilers
> - Win64-Amd64,various compilers
Interesting. I wonder what factors motivated such a choice.
> Well, if I would be pedantic, then in this decade I also wrote several
> programs for Arm32 Linux, where I don't know whether uint32_t is alias
> of 'unsigned int' or 'unsigned long', few programs for AMD64 Linux,
> where I know that uint32_t is an alias of 'unsigned long' and may be one
> program for ARM64 Linux that is the same as AMD64 Linux.
> But all those outliers together constitute a tiny fraction of the code
> that I wrote recently.
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 );
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-03 19:51 +0000 |
| Message-ID | <10ltjjt$1o4pk$1@dont-email.me> |
| In reply to | #396575 |
On 03/02/2026 15:47, Tim Rentsch wrote: > Michael S <already5chosen@yahoo.com> writes: > >> On Sun, 11 Jan 2026 11:51:43 -0800 >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> Michael S <already5chosen@yahoo.com> writes: >>> >>>> On Sat, 10 Jan 2026 22:02:03 -0500 >>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> wrote: >>>> >>>>> On 2026-01-09 07:18, Michael S wrote: >>>>> >>>>>> On Thu, 8 Jan 2026 19:31:13 -0500 >>>>>> "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> >>>>>> wrote: >>>>> >>>>> ... >>>>> >>>>>>> I'd have no problem with your approach if you hadn't falsely >>>>>>> claimed that "It is correct on all platforms". >>>>>> >>>>>> Which I didn't. >>>>> >>>>> On 2026-01-07 19:38, Michael S wrote: >>>>> ... >>>>> >>>>>> No, it is correct on all implementation. >>>>> >>>> >>>> The quote is taken out of context. >>>> The context was that on platforms that have properties (a) and (b) >>>> (see below) printing variables declared as uint32_t via %u is >>>> probably UB according to the Standard (I don't know for sure, >>>> however it is probable), but it can't cause troubles with >>>> production C compiler. Or with any C compiler that is made in >>>> intention of being used rather than crafted to prove theoretical >>>> points. Properties are: >>>> a) uint32_t aliased to 'unsigned long' >>>> b) 'unsigned int' is at least 32-bit wide. >>> >>> It seems unlikely that any implementation would make such a >>> choice. Can you name one that does? >> >> Four out of four target for which I write C programs for living in this >> decade: >> - Altera Nios2 (nios2-elf-gcc) >> - Arm Cortex-M bare metal (arm-none-eabi-gcc) >> - Win32-i386, various compilers >> - Win64-Amd64,various compilers > > Interesting. I wonder what factors motivated such a choice. > >> Well, if I would be pedantic, then in this decade I also wrote several >> programs for Arm32 Linux, where I don't know whether uint32_t is alias >> of 'unsigned int' or 'unsigned long', few programs for AMD64 Linux, >> where I know that uint32_t is an alias of 'unsigned long' and may be one >> program for ARM64 Linux that is the same as AMD64 Linux. >> But all those outliers together constitute a tiny fraction of the code >> that I wrote recently. > > 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?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-02-04 06:22 -0800 |
| Message-ID | <865x8cio5y.fsf@linuxsc.com> |
| In reply to | #396576 |
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? Also what sort of opaque types do you have in mind? What is the problem you want to solve here?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-04 16:44 +0000 |
| Message-ID | <10lvt1s$2fu8f$1@dont-email.me> |
| In reply to | #396587 |
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 '?'
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-04 18:12 +0100 |
| Message-ID | <10lvul0$2gps1$1@dont-email.me> |
| In reply to | #396588 |
On 04/02/2026 17:44, Bart wrote:
> 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 '?'
>
>
So are you asking because you don't know what Tim's construction does
with these types, or because you want to know if there is a portable and
safe way to print out any arithmetic type, or because you are perfectly
aware that C's printf has limitations and you want to post about how
terrible C is and how great your own language is?
The point of both Tim's and Keith's solutions is that you do /not/ need
to know the exact type of the expression you are printing - C's
conversion rules let them work with a range of different original types.
They were both picked specifically for the case of "uint32_t", but can
handle more types. Tim's can be used for any integer type of rank up to
"unsigned long int" (and thus not "long long" types), while Keith's will
be fine with any integer type and any floating point type as long as the
value of the integer part of the floating point value is within the
range of "unsigned long int".
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-02-04 18:48 +0100 |
| Message-ID | <10m00oq$2d054$1@dont-email.me> |
| In reply to | #396589 |
On 2026-02-04 18:12, David Brown wrote: > On 04/02/2026 17:44, Bart wrote: >> On 04/02/2026 14:22, Tim Rentsch wrote: >>> 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. [...] > >[...], or because you are perfectly > aware that C's printf has limitations and you want to post about how > terrible C is and how great your own language is? That was pretty obvious [to me] since I seem to recall that just recently he had posted an example of his language with a generic formatter, IIRC. Of course he has a point in criticizing this old 'printf' design; providing a well typed argument but needing to "find" the right formatting specifier anyway. Crude, but that's "C". And rarely anyone will be interested in discussions about this old inherent "C" design. Likewise about discussions of his "own language(s)". Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-04 18:11 +0000 |
| Message-ID | <10m024m$2hqvi$1@dont-email.me> |
| In reply to | #396589 |
On 04/02/2026 17:12, David Brown wrote:
> On 04/02/2026 17:44, Bart wrote:
>> 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 '?'
>>
>>
>
> So are you asking because you don't know what Tim's construction does
> with these types, or because you want to know if there is a portable and
> safe way to print out any arithmetic type, or because you are perfectly
> aware that C's printf has limitations and you want to post about how
> terrible C is and how great your own language is?
>
I was reponding to the example of a single variable with ONE type, that
happens to be uint32_t, apparently a standard C type.
Yes maybe that particular strategy might work (you know it is an integer
and that it is unsigned).
But it doesn't solve the general problem: even if there is a single type
involved, it might be conditional or opaque (or its type is changed
required all format codes to be revised.
Or there is an expression of mixed types.
> 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.
> The point of both Tim's and Keith's solutions is that you do /not/ need
> to know the exact type of the expression you are printing - C's
> conversion rules let them work with a range of different original types.
OK.
> They were both picked specifically for the case of "uint32_t", but can
> handle more types. Tim's can be used for any integer type of rank up to
> "unsigned long int" (and thus not "long long" types),
So not such a great range.
while Keith's will
> be fine with any integer type and any floating point type as long as the
> value of the integer part of the floating point value is within the
> range of "unsigned long int".
Better, *if* you know the expression has an unsigned integer type.
So as far as I'm concerned, the general problem remains. There are only
workarounds and special cases that every user has to work out for
themselves.
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?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-04 21:09 +0100 |
| Message-ID | <10m091i$2kiff$1@dont-email.me> |
| In reply to | #396591 |
On 04/02/2026 19:11, Bart wrote:
> On 04/02/2026 17:12, David Brown wrote:
>> On 04/02/2026 17:44, Bart wrote:
>>> 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 '?'
>>>
>>>
>>
>> So are you asking because you don't know what Tim's construction does
>> with these types, or because you want to know if there is a portable
>> and safe way to print out any arithmetic type, or because you are
>> perfectly aware that C's printf has limitations and you want to post
>> about how terrible C is and how great your own language is?
>>
>
> I was reponding to the example of a single variable with ONE type, that
> happens to be uint32_t, apparently a standard C type.
>
You know perfectly well that "uint32_t" is not a standard type - it is a
typedef for a standard or extended integer type.
And you know perfectly well that the constructions here from Tim and
Keith demonstrate safe ways to print values of type "uint32_t",
regardless of whether it is a typedef for "unsigned int", "unsigned long
int", or an extend integer type. That was the point of their posts.
> Yes maybe that particular strategy might work (you know it is an integer
> and that it is unsigned).
What did you think an "uint32_t" was, if not a type of unsigned integer?
And there is no "maybe" about it - the strategies work.
If you have other arithmetic types, then you need to adapt the strategy
to fit - you need something that covers the ranges of the data you are
dealing with.
>
> But it doesn't solve the general problem: even if there is a single type
> involved, it might be conditional or opaque (or its type is changed
> required all format codes to be revised.
>
> Or there is an expression of mixed types.
>
There is no such thing as an "expression of mixed types". There are
expressions formed with operators applied to subexpressions of different
types - the rules of C state very clearly how those subexpressions are
converted. (For most binary operators, these are the "usual arithmetic
conversions".) You know this too.
> > 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.
>
No, not all - but certainly many languages have more convenient handling
of printing expressions. C's method works - it has done its job for
half a century - but no one will argue that it is a bit clumsy. And if
you are rough or lazy about it, it can be unsafe. If it bothers you too
much, you can make a reasonable enough type-safe print facility with
_Generic and variadic macros.
>
>> The point of both Tim's and Keith's solutions is that you do /not/
>> need to know the exact type of the expression you are printing - C's
>> conversion rules let them work with a range of different original types.
>
> OK.
>
>> They were both picked specifically for the case of "uint32_t", but
>> can handle more types. Tim's can be used for any integer type of rank
>> up to "unsigned long int" (and thus not "long long" types),
>
> So not such a great range.
The used "unsigned long" and 0UL precisely because the range was great
enough for the purpose at hand. Changing those to "%llu", "unsigned
long long" and "0ULL" is an obvious way to cover all unsigned integer
types. 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.)
>
> while Keith's will
>> be fine with any integer type and any floating point type as long as
>> the value of the integer part of the floating point value is within
>> the range of "unsigned long int".
>
> Better, *if* you know the expression has an unsigned integer type.
>
Keith's method will also work as long as the type can be converted to an
"unsigned long" - that includes floating point values as long as they
are in range. Of course if he expected to print out floating point
types, he'd use an appropriate floating point format.
> So as far as I'm concerned, the general problem remains. There are only
> workarounds and special cases that every user has to work out for
> themselves.
>
If you can't figure this out, buy a "C programming for dummies" book and
start at the beginning. Yes, printf formatting can be ugly and
inconvenient compared to a number of other languages, but it is hardly
rocket science.
> 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?
C23 formats haven't made an impact because C23 library support is only
now beginning to appear. _Generic is used by people who know how to
program with C11 and find _Generic useful. In practice it is quite
rarely needed, since generally C programmers know what types they are
using, and often a normal macro is all you need. But I've used _Generic
occasionally myself.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-04 20:42 +0000 |
| Message-ID | <10m0b0g$2l6li$1@dont-email.me> |
| In reply to | #396592 |
On 04/02/2026 20:09, David Brown wrote:
> On 04/02/2026 19:11, Bart wrote:
>> On 04/02/2026 17:12, David Brown wrote:
>>> So are you asking because you don't know what Tim's construction does
>>> with these types, or because you want to know if there is a portable
>>> and safe way to print out any arithmetic type, or because you are
>>> perfectly aware that C's printf has limitations and you want to post
>>> about how terrible C is and how great your own language is?
>>>
>>
>> I was reponding to the example of a single variable with ONE type,
>> that happens to be uint32_t, apparently a standard C type.
>>
>
> You know perfectly well that "uint32_t" is not a standard type - it is a
> typedef for a standard or extended integer type.
>
> And you know perfectly well that the constructions here from Tim and
> Keith demonstrate safe ways to print values of type "uint32_t",
> regardless of whether it is a typedef for "unsigned int", "unsigned long
> int", or an extend integer type. That was the point of their posts.
And one of mine is that you might not know the type is 'uint32_t'.
Even if you were 100% sure, an update might change it, and the format
might no longer be appropriate. (Eg. it might become signed, but gcc
will not report that, at least not with Wall + Wextra + Wpedantic.)
>> Yes maybe that particular strategy might work (you know it is an
>> integer and that it is unsigned).
>
> What did you think an "uint32_t" was, if not a type of unsigned integer?
> And there is no "maybe" about it - the strategies work.
See above.
> If you have other arithmetic types, then you need to adapt the strategy
> to fit - you need something that covers the ranges of the data you are
> dealing with.
>
>>
>> But it doesn't solve the general problem: even if there is a single
>> type involved, it might be conditional or opaque (or its type is
>> changed required all format codes to be revised.
>>
>> Or there is an expression of mixed types.
>>
>
> There is no such thing as an "expression of mixed types". There are
> expressions formed with operators applied to subexpressions of different
> types - the rules of C state very clearly how those subexpressions are
> converted. (For most binary operators, these are the "usual arithmetic
> conversions".) You know this too.
An expression of mixed types means one that involves a number of
different types amongst its types.
Sure, the rules will tell you what the result will be, but you have to
work it out, and to do that, you have to know what each of those types
are (again, see above).
Try this one for example; T, U and V are three numeric types exported by
version 2.1 of some library:
T x;
U y;
V z;
printf("%?", x + y * z);
You can spend some time hunting down those types and figuring out the
result type (either one of T U V or maybe W). But how confident will you
be that it will still work on 2.2?
The change may be subtle enough that no warning is given, but enough to
give a wrong result.
>> > 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.
>>
>
> No, not all - but certainly many languages have more convenient handling
> of printing expressions. C's method works - it has done its job for
> half a century - but no one will argue that it is a bit clumsy. And if
> you are rough or lazy about it, it can be unsafe. If it bothers you too
> much, you can make a reasonable enough type-safe print facility with
> _Generic and variadic macros.
So, a workaround that every user has to bother with. That's a bad sign.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-05 12:41 +0100 |
| Message-ID | <10m1vl7$35irp$1@dont-email.me> |
| In reply to | #396593 |
On 04/02/2026 21:42, Bart wrote:
> On 04/02/2026 20:09, David Brown wrote:
>> On 04/02/2026 19:11, Bart wrote:
>>> On 04/02/2026 17:12, David Brown wrote:
>
>>>> So are you asking because you don't know what Tim's construction
>>>> does with these types, or because you want to know if there is a
>>>> portable and safe way to print out any arithmetic type, or because
>>>> you are perfectly aware that C's printf has limitations and you want
>>>> to post about how terrible C is and how great your own language is?
>>>>
>>>
>>> I was reponding to the example of a single variable with ONE type,
>>> that happens to be uint32_t, apparently a standard C type.
>>>
>>
>> You know perfectly well that "uint32_t" is not a standard type - it is
>> a typedef for a standard or extended integer type.
>>
>> And you know perfectly well that the constructions here from Tim and
>> Keith demonstrate safe ways to print values of type "uint32_t",
>> regardless of whether it is a typedef for "unsigned int", "unsigned
>> long int", or an extend integer type. That was the point of their posts.
>
> And one of mine is that you might not know the type is 'uint32_t'.
>
Just as long as we are clear that Tim and Keith's constructs were for
anything other than "uint32_t", whatever its underlying type may be.
For other selections of types, other similar constructs are needed, as
appropriate.
> Even if you were 100% sure, an update might change it, and the format
> might no longer be appropriate. (Eg. it might become signed, but gcc
> will not report that, at least not with Wall + Wextra + Wpedantic.)
Again, you are talking about types other than uint32_t? Although the
underlying type used for "uint32_t" is not known, its characteristics
are, including that it is unsigned.
Usually when you have a type T in your code, you know some things about
it - you typically know if it is arithmetic, integer, floating point,
you know something about its range. How much you know will vary, but a
type you know absolutely nothing about is unlikely to be of any use in code.
>
>>> Yes maybe that particular strategy might work (you know it is an
>>> integer and that it is unsigned).
>>
>> What did you think an "uint32_t" was, if not a type of unsigned
>> integer? And there is no "maybe" about it - the strategies work.
>
> See above.
>
>
>> If you have other arithmetic types, then you need to adapt the
>> strategy to fit - you need something that covers the ranges of the
>> data you are dealing with.
>>
>>>
>>> But it doesn't solve the general problem: even if there is a single
>>> type involved, it might be conditional or opaque (or its type is
>>> changed required all format codes to be revised.
>>>
>>> Or there is an expression of mixed types.
>>>
>>
>> There is no such thing as an "expression of mixed types". There are
>> expressions formed with operators applied to subexpressions of
>> different types - the rules of C state very clearly how those
>> subexpressions are converted. (For most binary operators, these are
>> the "usual arithmetic conversions".) You know this too.
>
> An expression of mixed types means one that involves a number of
> different types amongst its types.
>
Okay, that's what /you/ mean by that phrase. It is not an accurate
description - in any statically typed language, an expression will have
a single type. Subexpressions can be different types. But while I do
not approve of your terms here, I do understand what you are talking about.
> Sure, the rules will tell you what the result will be, but you have to
> work it out, and to do that, you have to know what each of those types
> are (again, see above).
No, the /compiler/ has to work it out. Whether /you/ need to work it
out or not, depends on what you are doing with the result.
If you have "T x;", and you write "(unsigned long) x" (as Keith
suggested), then you know the type of that expression - without knowing
the type of T. You need to know that "T" is a type that can be
converted to "unsigned long" (any arithmetic or pointer type will do),
and you need to know that the value of "x" is suitable for the
conversion to be defined (so if "x" is floating point, it needs to be in
range). If you don't know at least that much about "x", you probably
should not be writing code with it.
If you write "x + 0UL" (as Tim suggested), you know the resulting type
if "T" is an integer type. If T is a floating point type, however, the
resulting expression will have that floating point type. And if it is a
pointer type, the result will have that pointer type. On the other
hand, you don't have any restrictions in the values of "x".
Do you need to know the /exact/ type of an expression? Sometimes yes,
sometimes no. Since we are talking about ways to print out values
without knowing their exact types, clearly we don't need to know the
exact type here. We need to know certain characteristics, but not all
details. This is very common in coding.
>
> Try this one for example; T, U and V are three numeric types exported by
> version 2.1 of some library:
>
> T x;
> U y;
> V z;
> printf("%?", x + y * z);
>
> You can spend some time hunting down those types and figuring out the
> result type (either one of T U V or maybe W). But how confident will you
> be that it will still work on 2.2?
>
You need to know enough about the types to know how to use them for the
things you want to do with them. In the real world, the names of the
types usually makes the basics clear. For a library, the documentation
will make it clear. So for example, the "time_t" type in the C language
is documented for use in functions like "mktime" and "gmtime" - but not
for printing out directly with printf. You are given that it is a "real
type" - so you can convert it to a double and printf that, or you can
use functions like "gmtime" and print out the elements of the struct tm.
C is a statically typed language. In a statically typed language, you
cannot have a function that can handle arbitrary types. Languages that
provide a to print arbitrary types do so using methods that are not
supported by C - templates, overloads, type methods or helper functions
to convert different types to a common string format, etc.
> The change may be subtle enough that no warning is given, but enough to
> give a wrong result.
So make sure you know what you are doing. Know /enough/ about the types
you are using, and how you can safely use them.
Ultimately, you can't protect against all sources of idiocy or malice.
If a library has "typedef long int integer;" and later versions have
"typedef _Complex double integer;", then the library is at fault.
>
>
>>> > 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.
>>>
>>
>> No, not all - but certainly many languages have more convenient
>> handling of printing expressions. C's method works - it has done its
>> job for half a century - but no one will argue that it is a bit
>> clumsy. And if you are rough or lazy about it, it can be unsafe. If
>> it bothers you too much, you can make a reasonable enough type-safe
>> print facility with _Generic and variadic macros.
>
> So, a workaround that every user has to bother with. That's a bad sign.
>
How many people do you know who have actually written and use a C11
print system using _Generic and variadic macros? I don't know any.
(I've written simple examples as proofs of concept, posted in this
group, but not for real use.) It turns out that people /don't/ have to
have workarounds. "printf" has its limitations - there's no doubt
there. But it is good enough for most people and most uses.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-05 17:42 +0000 |
| Message-ID | <10m2kpb$3cm2p$1@dont-email.me> |
| In reply to | #396605 |
On 05/02/2026 11:41, David Brown wrote:
> On 04/02/2026 21:42, Bart wrote:
> Usually when you have a type T in your code, you know some things about
> it - you typically know if it is arithmetic, integer, floating point,
> you know something about its range.
How about time_t, clock_t, off_t?
> How much you know will vary, but a
> type you know absolutely nothing about is unlikely to be of any use in
> code.
The problem is that that format code is tied to the type of the
expression. That means that as your program evolves and the types
change, or the expression changes (so another term's type becomes
dominant), then you have to check all such format codes.
>>
>>>> Yes maybe that particular strategy might work (you know it is an
>>>> integer and that it is unsigned).
>>>
>>> What did you think an "uint32_t" was, if not a type of unsigned
>>> integer? And there is no "maybe" about it - the strategies work.
>>
>> See above.
>>
>>
>>> If you have other arithmetic types, then you need to adapt the
>>> strategy to fit - you need something that covers the ranges of the
>>> data you are dealing with.
>>>
>>>>
>>>> But it doesn't solve the general problem: even if there is a single
>>>> type involved, it might be conditional or opaque (or its type is
>>>> changed required all format codes to be revised.
>>>>
>>>> Or there is an expression of mixed types.
>>>>
>>>
>>> There is no such thing as an "expression of mixed types". There are
>>> expressions formed with operators applied to subexpressions of
>>> different types - the rules of C state very clearly how those
>>> subexpressions are converted. (For most binary operators, these are
>>> the "usual arithmetic conversions".) You know this too.
>>
>> An expression of mixed types means one that involves a number of
>> different types amongst its types.
(Here I meant 'amongst its terms'.)
>
> Okay, that's what /you/ mean by that phrase. It is not an accurate
> description - in any statically typed language, an expression will have
> a single type. Subexpressions can be different types. But while I do
> not approve of your terms here, I do understand what you are talking about.
>
>> Sure, the rules will tell you what the result will be, but you have to
>> work it out, and to do that, you have to know what each of those types
>> are (again, see above).
>
> No, the /compiler/ has to work it out. Whether /you/ need to work it
> out or not, depends on what you are doing with the result.
The compiler will not tell you the format codes to use!
> If you have "T x;", and you write "(unsigned long) x" (as Keith
> suggested), then you know the type of that expression - without knowing
> the type of T. You need to know that "T" is a type that can be
> converted to "unsigned long" (any arithmetic or pointer type will do),
> and you need to know that the value of "x" is suitable for the
> conversion to be defined (so if "x" is floating point, it needs to be in
> range). If you don't know at least that much about "x", you probably
> should not be writing code with it.
I tried this program:
#include <stdio.h>
#include "t.h" // defines T
T F();
int main() {
T x;
x=F();
printf("%lu\n", (unsigned long)x);
}
T happens to be 'int', and F() returns -1. This program however prints
4294967295.
If I change it so that T is 'long long int' and F returns 5000000000,
then it shows 705032704. Not really ideal.
Here a better bet for an unknown type is %f, which gives the right
values, but it appear as -1.00000 etc.
Better still is to use exactly the right format, but that has the issues
I mentioned.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-02-05 18:38 +0000 |
| Message-ID | <6t5hR.10820$NAt7.10392@fx39.iad> |
| In reply to | #396608 |
Bart <bc@freeuk.com> writes: >On 05/02/2026 11:41, David Brown wrote: >> On 04/02/2026 21:42, Bart wrote: > >> Usually when you have a type T in your code, you know some things about >> it - you typically know if it is arithmetic, integer, floating point, >> you know something about its range. > >How about time_t, clock_t, off_t? What about them? time_t has a dedicated formatter (strftime) and parser (strptime). clock_t and off_t can be cast to the largest integer type (e.g. unsigned long) and use the printf '%lu' or "%ld' formatting sequence as required by the application.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-02-05 23:55 +0100 |
| Message-ID | <10m374q$2d053$1@dont-email.me> |
| In reply to | #396608 |
On 2026-02-05 18:42, Bart wrote:
> On 05/02/2026 11:41, David Brown wrote:
>>
>> No, the /compiler/ has to work it out. Whether /you/ need to work it
>> out or not, depends on what you are doing with the result.
>
> The compiler will not tell you the format codes to use!
Well, it seems the compiler I have here does it quite verbosely...
$ cc -o prtfmt prtfmt.c
prtfmt.c: In function ‘main’:
prtfmt.c:8:19: warning: format ‘%d’ expects argument of type ‘int’, but
argument 2 has type ‘double’ [-Wformat=]
8 | printf ("%d\n", f);
| ~^ ~
| | |
| int double
| %f
prtfmt.c:9:19: warning: format ‘%f’ expects argument of type ‘double’,
but argument 2 has type ‘int’ [-Wformat=]
9 | printf ("%f\n", i);
| ~^ ~
| | |
| | int
| double
| %d
...giving information of every kind - here for two basic types, but
it has also the same verbose diagnostics with the '_t' types I tried
(e.g. suggesting '%ld' for a 'time_t' argument).
Note: I'm still acknowledging the unfortunate type/formatter-coupling
notwithstanding.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-05 23:42 +0000 |
| Message-ID | <10m39sd$3ladr$1@dont-email.me> |
| In reply to | #396612 |
On 05/02/2026 22:55, Janis Papanagnou wrote:
> On 2026-02-05 18:42, Bart wrote:
>> On 05/02/2026 11:41, David Brown wrote:
>>>
>>> No, the /compiler/ has to work it out. Whether /you/ need to work it
>>> out or not, depends on what you are doing with the result.
>>
>> The compiler will not tell you the format codes to use!
>
> Well, it seems the compiler I have here does it quite verbosely...
>
>
> $ cc -o prtfmt prtfmt.c
> prtfmt.c: In function ‘main’:
> prtfmt.c:8:19: warning: format ‘%d’ expects argument of type ‘int’, but
> argument 2 has type ‘double’ [-Wformat=]
> 8 | printf ("%d\n", f);
> | ~^ ~
> | | |
> | int double
> | %f
> prtfmt.c:9:19: warning: format ‘%f’ expects argument of type ‘double’,
> but argument 2 has type ‘int’ [-Wformat=]
> 9 | printf ("%f\n", i);
> | ~^ ~
> | | |
> | | int
> | double
> | %d
>
>
> ...giving information of every kind - here for two basic types, but
> it has also the same verbose diagnostics with the '_t' types I tried
> (e.g. suggesting '%ld' for a 'time_t' argument).
>
> Note: I'm still acknowledging the unfortunate type/formatter-coupling
> notwithstanding.
/Some/ compilers with /some/ options will /sometimes/ tell you when
you've got it wrong.
But you first have to make an educated guess, or put in some dummy
format code.
Eventually, it will compile. Until someone else builds your program,
using a slightly different set of headers where certain types are
defined, and then it might either give compiler messages that they have
to fix, or it show wrong results.
If I compile this code with 'gcc -Wall -Wextra -Wpedantic':
#include <stdio.h>
int main() {
int a = -1;
printf("%u", a);
}
it says nothing. The program displays 4294967295 instead of -1.
If compile this version (using %v) using a special extension:
#include <stdio.h>
int main() {
int a = -1;
printf("%v", a);
}
it shows -1. Which is better?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-05 21:10 -0800 |
| Message-ID | <87ikca8nj2.fsf@example.invalid> |
| In reply to | #396613 |
Bart <bc@freeuk.com> writes:
[...]
> /Some/ compilers with /some/ options will /sometimes/ tell you when
> you've got it wrong.
>
> But you first have to make an educated guess, or put in some dummy
> format code.
>
> Eventually, it will compile. Until someone else builds your program,
> using a slightly different set of headers where certain types are
> defined, and then it might either give compiler messages that they
> have to fix, or it show wrong results.
That's not how I do it, and I don't think it's how most programmers do
it.
I know the rules well enough that I can usually write a correct format
string in the first place. If I make a mistake, gcc's warnings are a
nice check.
> If I compile this code with 'gcc -Wall -Wextra -Wpedantic':
>
> #include <stdio.h>
>
> int main() {
> int a = -1;
> printf("%u", a);
> }
>
> it says nothing. The program displays 4294967295 instead of -1.
The behavior is unsurprising. The lack of a warning is very mildly
inconvenient.
> If compile this version (using %v) using a special extension:
>
> #include <stdio.h>
>
> int main() {
> int a = -1;
> printf("%v", a);
> }
>
> it shows -1. Which is better?
The one I can actually use.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-02-06 09:51 +0100 |
| Message-ID | <10m4a1r$3ko8l$1@dont-email.me> |
| In reply to | #396614 |
On 2026-02-06 06:10, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>
>> If I compile this code with 'gcc -Wall -Wextra -Wpedantic':
>>
>> #include <stdio.h>
>>
>> int main() {
>> int a = -1;
>> printf("%u", a);
>> }
>>
>> it says nothing. The program displays 4294967295 instead of -1.
Yes. You instruct 'printf' with '%u' to interpret and display it
(the variable 'a') as unsigned. ('-1' is not an unsigned numeric
representation.) - I wonder what you are thinking here.
>
> The behavior is unsurprising. The lack of a warning is very mildly
> inconvenient.
Indeed unsurprising. And I even don't see any inconvenience given
that even an initialized declaration of 'unsigned a = -1;' is not
considered a problem in "C". I rather learned that to be a useful
code pattern when programming in "C".
Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-06 04:46 -0800 |
| Message-ID | <87ecmy82f8.fsf@example.invalid> |
| In reply to | #396616 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-02-06 06:10, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> If I compile this code with 'gcc -Wall -Wextra -Wpedantic':
>>>
>>> #include <stdio.h>
>>>
>>> int main() {
>>> int a = -1;
>>> printf("%u", a);
>>> }
>>>
>>> it says nothing. The program displays 4294967295 instead of -1.
>
> Yes. You instruct 'printf' with '%u' to interpret and display it
> (the variable 'a') as unsigned. ('-1' is not an unsigned numeric
> representation.) - I wonder what you are thinking here.
>
>> The behavior is unsurprising. The lack of a warning is very mildly
>> inconvenient.
>
> Indeed unsurprising. And I even don't see any inconvenience given
> that even an initialized declaration of 'unsigned a = -1;' is not
> considered a problem in "C". I rather learned that to be a useful
> code pattern when programming in "C".
Sure, but the point is that the program has undefined behavior.
If you define `unsigned a = -1;`, the value of the initializer is
implicitly converted from int to unsigned, and the value of UINT_MAX
is stored in `a`. That's well defined.
Passing a argument of type int to printf with a "%u" format is
well defined if and only if the value of the argument is within
the ranges of both types (which is almost certainly equivalent to
it being non-negative). This is strongly implied prior to C23,
and guaranteed in C23. There is no implicit conversion; the int
is treated as if it were of type unsigned int. In practice, it's
almost certain to display the value of UINT_MAX unless the compiler
goes out of its way to do something else.
A warning would not be inappropriate -- and in fact clang version
21 does issue a warning with "-Weverything". (The warning refers to
"-Wformat", which by itself doesn't trigger the warning; that might
be a bug.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web