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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-02-09 01:27 +0000 |
| Message-ID | <10mbd6d$37sq7$1@paganini.bofh.team> |
| In reply to | #396654 |
Bart <bc@freeuk.com> wrote:
> On 08/02/2026 19:21, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>> On 07/02/2026 22:48, Waldek Hebisch wrote:
>
>>>> In SYS V convention argument is passed in exactly one place. It may
>>>> be GPR, may be XMM register, may be on the stack. If you put right
>>>> thing in RAX, then your arguments are valid regardless if the function
>>>> is a vararg function or not.
>>>
>>> I had to go and check this, and you're right. SYS V does nothing special
>>> when calling variadic functions.
>>
>> Well, there is special thing: RAX should contain number of SSE
>> registers used for passing parameters. You do not need to set
>> RAX for normal calls (at least on Linux, some other systems
>> require it for all calls).
>
> I looked out for that but don't remember seeing in on godbolt.org, and I
> think it was for SYS V.
>
> But I tried it again, and AL is being set to some count, which appears
> to be the total number of float arguments (and rereading your comment,
> you say the same thing).
>
>>
>>> I guess that makes implementing the body of variadic functions harder,
>>> since it doesn't know where to look for the n'th variadic argument
>>> unless it knows the type.
>>
>> Well, if a function wants to do actual computation with an argument
>> it should better know its type.
>
> On Windows, it will know the location of the next vararg and can access
> its value before it knows the type. The user-provided type (eg.
> 'var_arg(p, int)') can simple do a type-punning cast on the value.
>
> All args: fixed, variadic-reg, variadic-pushed, will also all be in
> consecutive stack slots, regardless of type (This is the real reason why
> floats should be loaded to GPRs for variadics: entry code just needs to
> spill those 4 GPRs, it anyway won't know the mix of types.)
>
>>> I started generating code for ARM64, but gave up because it was too hard
>>> and not fun (the RISC processor turned out to be a LOT more complex than
>>> the CISC x64!).
>>
>> Well, RISC processor means that compiler have to do work which is
>> frequently done by hardware on a CISC. Concerning arm32, most
>> annoying for me was limited range of constants, especially limit
>> on offsets that can be part of an instruction. With my current
>> implementation that puts something like 2kB limit on size of local
>> variables. And my generator mixes instructions and constant data
>> (otherwise it could not access constant data using limited available
>> offsets), which works but compilcates code generator and probably
>> gives suboptimal performance.
>
> There are a dozen annoying things like this on arm64. Even when you give
> up and decide to load 64-bit constants from a memory pool, you find you
> can't even directly access that pool as it has an absolute address. That
> can involve first loading the page address (ie. minus lower 12 bits) to
> R, then you have to use an address mode involving R and the lower 12
> bits as an offset.
As I wrote I generate constant pool as part of instruction stream.
I use PC-relative adressing so as long as constant is close
enough to instruction using it I can use short offsets.
There is some extra effort, normally I am trying to put constants
after unconditional jump and before next label, but I may need
extra jump to "jump around" constants.
>>> The last straw was precisely to do with the SYS V call-conventions, and
>>> I hadn't even gotten to variadic arguments yet, nor to structs passed
>>> by-value, where the rules are labyrinthine.
>>
>> My low-level code only handles scalar arguments. That includes pointer
>> to structures, but not structures passed by value. Structures passed by
>> value could be handled by higher-level code, but up to now there was
>> no need to do this.
>>
>> BTW, my amd64 code is assembler, so off-topic here, but arm32 code
>> is mostly C. I use two helper structures:
>>
>> struct registers_buffer {
>> int i_reg[4];
>> union {double d; struct {float sl; float sh;} sf2;} f_reg[8];
>> };
>>
>> typedef struct registers_buffer reg_buff;
>>
>> typedef struct arg_state { int ni; int sfi; int dfi; int si;} arg_state;
>>
>> C code fills 'reg_buff' with values and later low-level assembly
>> copies values from the buffer to registers. I allocate enough space on
>> the stack so that C code can write to the stack without risk of
>> stack overflow.
>>
>> There are 3 helper routines:
>
>
> This looks pretty complicated, but what is it for: is it still to do
> with variadic functions, or is to with the LIBFFI problem?
This is to handle a call, it does not matter variadic or not.
The call is from dynamically typed language and argument types are
known only at runtime (actually, argument types _may_ be statically
known at higher level, but for simplicity "all" (see below) calls go
trough a single low-level routine that handles general dynamic case.
Dispatcher routine (which I did not show) loops over arguments,
decodes their types and converts them to C representation. Then
it calls one of the 3 helper routines to place each argument in the buffer
or on the stack.
There is simpler integer only code which is mainly used to perform
low level system calls. This iterface do not convert arguments
(the assumption is that caller passes C-compatible representation)
and logic is simpler as it just puts what fits in registers and
the rest on the stack.
Both interfaces spill all registers used by calling language to
the stack before actual processing of the call. This is because
C code may perform a callback and callback may trigger garbage
collection and garbage collector needs to see all registers that
may point to language data. There are global variables which
tell garbage collector which parts of the stack are managed by
the language (and need to be scanned) and which belong to C or
FFI machinery (garbage collector ignores this part).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-10 00:14 +0000 |
| Message-ID | <10mdt8a$37i23$1@dont-email.me> |
| In reply to | #396655 |
On 09/02/2026 01:27, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>> On 08/02/2026 19:21, Waldek Hebisch wrote:
>>> Bart <bc@freeuk.com> wrote:
>>>> On 07/02/2026 22:48, Waldek Hebisch wrote:
>>
>>>>> In SYS V convention argument is passed in exactly one place. It may
>>>>> be GPR, may be XMM register, may be on the stack. If you put right
>>>>> thing in RAX, then your arguments are valid regardless if the function
>>>>> is a vararg function or not.
>>>>
>>>> I had to go and check this, and you're right. SYS V does nothing special
>>>> when calling variadic functions.
>>>
>>> Well, there is special thing: RAX should contain number of SSE
>>> registers used for passing parameters. You do not need to set
>>> RAX for normal calls (at least on Linux, some other systems
>>> require it for all calls).
>>
>> I looked out for that but don't remember seeing in on godbolt.org, and I
>> think it was for SYS V.
>>
>> But I tried it again, and AL is being set to some count, which appears
>> to be the total number of float arguments (and rereading your comment,
>> you say the same thing).
>>
>>>
>>>> I guess that makes implementing the body of variadic functions harder,
>>>> since it doesn't know where to look for the n'th variadic argument
>>>> unless it knows the type.
>>>
>>> Well, if a function wants to do actual computation with an argument
>>> it should better know its type.
>>
>> On Windows, it will know the location of the next vararg and can access
>> its value before it knows the type. The user-provided type (eg.
>> 'var_arg(p, int)') can simple do a type-punning cast on the value.
>>
>> All args: fixed, variadic-reg, variadic-pushed, will also all be in
>> consecutive stack slots, regardless of type (This is the real reason why
>> floats should be loaded to GPRs for variadics: entry code just needs to
>> spill those 4 GPRs, it anyway won't know the mix of types.)
>>
>>>> I started generating code for ARM64, but gave up because it was too hard
>>>> and not fun (the RISC processor turned out to be a LOT more complex than
>>>> the CISC x64!).
>>>
>>> Well, RISC processor means that compiler have to do work which is
>>> frequently done by hardware on a CISC. Concerning arm32, most
>>> annoying for me was limited range of constants, especially limit
>>> on offsets that can be part of an instruction. With my current
>>> implementation that puts something like 2kB limit on size of local
>>> variables. And my generator mixes instructions and constant data
>>> (otherwise it could not access constant data using limited available
>>> offsets), which works but compilcates code generator and probably
>>> gives suboptimal performance.
>>
>> There are a dozen annoying things like this on arm64. Even when you give
>> up and decide to load 64-bit constants from a memory pool, you find you
>> can't even directly access that pool as it has an absolute address. That
>> can involve first loading the page address (ie. minus lower 12 bits) to
>> R, then you have to use an address mode involving R and the lower 12
>> bits as an offset.
>
> As I wrote I generate constant pool as part of instruction stream.
> I use PC-relative adressing so as long as constant is close
> enough to instruction using it I can use short offsets.
> There is some extra effort, normally I am trying to put constants
> after unconditional jump and before next label, but I may need
> extra jump to "jump around" constants.
>
>>>> The last straw was precisely to do with the SYS V call-conventions, and
>>>> I hadn't even gotten to variadic arguments yet, nor to structs passed
>>>> by-value, where the rules are labyrinthine.
>>>
>>> My low-level code only handles scalar arguments. That includes pointer
>>> to structures, but not structures passed by value. Structures passed by
>>> value could be handled by higher-level code, but up to now there was
>>> no need to do this.
>>>
>>> BTW, my amd64 code is assembler, so off-topic here, but arm32 code
>>> is mostly C. I use two helper structures:
>>>
>>> struct registers_buffer {
>>> int i_reg[4];
>>> union {double d; struct {float sl; float sh;} sf2;} f_reg[8];
>>> };
>>>
>>> typedef struct registers_buffer reg_buff;
>>>
>>> typedef struct arg_state { int ni; int sfi; int dfi; int si;} arg_state;
>>>
>>> C code fills 'reg_buff' with values and later low-level assembly
>>> copies values from the buffer to registers. I allocate enough space on
>>> the stack so that C code can write to the stack without risk of
>>> stack overflow.
>>>
>>> There are 3 helper routines:
>>
>>
>> This looks pretty complicated, but what is it for: is it still to do
>> with variadic functions, or is to with the LIBFFI problem?
>
> This is to handle a call, it does not matter variadic or not.
> The call is from dynamically typed language and argument types are
> known only at runtime
OK, so it is probably performing the LIBFFI thing, or rather what needs
to come before, which is to marshall the arguments into homogenous array
of values. The actual LIBFFI task needs some ASM support as you say.
In that case, my own code to do the same (not in C) is probably more fiddly:
https://github.com/sal55/langs/blob/master/calldll.m
The interpreter calls 'calldll()'. 'vartopacked()' does the translation
from tagged dynamic values to suitable FFI types. Here the args are
assembled into an i64 array.
The actual call is done with 'os_calldllfunction' which uses inline
assembly; that has been appended.
I also have a version of that in pure HLL code, but it only handles the
most common combinations. (I used that if transpiling to C.)
> (actually, argument types _may_ be statically
> known at higher level, but for simplicity "all" (see below) calls go
> trough a single low-level routine that handles general dynamic case.
> Dispatcher routine (which I did not show) loops over arguments,
> decodes their types and converts them to C representation. Then
> it calls one of the 3 helper routines to place each argument in the buffer
> or on the stack.
>
> There is simpler integer only code which is mainly used to perform
> low level system calls. This iterface do not convert arguments
> (the assumption is that caller passes C-compatible representation)
> and logic is simpler as it just puts what fits in registers and
> the rest on the stack.
>
> Both interfaces spill all registers used by calling language to
> the stack before actual processing of the call. This is because
> C code may perform a callback and callback may trigger garbage
So here the dynamic code is not interpreted?
That's a problem for me: I can't pass a the address of a callback
function which only exists as bytecode!
(For the purpose of running WinAPI GUI programs, I set up a special
callback function within the compiler, and that then has to start a new
interpreter instance briefly.)
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-02-10 13:22 +0000 |
| Message-ID | <10mfbdp$3lj5g$1@paganini.bofh.team> |
| In reply to | #396657 |
Bart <bc@freeuk.com> wrote:
> On 09/02/2026 01:27, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>> On 08/02/2026 19:21, Waldek Hebisch wrote:
>>>> Bart <bc@freeuk.com> wrote:
>>>>> On 07/02/2026 22:48, Waldek Hebisch wrote:
>>>
>>>>> The last straw was precisely to do with the SYS V call-conventions, and
>>>>> I hadn't even gotten to variadic arguments yet, nor to structs passed
>>>>> by-value, where the rules are labyrinthine.
>>>>
>>>> My low-level code only handles scalar arguments. That includes pointer
>>>> to structures, but not structures passed by value. Structures passed by
>>>> value could be handled by higher-level code, but up to now there was
>>>> no need to do this.
>>>>
>>>> BTW, my amd64 code is assembler, so off-topic here, but arm32 code
>>>> is mostly C. I use two helper structures:
>>>>
>>>> struct registers_buffer {
>>>> int i_reg[4];
>>>> union {double d; struct {float sl; float sh;} sf2;} f_reg[8];
>>>> };
>>>>
>>>> typedef struct registers_buffer reg_buff;
>>>>
>>>> typedef struct arg_state { int ni; int sfi; int dfi; int si;} arg_state;
>>>>
>>>> C code fills 'reg_buff' with values and later low-level assembly
>>>> copies values from the buffer to registers. I allocate enough space on
>>>> the stack so that C code can write to the stack without risk of
>>>> stack overflow.
>>>>
>>>> There are 3 helper routines:
>>>
>>>
>>> This looks pretty complicated, but what is it for: is it still to do
>>> with variadic functions, or is to with the LIBFFI problem?
>>
>> This is to handle a call, it does not matter variadic or not.
>> The call is from dynamically typed language and argument types are
>> known only at runtime
>
> OK, so it is probably performing the LIBFFI thing, or rather what needs
> to come before, which is to marshall the arguments into homogenous array
> of values. The actual LIBFFI task needs some ASM support as you say.
As you can see from declaration of 'struct registers_buffer' values
are no homogeneous: there is separate part for integer registers
and separate part for floating point ones. In arm32 pair of
single float registers overlaps with double float register,
that is why for floating point I use a union.
The C code is called from assembly code. C code stores stack
arguments directly to the stack (before calling C code assembler
ensures that there is enough space on the stack for all arguments).
Since C code could use registers for its own purpose register
arguments are stored in a buffer and loaded after argument loop
is done.
> In that case, my own code to do the same (not in C) is probably more fiddly:
>
> https://github.com/sal55/langs/blob/master/calldll.m
>
> The interpreter calls 'calldll()'. 'vartopacked()' does the translation
> from tagged dynamic values to suitable FFI types. Here the args are
> assembled into an i64 array.
It looks a bit simpler: AFAICS your code does not spread arguments
between various destinations (various kinds of registers and the stack).
> The actual call is done with 'os_calldllfunction' which uses inline
> assembly; that has been appended.
>
> I also have a version of that in pure HLL code, but it only handles the
> most common combinations. (I used that if transpiling to C.)
>
>
>> (actually, argument types _may_ be statically
>> known at higher level, but for simplicity "all" (see below) calls go
>> trough a single low-level routine that handles general dynamic case.
>> Dispatcher routine (which I did not show) loops over arguments,
>> decodes their types and converts them to C representation. Then
>> it calls one of the 3 helper routines to place each argument in the buffer
>> or on the stack.
>>
>> There is simpler integer only code which is mainly used to perform
>> low level system calls. This iterface do not convert arguments
>> (the assumption is that caller passes C-compatible representation)
>> and logic is simpler as it just puts what fits in registers and
>> the rest on the stack.
>>
>> Both interfaces spill all registers used by calling language to
>> the stack before actual processing of the call. This is because
>> C code may perform a callback and callback may trigger garbage
>
> So here the dynamic code is not interpreted?
There are no interpreter: all code is compiled to machine code. That
include user "command line".
But in principle adding a bytecode intepreter is not hard. All
functions would need a small machine code stub to start interpreter.
There would be efficiency hit for calls to interpreted functions,
but probably not too bad (interpreted code is slow anyway).
ATM it is not clear to me if advantages (mainly smaller code)
justify needed effort.
> That's a problem for me: I can't pass a the address of a callback
> function which only exists as bytecode!
>
> (For the purpose of running WinAPI GUI programs, I set up a special
> callback function within the compiler, and that then has to start a new
> interpreter instance briefly.)
Yes, with simple enough interpreter one can start separate interpreter
"instance" for each call.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-02-09 01:40 +0000 |
| Message-ID | <10mbdtg$37sq7$2@paganini.bofh.team> |
| In reply to | #396654 |
Bart <bc@freeuk.com> wrote:
>>> On 07/02/2026 22:48, Waldek Hebisch wrote:
>
>> BTW, my amd64 code is assembler, so off-topic here, but arm32 code
>> is mostly C. I use two helper structures:
>>
>> struct registers_buffer {
>> int i_reg[4];
>> union {double d; struct {float sl; float sh;} sf2;} f_reg[8];
>> };
>>
>> typedef struct registers_buffer reg_buff;
>>
>> typedef struct arg_state { int ni; int sfi; int dfi; int si;} arg_state;
>>
>> C code fills 'reg_buff' with values and later low-level assembly
>> copies values from the buffer to registers. I allocate enough space on
>> the stack so that C code can write to the stack without risk of
>> stack overflow.
>>
>> There are 3 helper routines:
>
>
> This looks pretty complicated, but what is it for: is it still to do
> with variadic functions, or is to with the LIBFFI problem?
Just little extra thing: the code I posted just copies arguments, but
the same logic can be used at compile time to generate parameter
passing code.
Concerning "pretty complicated", it is doing what specification says
it should do, it is shorter than the specification and IMO it is
at least as readible as the specification (OK, for people that do not
know the specification bunch of comments would be useful). Since
it is C a few things that are not entirely clear in the specification
are precisly specified.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-06 05:08 -0800 |
| Message-ID | <875x8a81f0.fsf@example.invalid> |
| In reply to | #396622 |
Bart <bc@freeuk.com> writes:
[...]
> I guess you've never used printf-family functions via the FFI of
> another language!
As it happens, I haven't.
I presume if there were a point, you would have made it by now.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-06 14:28 +0000 |
| Message-ID | <10m4tqt$7om1$1@dont-email.me> |
| In reply to | #396629 |
On 06/02/2026 13:08, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> I guess you've never used printf-family functions via the FFI of >> another language! > > As it happens, I haven't. > > I presume if there were a point, you would have made it by now. > I thought you might have infered it. All shortcomings of C can apparently be fixed by employing a selection of it gcc's 200+ options. So no point in making the language better instead. But that doesn't work when some bits of raw C need to be used from another language. For example, library headers containing a C API, which some languages may use as the basis for their own bindings.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-06 14:29 +0000 |
| Message-ID | <10m4tss$7om1$2@dont-email.me> |
| In reply to | #396630 |
On 06/02/2026 14:28, Bart wrote: > On 06/02/2026 13:08, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >> [...] >>> I guess you've never used printf-family functions via the FFI of >>> another language! >> >> As it happens, I haven't. >> >> I presume if there were a point, you would have made it by now. >> > > > I thought you might have infered it. > > All shortcomings of C can apparently be fixed by employing a selection > of it gcc's 200+ options. I missed out at least one zero!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-06 11:21 -0800 |
| Message-ID | <87y0l57k53.fsf@example.invalid> |
| In reply to | #396630 |
Bart <bc@freeuk.com> writes:
> On 06/02/2026 13:08, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> I guess you've never used printf-family functions via the FFI of
>>> another language!
>> As it happens, I haven't.
>> I presume if there were a point, you would have made it by now.
>
> I thought you might have infered it.
>
> All shortcomings of C can apparently be fixed by employing a selection
> of it gcc's 200+ options. So no point in making the language better
> instead.
Nobody said any of that.
> But that doesn't work when some bits of raw C need to be used from
> another language. For example, library headers containing a C API,
> which some languages may use as the basis for their own bindings.
Sure, FFIs can be tricky.
You randomly introduced FFIs into a discussion of printf formats. What
irrelevant argument are you going to make next?
https://en.wikipedia.org/wiki/Gish_gallop
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-06 20:08 +0000 |
| Message-ID | <10m5hon$g2u6$1@dont-email.me> |
| In reply to | #396633 |
On 06/02/2026 19:21, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 06/02/2026 13:08, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>> [...] >>>> I guess you've never used printf-family functions via the FFI of >>>> another language! >>> As it happens, I haven't. >>> I presume if there were a point, you would have made it by now. >> >> I thought you might have infered it. >> >> All shortcomings of C can apparently be fixed by employing a selection >> of it gcc's 200+ options. So no point in making the language better >> instead. > > Nobody said any of that. > >> But that doesn't work when some bits of raw C need to be used from >> another language. For example, library headers containing a C API, >> which some languages may use as the basis for their own bindings. > > Sure, FFIs can be tricky. > > You randomly introduced FFIs into a discussion of printf formats. What > irrelevant argument are you going to make next? > > https://en.wikipedia.org/wiki/Gish_gallop You seem to have introduced some nonsense of your own. I'm simply saying that people discussing here C are often blind to its problems because they employ an advanced C compiler or other analytical tools to mitigate them. You can't do that if working with raw C like I do. I've been using C libraries via FFIs and C header files for about 30 years. And so, if you want to use *printf functions like that, then the fact that gcc can sometimes report on incorrect format codes is no help at all; I'm not using gcc, /or/ writing C! It doesn't help when I'm writing C either, as I either use lesser compilers, or use gcc without any fancy options. I believe a language should stand by itself and not rely on complex tooling to make it practical to use. Not even syntax highlighting should be necessary.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-06 12:56 -0800 |
| Message-ID | <87tsvt7fry.fsf@example.invalid> |
| In reply to | #396634 |
Bart <bc@freeuk.com> writes:
> On 06/02/2026 19:21, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 06/02/2026 13:08, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> I guess you've never used printf-family functions via the FFI of
>>>>> another language!
>>>>
>>>> As it happens, I haven't.
>>>>
>>>> I presume if there were a point, you would have made it by now.
>>>
>>> I thought you might have infered it.
>>>
>>> All shortcomings of C can apparently be fixed by employing a selection
>>> of it gcc's 200+ options. So no point in making the language better
>>> instead.
>>>
>> Nobody said any of that.
>>
>>> But that doesn't work when some bits of raw C need to be used from
>>> another language. For example, library headers containing a C API,
>>> which some languages may use as the basis for their own bindings.
>>
>> Sure, FFIs can be tricky.
>>
>> You randomly introduced FFIs into a discussion of printf formats. What
>> irrelevant argument are you going to make next?
>> https://en.wikipedia.org/wiki/Gish_gallop
>
> You seem to have introduced some nonsense of your own.
What nonsense have I introduced? please be specific.
> I'm simply saying that people discussing here C are often blind to its
> problems because they employ an advanced C compiler or other
> analytical tools to mitigate them.
People discussing C here are typically very much aware of its problems.
Much of what we discuss is methods for using C correctly and, yes,
working around its problems.
> You can't do that if working with raw C like I do. I've been using C
> libraries via FFIs and C header files for about 30 years.
Good for you. Most of the rest of us don't use FFIs. But if you
want help using them, you could ask specific questions, and it's
likely that someone here would be willing and able to answer them.
> And so, if you want to use *printf functions like that, then the fact
> that gcc can sometimes report on incorrect format codes is no help at
> all; I'm not using gcc, /or/ writing C!
OK, so some warnings produced by gcc (and other compilers) that I find
useful are not useful to you.
So what? What do you expect anyone here to do about it?
You seem to be complaining that calling C's printf from another
language via an FFI is difficult. I can certainly believe that
it is. Do you actually need to do that? I have some thoughts
about alternative approaches, which I'll be glad to discuss --
if and only if you ask.
> It doesn't help when I'm writing C either, as I either use lesser
> compilers, or use gcc without any fancy options.
>
> I believe a language should stand by itself and not rely on complex
> tooling to make it practical to use. Not even syntax highlighting
> should be necessary.
News flash: Bart doesn't like C.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-02-06 14:35 +0000 |
| Message-ID | <6%mhR.294892$lag.235366@fx17.iad> |
| In reply to | #396614 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>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.
Agreed.
>
>> 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.
A warning could be even worse; it may not be unusual to
desire to print a signed integer as unsigned (or in hex) in
some applications.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-02-07 17:55 +0000 |
| Message-ID | <20260207093737.331@kylheku.com> |
| In reply to | #396613 |
On 2026-02-05, Bart <bc@freeuk.com> wrote:
> 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.
That's an excellent reason to keep the bulk of your code portable, and
offer it to multiple compilers.
I think the only way you are going to run into a crappy compiler in a
real job situation in 2026 is if you're an embedded developer working
with some very proprietary processor for which the only compiler comes
from its vendor. Even so the bits of your code not specific to that
chip can be compiled with something else. Which you want to do not just
for diagnostics but to be able to run unit tests on that code on a
regular developer machine.
> 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.
For that you need this:
$ gcc -Wall -pedantic -W -Wformat -Wformat-signedness printf.c
printf.c: In function ‘main’:
printf.c:5:12: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘int’ [-Wformat=]
printf("%u", a);
~^
%u
There is probably a good reason for that; passing a signed argument
to an unsigned conversion specifier de facto works fine, and
some code relies on it; i.e. the 4294967295 is what the programmer
wanted.
You often see that with %x, which also takes unsigned int;
the programmer wants -16 to come out as "FFFFFFF0", and not -10.
Someone with code like that might want to catch other problems with
printf calls, and not be bothered with those.
> 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?
Both are undefined behavior. The latter is a documented extension
that works where it works, which is good.
Using %u with int /de facto/ works (and could also be a documented
extension).
/de facto/ is weaker than documented. But on the other hand, /de facto/
works in more places than %v.
If you hit a library that doesn't have %v, it doesn't work at all.
I've never seen int passed to %d or %x not work in the manner you
would expect if int and unsigned int arguments were passed in
exactly the same way and subject to a reinterpretation of the bits.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-07 20:51 +0000 |
| Message-ID | <10m88l8$1cvj8$2@dont-email.me> |
| In reply to | #396637 |
On 07/02/2026 17:55, Kaz Kylheku wrote:
> On 2026-02-05, Bart <bc@freeuk.com> wrote:
>> 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.
>
> That's an excellent reason to keep the bulk of your code portable, and
> offer it to multiple compilers.
>
> I think the only way you are going to run into a crappy compiler in a
> real job situation in 2026 is if you're an embedded developer working
> with some very proprietary processor for which the only compiler comes
> from its vendor. Even so the bits of your code not specific to that
> chip can be compiled with something else. Which you want to do not just
> for diagnostics but to be able to run unit tests on that code on a
> regular developer machine.
>
>> 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.
>
> For that you need this:
>
> $ gcc -Wall -pedantic -W -Wformat -Wformat-signedness printf.c
-Wformat-signedness, of course! Sorry I just don't believe in
micro-managing a compiler's job to that extent.
Here's my code: is it valid C or not? It's a yes or no answer.
If I wanted a more nuanced or a speculative opinion about my code, I'd
use a tool that wasn't called a compiler, and I would not use it for
every routine build.
> There is probably a good reason for that; passing a signed argument
> to an unsigned conversion specifier de facto works fine, and
> some code relies on it; i.e. the 4294967295 is what the programmer
> wanted.
Then they can add a cast.
>
> You often see that with %x, which also takes unsigned int;
> the programmer wants -16 to come out as "FFFFFFF0", and not -10.
That's whay you get with %x anyway; I've never seen it produce a
negative hex number.
(My systems language can produce negative hex results, unless told to
treat as unsigned. Example:
i64 a := -1
u64 b := -1
println a:"h" # -1
println a:"hu" # FFFFFFFFFFFFFFFF
println b:"h" # FFFFFFFFFFFFFFFF)
> Someone with code like that might want to catch other problems with
> printf calls, and not be bothered with those.
>
>> 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?
>
> Both are undefined behavior. The latter is a documented extension
> that works where it works, which is good.
>
> Using %u with int /de facto/ works (and could also be a documented
> extension).
>
> /de facto/ is weaker than documented. But on the other hand, /de facto/
> works in more places than %v.
>
> If you hit a library that doesn't have %v, it doesn't work at all.
The %v refered to one of my old implementations.
There was handled within the compiler, so worked with any library.
It was limited to format strings that are constants, but then so are
-Wformat-signedness etc.
> I've never seen int passed to %d or %x not work in the manner you
> would expect if int and unsigned int arguments were passed in
> exactly the same way and subject to a reinterpretation of the bits.
>
I've been in the situation where I was unsure if the result of an
expression was signed or unsigned. So if the top if is set, I want to
see if it was printed as a negative value (so signed), or as positive.
%u or %x won't help here. I head to resort to casting to float then
using %f.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-06 12:27 +0100 |
| Message-ID | <10m4j7p$3s2o$1@dont-email.me> |
| In reply to | #396608 |
On 05/02/2026 18:42, Bart wrote:
> 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? You know a lot about these types, and what they can be
used for. You know if they are suitable for printf'ing directly, or
not, and how to either convert them to a suitable type directly or to
extract information from them.
>
>> 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.
>
If only there were a convenient way to handle this... oh, wait, there
is. Do as any competent programmer does when they have a complex
expression - assign the result to a local variable (/you/ pick the
type), rather than having too much in one huge printf.
>>>
>>>>> 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.
Converting -1 to unsigned long gives you that result, yes.
Conversions do not absolve you from having to know what your code does,
and the obligation to write sensible code. The conversion here means
your code does not have C undefined behaviour - it means the compiler
and run-time will do what you asked it to do. It cannot stop you from
asking it to do something silly, or something you did not mean. Again,
you /know/ this - it is fundamental to /all/ programming. It is nothing
to do with C.
>
> 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-05 11:05 -0800 |
| Message-ID | <87wm0r80zj.fsf@example.invalid> |
| In reply to | #396605 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> 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.
I recently played around with an attempted framework using _Generic.
The goal was to be able to write something like
print(s(x), s(y), s(z));
where x, y, and z can be of more or less arbitrary types (integer,
floating-point char*). The problem I ran into was that only one of
the generic associations is evaluated (which one is determined at
compile time), but *all* of them have to be valid code. There's a
proposal to change this for C 202y.
I didn't spend a lot of time on it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-02-06 02:59 -0800 |
| Message-ID | <86wm0qgmtm.fsf@linuxsc.com> |
| In reply to | #396610 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>
>> 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.
>
> I recently played around with an attempted framework using _Generic.
> The goal was to be able to write something like
>
> print(s(x), s(y), s(z));
>
> where x, y, and z can be of more or less arbitrary types (integer,
> floating-point char*). The problem I ran into was that only one of
> the generic associations is evaluated (which one is determined at
> compile time), but *all* of them have to be valid code.
That is annoying but it shouldn't be too hard to work around
it. To verify that hypothesis I wrote this test case:
#include <stdio.h>
#include <time.h>
#include <stdint.h>
#include "h/show.h"
int
main(){
unsigned long long ull = -1;
signed long long sll = -1;
unsigned long ul = -1;
signed long sl = -1;
unsigned char uc = -1;
signed char sc = -1;
unsigned short us = -1;
signed short ss = -1;
unsigned int ui = -1;
signed int si = -1;
char c = 'q';
float f = 1.23;
double d = 3.14159265358979312;
double long ld = 6.28318530717958623;
_Bool yes = 1;
_Bool no = !yes;
clock_t runtime = clock();
time_t now = time(0);
off_t offset = 27;
uint16_t u16 = -1;
int16_t s16 = -1;
uint_least32_t uge32 = -1;
int_least32_t sge32 = -1;
uint_fast32_t uf32 = -1;
int_fast32_t sf32 = -1;
char * foo = "foo";
const char * bas = "bas";
show(
uc,sc,us,ss,ui,si,ul,sl,ull,sll,
c,f,d,ld,yes,no,u16,s16,uge32,sge32,
runtime,now,offset,uf32,sf32,
c * now / 1e8 * ld,
foo, bas
);
printf( "\n" );
return 0;
}
which compiles under C11 and (along with the show.h include file)
produces output:
uc = 255
sc = -1
us = 65535
ss = -1
ui = 4294967295
si = -1
ul = 18446744073709551615
sl = -1
ull = 18446744073709551615
sll = -1
c = 'q'
f = 1.230000
d = 3.141593
ld = 6.283185
yes = true
no = false
u16 = 65535
s16 = -1
uge32 = 4294967295
sge32 = -1
runtime = 365
now = 1770371790
offset = 27
uf32 = 18446744073709551615
sf32 = -1
c * now / 1e8 * ld = 12569.638642
foo = "foo"
bas = (const char *) "bas"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-06 04:49 -0800 |
| Message-ID | <87a4xm82a5.fsf@example.invalid> |
| In reply to | #396618 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> I recently played around with an attempted framework using _Generic.
>> The goal was to be able to write something like
>>
>> print(s(x), s(y), s(z));
>>
>> where x, y, and z can be of more or less arbitrary types (integer,
>> floating-point char*). The problem I ran into was that only one of
>> the generic associations is evaluated (which one is determined at
>> compile time), but *all* of them have to be valid code.
>
> That is annoying but it shouldn't be too hard to work around
> it. To verify that hypothesis I wrote this test case:
>
>
> #include <stdio.h>
> #include <time.h>
> #include <stdint.h>
>
> #include "h/show.h"
>
> int
> main(){
[30 lines deleted]
> show(
> uc,sc,us,ss,ui,si,ul,sl,ull,sll,
> c,f,d,ld,yes,no,u16,s16,uge32,sge32,
> runtime,now,offset,uf32,sf32,
> c * now / 1e8 * ld,
> foo, bas
> );
> printf( "\n" );
>
> return 0;
> }
>
> which compiles under C11 and (along with the show.h include file)
> produces output:
>
> uc = 255
> sc = -1
> us = 65535
[23 lines deleted]
> foo = "foo"
> bas = (const char *) "bas"
Were you planning to show us what show.h looks like?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-06 13:05 +0000 |
| Message-ID | <10m4ovb$591t$3@dont-email.me> |
| In reply to | #396625 |
On 06/02/2026 12:49, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
>>> I recently played around with an attempted framework using _Generic.
>>> The goal was to be able to write something like
>>>
>>> print(s(x), s(y), s(z));
>>>
>>> where x, y, and z can be of more or less arbitrary types (integer,
>>> floating-point char*). The problem I ran into was that only one of
>>> the generic associations is evaluated (which one is determined at
>>> compile time), but *all* of them have to be valid code.
>>
>> That is annoying but it shouldn't be too hard to work around
>> it. To verify that hypothesis I wrote this test case:
>>
>>
>> #include <stdio.h>
>> #include <time.h>
>> #include <stdint.h>
>>
>> #include "h/show.h"
>>
>> int
>> main(){
> [30 lines deleted]
>> show(
>> uc,sc,us,ss,ui,si,ul,sl,ull,sll,
>> c,f,d,ld,yes,no,u16,s16,uge32,sge32,
>> runtime,now,offset,uf32,sf32,
>> c * now / 1e8 * ld,
>> foo, bas
>> );
>> printf( "\n" );
>>
>> return 0;
>> }
>>
>> which compiles under C11 and (along with the show.h include file)
>> produces output:
>>
>> uc = 255
>> sc = -1
>> us = 65535
> [23 lines deleted]
>> foo = "foo"
>> bas = (const char *) "bas"
>
> Were you planning to show us what show.h looks like?
Of course not!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-02-17 23:11 -0800 |
| Message-ID | <86342yh6fr.fsf@linuxsc.com> |
| In reply to | #396625 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>>> I recently played around with an attempted framework using _Generic.
>>> The goal was to be able to write something like
>>>
>>> print(s(x), s(y), s(z));
>>>
>>> where x, y, and z can be of more or less arbitrary types (integer,
>>> floating-point char*). The problem I ran into was that only one of
>>> the generic associations is evaluated (which one is determined at
>>> compile time), but *all* of them have to be valid code.
>>
>> That is annoying but it shouldn't be too hard to work around
>> it. To verify that hypothesis I wrote this test case:
>>
>>
>> #include <stdio.h>
>> #include <time.h>
>> #include <stdint.h>
>>
>> #include "h/show.h"
>>
>> int
>> main(){
>
> [30 lines deleted]
>
>> show(
>> uc,sc,us,ss,ui,si,ul,sl,ull,sll,
>> c,f,d,ld,yes,no,u16,s16,uge32,sge32,
>> runtime,now,offset,uf32,sf32,
>> c * now / 1e8 * ld,
>> foo, bas
>> );
>> printf( "\n" );
>>
>> return 0;
>> }
>>
>> which compiles under C11 and (along with the show.h include file)
>> produces output:
>>
>> uc = 255
>> sc = -1
>> us = 65535
>
> [23 lines deleted]
>
>> foo = "foo"
>> bas = (const char *) "bas"
>
> Were you planning to show us what show.h looks like?
I posted what I thought showed the essential elements of what I
was trying to convey. I don't want to get dragged into a
discussion of irrelevant tangents.
What would be more interesting is if you would post some of your
efforts showing what sort of problems you ran into. What made
those happen? What are the contours of the problem you were
trying to solve? Were those contours too large, or might the
full problem be solvable using a modified approach? It would be
good to see a discussion of exactly what problems there were and
what sort of approaches might address them.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-06 12:42 +0100 |
| Message-ID | <10m4k34$3s2o$2@dont-email.me> |
| In reply to | #396610 |
On 05/02/2026 20:05, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> 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. > > I recently played around with an attempted framework using _Generic. > The goal was to be able to write something like > > print(s(x), s(y), s(z)); > > where x, y, and z can be of more or less arbitrary types (integer, > floating-point char*). The problem I ran into was that only one of > the generic associations is evaluated (which one is determined at > compile time), but *all* of them have to be valid code. There's a > proposal to change this for C 202y. > > I didn't spend a lot of time on it. > My experiments used a variadic macro so that : print(x, y, z); would be turned into something akin to : print_generic(x); print_generic(y); print_generic(z); The "print_generic" _Generic macro would then lead you to : print_charp(x); print_double(y); print_int(z); The difference is then that you get multiple individual print calls, rather than one single one. For some uses, that could be a problem - for other uses, it could be fine. (For my own needs, it's actually quite okay - often what I will do is have a fixed-size local variable buffer, built up a debug string in that, then pass the buffer on to a serial port output routine. The main "print" macro would have this extra code before and after the print_generic macro calls.) It would also be possible to do something with _Generic macros to turn the different items into strings. You could allocate the memory for the strings with VLAs (or alloca, if you want to allow that). I haven't tried that, but maybe it's something for a rainy day. The most annoying thing about it all, however, is that there is no way to extend a _Generic macro later. You have to put all the types you want in the one place.
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web