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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-08 11:35 +0100 |
| Message-ID | <10jo19g$1df1o$1@dont-email.me> |
| In reply to | #396285 |
On 08/01/2026 00:26, Michael S wrote:
> On Wed, 07 Jan 2026 13:28:45 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>> On Tue, 6 Jan 2026 10:31:41 -0500
>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>>>> On 2026-01-06 04:29, Michael S wrote:
>>>>>>> On Tue, 6 Jan 2026 00:27:04 -0000 (UTC)
>>>>>>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>>>> ...
>>>>>>>> Section 7.8 of the C spec defines macros you can use so you
>>>>>>>> don’t have to hard-code assumptions about the lengths of
>>>>>>>> integers in printf-format strings.
>>>>>>>
>>>>>>> Did you ever try to use them? They look ugly.
>>>>>>
>>>>>> Which is more important, correctness or beauty?
>>>>>
>>>>> It depends.
>>>>>
>>>>> When I know for sure that incorrectness has no consequences, like
>>>>> in case of using %u to print 'unsigned long' on target with 32-bit
>>>>> longs, or like using %llu to print 'unsigned long' on target with
>>>>> 64-bit longs, then beauty wins. Easily.
>>>>
>>>> Seriously?
>>>>
>>>> An example:
>>>>
>>>> unsigned long n = 42;
>>>> printf("%u\n", n); // incorrect
>>>> printf("%lu\n", n); // correct
>>>>
>>>> Are you really saying that the second version is so much uglier
>>>> than the first that you'd rather write incorrect code?
>>>
>>> I suspect he may have been referring to code that needs
>>> to build for both 32-bit and 64-bit targets. One might
>>> typedef 'uint64' to be unsigned long long on both targets
>>> and just use %llu for the format string. BTDT.
>>
>> In the quoted paragraph above, Michael wrote about using %u to print
>> unsigned long, not about using %u to print some type hidden behind
>> a typedef. If he didn't mean that, he can say so.
>>
>> But even if he meant to talk about printing, say, uint64_t values,
>> my point stands.
>>
>> I wouldn't define my own "uint64" type. I'd just use "uint64_t",
>> defined in <stdint.h>. And I'd use one of several *correct* ways
>> to print uint64_t values.
>>
>> Michael, if you'd care to clarify, given:
>>
>> unsigned long n = 42;
>> printf("%u\n", n); // incorrect
>> printf("%lu\n", n); // correct
>>
>> (and assuming that unsigned int and unsigned long are the same width
>> on the current implementation), do you really prefer the version
>> marked as "incorrect"?
>>
>
> I hoped that I already clarified that point more than one time.
> Obviously, I hoped wrong.
>
> In the case I am talking about n declared as uint32_t.
> uint32_t is an alias of 'unsigned long' on 32-bit embedded targets, on
> 32-bit Linux, on 32-bit Windows and on 64-bit Windows. It is
> alias of 'unsigned int' on 64-bit Linux.
"uint32_t" is an alias of "unsigned long" in the common embedded ABI for
32-bit ARM, as used by gcc and clang. I haven't tested if it is the
same on the five other 32-bit proprietary ARM compilers I know of (IAR,
GHS, Metrowerks, ImageCraft, ARM/Keil), and there are no doubt many
other ARM compilers I have not heard of. I think I have used perhaps
seven other 32-bit embedded processor architectures at least
occasionally, and can probably think of a maybe another ten that I have
never used. And there are many more.
I think it would be extraordinarily arrogant of me to claim I know that
"uint32_t is unsigned long on 32-bit embedded targets". Do you have
such a wide experience that /you/ can justify that claim?
Indeed, a quick check using godbolt.org shows that on 32-bit ARM Linux,
uint32_t is "unsigned int", and for other 32-bit targets there is a mixture.
> Sometimes I move code between targets by myself, sometimes, rarely,
> other people do it. I don't want to have different versions of the code
> and I don't want to use ugly standard specifiers. Between two pretty
> and working variants I prefer the shorter one. Partly because it is
> guaranteed to work correctly on all my targets, including LIN64, but
> more importantly (in practice, 64-bit Linux is a very rare target in my
> daily routine) just because it is shorter. And I don't care that it is
> formally "incorrect" on my more common targets. Or may be not
> "formally", but both gcc and clang think so.
>
This seems like a fine example of cutting off your own nose to spite
your face. The single worst feature (IMHO) of printf and friends is
that you have to match up the format string with the parameters and
their types, or you have UB. Thus most compilers and static checkers
can check literal format strings and the compare them to the number and
types of the parameters. Warnings like gcc's "-Wformat" turn one of C's
biggest static checking holes into almost a non-issue for many cases.
And you throw that out just because you think "%lu" is uglier than "%u".
I've been working with embedded C development for 30+ years. And I find
that embedded C developers fall into two categories - those that use
compiler warnings as obsessively as practically possible, and those that
write crappy code with glaring errors. That division is almost
independent of experience - people who have been in the branch for
decades make mistakes too.
I don't think you will find anyone who will tell you "PRIu32" and
friends are nice and neat, and look good in a string literal. And if
you are writing code that does not have to be portable (most code does
not), I see nothing wrong with using "%lu" for uint32_t if you know your
platform makes it an unsigned long int. Or you can, as others have
suggested, use "%u" and cast your uint32_t to "unsigned" (or "%lu" and
"unsigned long", or whatever makes sense to you). If you have a modern
enough C library, you can use "%w32u" for uint32_t. Or you can use your
own specific functions (very common in the embedded world - "printf" has
a /lot/ overhead), or variadic and _Generic macros to get type-safe
printing. There are many possibilities of doing this right (where
"right" depends on your balances between convenience and portability) -
there is no justification that I can see for doing it wrong.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-06 19:44 -0500 |
| Message-ID | <10jka9v$3jbe4$6@dont-email.me> |
| In reply to | #396225 |
On 2026-01-06 13:05, Michael S wrote: > On Tue, 6 Jan 2026 10:31:41 -0500 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > >> On 2026-01-06 04:29, Michael S wrote: >>> On Tue, 6 Jan 2026 00:27:04 -0000 (UTC) >>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> ... >>>> Section 7.8 of the C spec defines macros you can use so you don’t >>>> have to hard-code assumptions about the lengths of integers in >>>> printf-format strings. >>> >>> Did you ever try to use them? They look ugly. >> >> Which is more important, correctness or beauty? >> > > It depends. > > When I know for sure that incorrectness has no consequences, like If it did in fact have no consequences, it wouldn't be incorrect. It's the bad consequences of using the wrong format specifier that are the reason you should be avoiding doing so. It has undefined behavior, but the most common consequence is relatively mild - it just prints out the wrong value. Only in unusual circumstance can it result in memory access problems, or other more serious consequences. > in case of using %u to print 'unsigned long' on target with 32-bit > longs, or like using %llu to print 'unsigned long' on target with > 64-bit longs, then beauty wins. Easily. You've got it backwards. "%u" is the correct specifier to use for unsigned long on all platforms, whether unsigned long is 32, 36, or even 48 bits. It is NOT the right specifier to use for any of the standard typedefs, such as time_t or uint32_t, unless you are certain that it is a typedef for unsigned long by the particular implementation you're currently using. The reason that they are typedefs is precisely because they can be typedef'd to different types by different implementations. >> If you know that an expression has one of the standard-named types or >> typedefs for with there is a corresponding printf() specifier, you >> should use that specifier. Otherwise, if you know that an expression >> has one of the types declared in <stdint.h>, you should use the >> corresponding macro #defined in <inttypes.h> to print it. > > I should? Really? > Sorry, James, but you have no authority to make such statements. It is not a command, it is advice. You're free to ignore it. If you make a habit of ignoring it, you're likely to someday find that your code malfunctions when porting to a new platform.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-01-07 01:14 +0000 |
| Message-ID | <10jkc1d$9mv1$1@dont-email.me> |
| In reply to | #396237 |
On 07/01/2026 00:44, James Kuyper wrote: > On 2026-01-06 13:05, Michael S wrote: >> in case of using %u to print 'unsigned long' on target with 32-bit >> longs, or like using %llu to print 'unsigned long' on target with >> 64-bit longs, then beauty wins. Easily. > > You've got it backwards. "%u" is the correct specifier to use for > unsigned long on all platforms, whether unsigned long is 32, 36, or even > 48 bits. So not "%lu"?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-07 13:41 +0200 |
| Message-ID | <20260107134154.0000165b@yahoo.com> |
| In reply to | #396242 |
On Wed, 7 Jan 2026 01:14:21 +0000 bart <bc@freeuk.com> wrote: > On 07/01/2026 00:44, James Kuyper wrote: > > On 2026-01-06 13:05, Michael S wrote: > > >> in case of using %u to print 'unsigned long' on target with 32-bit > >> longs, or like using %llu to print 'unsigned long' on target with > >> 64-bit longs, then beauty wins. Easily. > > > > You've got it backwards. "%u" is the correct specifier to use for > > unsigned long on all platforms, whether unsigned long is 32, 36, or > > even 48 bits. > > So not "%lu"? > > gcc and clang maintainers certainly think so.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-01-07 15:54 +0000 |
| Message-ID | <10jlvit$opc3$1@dont-email.me> |
| In reply to | #396257 |
On 07/01/2026 11:41, Michael S wrote:
> On Wed, 7 Jan 2026 01:14:21 +0000
> bart <bc@freeuk.com> wrote:
>
>> On 07/01/2026 00:44, James Kuyper wrote:
>>> On 2026-01-06 13:05, Michael S wrote:
>>
>>>> in case of using %u to print 'unsigned long' on target with 32-bit
>>>> longs, or like using %llu to print 'unsigned long' on target with
>>>> 64-bit longs, then beauty wins. Easily.
>>>
>>> You've got it backwards. "%u" is the correct specifier to use for
>>> unsigned long on all platforms, whether unsigned long is 32, 36, or
>>> even 48 bits.
>>
>> So not "%lu"?
>>
>>
>
> gcc and clang maintainers certainly think so.
>
They think it is correct or not correct? If I compile this:
#include <stdio.h>
int main() {
unsigned long a=0;
printf("%u", a);
}
then gcc complains (given suitable options):
warning: format '%u' expects argument of type 'unsigned int', but
argument 2 has type 'long unsigned int' [-Wformat=]
The suggests it is not correct.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-07 18:17 +0200 |
| Message-ID | <20260107181716.000045c0@yahoo.com> |
| In reply to | #396270 |
On Wed, 7 Jan 2026 15:54:06 +0000
bart <bc@freeuk.com> wrote:
> On 07/01/2026 11:41, Michael S wrote:
> > On Wed, 7 Jan 2026 01:14:21 +0000
> > bart <bc@freeuk.com> wrote:
> >
> >> On 07/01/2026 00:44, James Kuyper wrote:
> >>> On 2026-01-06 13:05, Michael S wrote:
> >>
> >>>> in case of using %u to print 'unsigned long' on target with
> >>>> 32-bit longs, or like using %llu to print 'unsigned long' on
> >>>> target with 64-bit longs, then beauty wins. Easily.
> >>>
> >>> You've got it backwards. "%u" is the correct specifier to use for
> >>> unsigned long on all platforms, whether unsigned long is 32, 36,
> >>> or even 48 bits.
> >>
> >> So not "%lu"?
> >>
> >>
> >
> > gcc and clang maintainers certainly think so.
> >
>
> They think it is correct or not correct? If I compile this:
>
> #include <stdio.h>
>
> int main() {
> unsigned long a=0;
> printf("%u", a);
> }
>
> then gcc complains (given suitable options):
>
> warning: format '%u' expects argument of type 'unsigned int', but
> argument 2 has type 'long unsigned int' [-Wformat=]
>
> The suggests it is not correct.
May be, I was not sufficiently clear, but my post was agreeing with
your point.
[toc] | [prev] | [next] | [standalone]
| From | "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-07 12:45 -0500 |
| Message-ID | <10jm63q$r1ko$1@dont-email.me> |
| In reply to | #396242 |
On 2026-01-06 20:14, bart wrote: > On 07/01/2026 00:44, James Kuyper wrote: >> On 2026-01-06 13:05, Michael S wrote: > >>> in case of using %u to print 'unsigned long' on target with 32-bit >>> longs, or like using %llu to print 'unsigned long' on target with >>> 64-bit longs, then beauty wins. Easily. >> >> You've got it backwards. "%u" is the correct specifier to use for >> unsigned long on all platforms, whether unsigned long is 32, 36, or even >> 48 bits. > > So not "%lu"? I was so wrapped up in making my point about the differences between standard named types and the <stdint.h> typedefs that I failed to notice he was using the wrong specifier for unsigned long. You're right, it should be "%lu". On a different point, I used time_t as an example. It would have been better to use ptrdiff_t instead, since <inttypes.h> has a macro for that type, and doesn't have one for time_t.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-07 20:31 +0000 |
| Message-ID | <10jmfr9$v99t$5@dont-email.me> |
| In reply to | #396276 |
On Wed, 7 Jan 2026 12:45:30 -0500, James Russell Kuyper Jr. wrote: > On a different point, I used time_t as an example. It would have > been better to use ptrdiff_t instead, since <inttypes.h> has a macro > for that type, and doesn't have one for time_t. This is why you have configure scripts, so they can figure out the right types to use for building on your platform.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-07 13:32 -0800 |
| Message-ID | <87ms2pglck.fsf@example.invalid> |
| In reply to | #396279 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Wed, 7 Jan 2026 12:45:30 -0500, James Russell Kuyper Jr. wrote:
>> On a different point, I used time_t as an example. It would have
>> been better to use ptrdiff_t instead, since <inttypes.h> has a macro
>> for that type, and doesn't have one for time_t.
>
> This is why you have configure scripts, so they can figure out the
> right types to use for building on your platform.
I don't follow. ptrdiff_t is defined in <stddef.h>, and is the correct
type for the result of subtracting two pointers. What relevant
information would a configure script give you?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-08 01:29 +0200 |
| Message-ID | <20260108012907.00007268@yahoo.com> |
| In reply to | #396282 |
On Wed, 07 Jan 2026 13:32:27 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: > > On Wed, 7 Jan 2026 12:45:30 -0500, James Russell Kuyper Jr. wrote: > >> On a different point, I used time_t as an example. It would have > >> been better to use ptrdiff_t instead, since <inttypes.h> has a > >> macro for that type, and doesn't have one for time_t. > > > > This is why you have configure scripts, so they can figure out the > > right types to use for building on your platform. > > I don't follow. ptrdiff_t is defined in <stddef.h>, and is the > correct type for the result of subtracting two pointers. What > relevant information would a configure script give you? > configure scripts are a cornerstone of software development religion for quite a few people. I hate them (scripts, not people) with passion.
[toc] | [prev] | [next] | [standalone]
| From | "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-08 19:16 -0500 |
| Message-ID | <10jphcj$15aeb$1@dont-email.me> |
| In reply to | #396282 |
On 2026-01-07 16:32, Keith Thompson wrote: > Lawrence D’Oliveiro <ldo@nz.invalid> writes: >> On Wed, 7 Jan 2026 12:45:30 -0500, James Russell Kuyper Jr. wrote: >>> On a different point, I used time_t as an example. It would have >>> been better to use ptrdiff_t instead, since <inttypes.h> has a macro >>> for that type, and doesn't have one for time_t. >> >> This is why you have configure scripts, so they can figure out the >> right types to use for building on your platform. > > I don't follow. ptrdiff_t is defined in <stddef.h>, and is the correct > type for the result of subtracting two pointers. What relevant > information would a configure script give you? I suspect he's referring to time_t, not ptrdiff_t. I mentioned the absence of a macro #defined in <inttypes.h> as a reason why I should not have used time_t as an example.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-08 17:13 +0100 |
| Message-ID | <10jol31$1jqi7$1@dont-email.me> |
| In reply to | #396242 |
On 07/01/2026 02:14, bart wrote: > On 07/01/2026 00:44, James Kuyper wrote: >> On 2026-01-06 13:05, Michael S wrote: > >>> in case of using %u to print 'unsigned long' on target with 32-bit >>> longs, or like using %llu to print 'unsigned long' on target with >>> 64-bit longs, then beauty wins. Easily. >> >> You've got it backwards. "%u" is the correct specifier to use for >> unsigned long on all platforms, whether unsigned long is 32, 36, or even >> 48 bits. > > So not "%lu"? > > "%lu" is, as you point out, the correct specifier for "unsigned long". James made a mistake here - it's unusual for him, but we are all fallible. That is why it is a good idea to enable whatever static warnings you can get from a compiler, as long as they don't conflict with your particular coding style. And that is why it is madness for Michael to disable something as useful as printf format checking just because he thinks "%lu" is "ugly".
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-01-05 16:23 +0000 |
| Message-ID | <10jgohd$31ebg$1@nntp.eternal-september.org> |
| In reply to | #396161 |
On Mon, 05 Jan 2026 10:51:38 +0200, Michael S wrote: > On Mon, 5 Jan 2026 00:17:07 -0800 > Andrey Tarasevich <noone@noone.net> wrote: > >> On Sun 1/4/2026 11:19 PM, Kenny McCormack wrote: >> > The question is: How can you reliably printf() a time_t value? >> > What conversion spec should you use? >> >> You can't. As far as the language is concerned, `time_t` is intended >> to be an opaque type. It has to be a real type, so it is either an >> integer of a plain floating-point type. But other than that nothing >> is known about it. There's really no point in printing it. >> >> If you still want to, you can do it in some implementation-specific >> way. Which still immediately means that you can't do it "reliably", >> if I understand what you mean correctly. >> > > I can't think about situation in which casting time_t value to 'long > long' can go wrong. As Andrey pointed out, time_t can resolve to a floatingpoint type, so, "long long" would go wrong if the implementation typedefs it to float, or double, or long double. -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-01-05 16:34 +0000 |
| Message-ID | <10jgp61$304fj$1@news.xmission.com> |
| In reply to | #396180 |
In article <10jgohd$31ebg$1@nntp.eternal-september.org>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
...
>As Andrey pointed out, time_t can resolve to a floatingpoint type,
>so, "long long" would go wrong if the implementation typedefs it to
> float, or
> double, or
> long double.
That really doesn't matter. We're talking about POSIX here.
Yes, I neglected to mention that in the OP (I had intended to, but it
slipped my mind when I hit "send"), but I added it in in a subsequent
post. So, the qualifier is there.
--
"We are in the beginning of a mass extinction, and all you can talk
about is money and fairy tales of eternal economic growth."
- Greta Thunberg -
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-05 17:34 +0100 |
| Message-ID | <10jgp66$31gp5$1@nntp.eternal-september.org> |
| In reply to | #396180 |
On 05/01/2026 17:23, Lew Pitcher wrote: > On Mon, 05 Jan 2026 10:51:38 +0200, Michael S wrote: > >> On Mon, 5 Jan 2026 00:17:07 -0800 >> Andrey Tarasevich <noone@noone.net> wrote: >> >>> On Sun 1/4/2026 11:19 PM, Kenny McCormack wrote: >>>> The question is: How can you reliably printf() a time_t value? >>>> What conversion spec should you use? >>> >>> You can't. As far as the language is concerned, `time_t` is intended >>> to be an opaque type. It has to be a real type, so it is either an >>> integer of a plain floating-point type. But other than that nothing >>> is known about it. There's really no point in printing it. >>> >>> If you still want to, you can do it in some implementation-specific >>> way. Which still immediately means that you can't do it "reliably", >>> if I understand what you mean correctly. >>> >> >> I can't think about situation in which casting time_t value to 'long >> long' can go wrong. > > As Andrey pointed out, time_t can resolve to a floatingpoint type, > so, "long long" would go wrong if the implementation typedefs it to > float, or > double, or > long double. > As I understand it, time_t is intended to be suitable for holding a number of seconds (it is used for that purpose in struct timespec). So while it might be a floating point type, it is unlikely to be holding a value greater than 2 ** 63 (21 times the age of the universe in seconds). But I think there is still a hypothetical possibility that the time_t value returned by, say, the "time" function, could have a different scaling. If that were scaled in nanoseconds, you could overflow long long after only about 292 years. Perhaps you are safer converting to _BitInt(128) :-)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-05 13:11 -0500 |
| Message-ID | <10jgusa$2rp4s$3@nntp.eternal-september.org> |
| In reply to | #396182 |
On 2026-01-05 11:34, David Brown wrote: ... > As I understand it, time_t is intended to be suitable for holding a > number of seconds ... The standard says nothing about that. > ... (it is used for that purpose in struct timespec). ... The standard says nothing to connect time_t to struct timespec.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-05 19:28 +0100 |
| Message-ID | <10jgvtb$34hmn$1@nntp.eternal-september.org> |
| In reply to | #396184 |
On 05/01/2026 19:11, James Kuyper wrote: > On 2026-01-05 11:34, David Brown wrote: > ... >> As I understand it, time_t is intended to be suitable for holding a >> number of seconds ... > > The standard says nothing about that. > >> ... (it is used for that purpose in struct timespec). ... > > The standard says nothing to connect time_t to struct timespec. 7.27.1p4: The range and precision of times representable in clock_t and time_t are implementation-defined. The timespec structure shall contain at least the following members, in any order. The semantics of the members and their normal ranges are expressed in the comments. time_t tv_sec; // whole seconds -- >= 0 long tv_nsec; // nanoseconds -- [0, 999999999]
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-05 14:00 -0500 |
| Message-ID | <10jh1nn$2rp4s$5@nntp.eternal-september.org> |
| In reply to | #396186 |
On 2026-01-05 13:28, David Brown wrote: > On 05/01/2026 19:11, James Kuyper wrote: >> On 2026-01-05 11:34, David Brown wrote: >> ... >>> As I understand it, time_t is intended to be suitable for holding a >>> number of seconds ... >> >> The standard says nothing about that. >> >>> ... (it is used for that purpose in struct timespec). ... >> >> The standard says nothing to connect time_t to struct timespec. > > 7.27.1p4: > > The range and precision of times representable in clock_t and time_t are > implementation-defined. The timespec structure shall contain at least > the following members, in any order. The semantics of the members and > their normal ranges are expressed in the comments. > > time_t tv_sec; // whole seconds -- >= 0 > long tv_nsec; // nanoseconds -- [0, 999999999] I'm not sure how I missed that in my search. In the latest draft of the standard I could find, n3685.pdf, that's in 7.21.1p6. I found struct timespec mentioned in 7.21.1p5 with no detailed specification, and didn't bother reading the next paragraph, which provides that specification. If I had thought about it, I would have realized that the same was true of struct tm, which I know from long experience has a detailed specification.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-05 20:38 +0100 |
| Message-ID | <10jh3v6$36d3s$1@nntp.eternal-september.org> |
| In reply to | #396187 |
On 05/01/2026 20:00, James Kuyper wrote: > On 2026-01-05 13:28, David Brown wrote: >> On 05/01/2026 19:11, James Kuyper wrote: >>> On 2026-01-05 11:34, David Brown wrote: >>> ... >>>> As I understand it, time_t is intended to be suitable for holding a >>>> number of seconds ... >>> >>> The standard says nothing about that. >>> >>>> ... (it is used for that purpose in struct timespec). ... >>> >>> The standard says nothing to connect time_t to struct timespec. >> >> 7.27.1p4: >> >> The range and precision of times representable in clock_t and time_t are >> implementation-defined. The timespec structure shall contain at least >> the following members, in any order. The semantics of the members and >> their normal ranges are expressed in the comments. >> >> time_t tv_sec; // whole seconds -- >= 0 >> long tv_nsec; // nanoseconds -- [0, 999999999] > > I'm not sure how I missed that in my search. Probably in the same way I regularly miss details... > In the latest draft of the > standard I could find, n3685.pdf, that's in 7.21.1p6. I found struct > timespec mentioned in 7.21.1p5 with no detailed specification, and > didn't bother reading the next paragraph, which provides that > specification. If I had thought about it, I would have realized that the > same was true of struct tm, which I know from long experience has a > detailed specification. There is still nothing, as far as I can see, that guarantees other functions returning time_t work in seconds.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-05 14:41 -0800 |
| Message-ID | <87tswz3co9.fsf@example.invalid> |
| In reply to | #396184 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2026-01-05 11:34, David Brown wrote:
> ...
>> As I understand it, time_t is intended to be suitable for holding a
>> number of seconds ...
>
> The standard says nothing about that.
>
>> ... (it is used for that purpose in struct timespec). ...
>
> The standard says nothing to connect time_t to struct timespec.
Yes, but also no.
struct timespec contains at least the following members, in any order:
time_t tv_sec; // whole seconds — ≥ 0
long tv_nsec; // nanoseconds — [0, 999999999]
But a footnote says:
The tv_sec member is a linear count of seconds and may not have
the normal semantics of a time_t.
This makes for a simpler implementation *if* the time_t value
returned by time(), and operated on by difftime(), mktime(), ctime(),
gmtime(), and localtime(), happens to hold a linear count of seconds
(as it does on most systems).
It's odd that time_t is used for two potentially very different
purposes, one as a member of struct timespec and another as used
in all other contexts. And I would guess that a lot of code that
uses struct timespec *assumes* that its time_t member has the same
semantics value returned by time(NULL).
For example, as I write this the time is 2026-01-05 22:32:57.881 UTC.
The corresponding value returned by time() is 1767652377 (seconds
since the 1970 epoch, no milliseconds). An implementation could
represent the current time (the value returned by time(NULL) as a
64-bit integer with the value 20260105223257881. But timespec_get()
would still have to set the tv_sec member to 1767652377.
It might have been cleaner either to require that time_t represents a
count of seconds, or to use a type other than time_t for the tv_sec
member of struct timespec.
I know there are systems that use something other than seconds
since 1970 in the underlying time representation, but are there any
C implementations that don't use seconds since 1970? (POSIX and
Windows both specify 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]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web