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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-06 12:39 +0000 |
| Message-ID | <10m4neq$591t$1@dont-email.me> |
| In reply to | #396614 |
On 06/02/2026 05:10, Keith Thompson wrote: > 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. I guess you've never used printf-family functions via the FFI of another language!
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-02-06 14:47 +0200 |
| Message-ID | <20260206144732.00002e5c@yahoo.com> |
| In reply to | #396622 |
On Fri, 6 Feb 2026 12:39:55 +0000 Bart <bc@freeuk.com> wrote: > On 06/02/2026 05:10, Keith Thompson wrote: > > 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. > > I guess you've never used printf-family functions via the FFI of > another language! > > Vararg via FFI? Is it really a good idea?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-06 13:04 +0000 |
| Message-ID | <10m4ot0$591t$2@dont-email.me> |
| In reply to | #396624 |
On 06/02/2026 12:47, Michael S wrote:
> On Fri, 6 Feb 2026 12:39:55 +0000
> Bart <bc@freeuk.com> wrote:
>
>> On 06/02/2026 05:10, Keith Thompson wrote:
>>> 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.
>>
>> I guess you've never used printf-family functions via the FFI of
>> another language!
>>
>>
>
> Vararg via FFI? Is it really a good idea?
>
It's covered by platform ABIs of both Windows and SYS V.
This is printf called from an interpreted language with dynamic typing:
a := 12345678987654321
b := pi
c := "A"*10
d := &a
printf("%lld %f %s %p\n", a, b, c, d)
Output is:
12345678987654321 3.141593 AAAAAAAAAA 00000000036A1D48
(Strings are converted to zero-terminated form for the FFI.)
If I try it like this however:
printf("%lld %f %s %p\n", d, c, b, a)
It will go wrong (crashing inside the C library). With the built-in
print feature, that doesn't happen:
println a, b, c, d
println d, c, b, a
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-02-08 10:52 +0200 |
| Message-ID | <20260208105246.000046a0@yahoo.com> |
| In reply to | #396626 |
On Fri, 6 Feb 2026 13:04:34 +0000
Bart <bc@freeuk.com> wrote:
> On 06/02/2026 12:47, Michael S wrote:
> > On Fri, 6 Feb 2026 12:39:55 +0000
> > Bart <bc@freeuk.com> wrote:
> >
> >> On 06/02/2026 05:10, Keith Thompson wrote:
> >>> 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.
> >>
> >> I guess you've never used printf-family functions via the FFI of
> >> another language!
> >>
> >>
> >
> > Vararg via FFI? Is it really a good idea?
> >
>
> It's covered by platform ABIs of both Windows and SYS V.
>
My question was not about technical possibility. I understand that with
enough of effort everything is possible.
I asked whether it is a good idea.
Is not it simpler for you and for your potential users to declare that
your language can not call external C functions with variable number of
arguments? To me it does not sound like this ability is either necessary
or very valuable.
Above I assume that we are talking about your scripting language.
W.r.t. your other language, I have no strong opinion. But my weak
opinion is that it also does not need it, possibly with exception for
ability to do few (very few, hopefully) historically idiotically
defined Unix system calls that can be handled individually as special
cases.
> This is printf called from an interpreted language with dynamic
> typing:
>
> a := 12345678987654321
> b := pi
> c := "A"*10
> d := &a
> printf("%lld %f %s %p\n", a, b, c, d)
>
> Output is:
>
> 12345678987654321 3.141593 AAAAAAAAAA 00000000036A1D48
>
> (Strings are converted to zero-terminated form for the FFI.)
>
> If I try it like this however:
>
> printf("%lld %f %s %p\n", d, c, b, a)
>
> It will go wrong (crashing inside the C library). With the built-in
> print feature, that doesn't happen:
>
> println a, b, c, d
> println d, c, b, a
>
>
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-02-08 12:18 +0100 |
| Message-ID | <10m9rds$1h1k5$1@dont-email.me> |
| In reply to | #396643 |
On 2026-02-08 09:52, Michael S wrote: > On Fri, 6 Feb 2026 13:04:34 +0000 > Bart <bc@freeuk.com> wrote: >> On 06/02/2026 12:47, Michael S wrote: >>> On Fri, 6 Feb 2026 12:39:55 +0000 >>> Bart <bc@freeuk.com> wrote: >>>> >>>> I guess you've never used printf-family functions via the FFI of >>>> another language! >>> >>> Vararg via FFI? Is it really a good idea? (This was exactly my thought.) (There's obviously a reason why languages that access "C" functions seem to avoid support for "varargs".) >> [...] > [...] > I asked whether it is a good idea. > Is not it simpler for you and for your potential users to declare that > your language can not call external C functions with variable number of > arguments? To me it does not sound like this ability is either necessary > or very valuable. C's "varargs" mechanism always appeared kludgy to me. Though I haven't followed "varargs" in "C" since K&R times, but I've a faint impression that something has been done and changed since back then. What was it, or is it still supported [only] in its original form? Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-02-08 04:03 -0800 |
| Message-ID | <87ikc75to4.fsf@example.invalid> |
| In reply to | #396644 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
> C's "varargs" mechanism always appeared kludgy to me. Though I
> haven't followed "varargs" in "C" since K&R times, but I've a
> faint impression that something has been done and changed since
> back then. What was it, or is it still supported [only] in its
> original form?
Pre-ANSI C had a <varargs.h> header, used to process arguments to
variadic functions like printf. C89 replaced it with <stdarg.h>,
which hasn't changed much since then. Consult any recent standard
draft for details. C23 removes the requirement for the last
non-variadic argument to be passed to the va_start macro, allowing
for functions with *only* variadic parameters.
--
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 | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-02-08 16:50 +0000 |
| Message-ID | <10maesc$30i1s$1@paganini.bofh.team> |
| In reply to | #396643 |
Michael S <already5chosen@yahoo.com> wrote:
> On Fri, 6 Feb 2026 13:04:34 +0000
> Bart <bc@freeuk.com> wrote:
>
>> On 06/02/2026 12:47, Michael S wrote:
>> > On Fri, 6 Feb 2026 12:39:55 +0000
>> > Bart <bc@freeuk.com> wrote:
>> >
>> >> On 06/02/2026 05:10, Keith Thompson wrote:
>> >>> 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.
>> >>
>> >> I guess you've never used printf-family functions via the FFI of
>> >> another language!
>> >>
>> >>
>> >
>> > Vararg via FFI? Is it really a good idea?
>> >
>>
>> It's covered by platform ABIs of both Windows and SYS V.
>>
>
> My question was not about technical possibility. I understand that with
> enough of effort everything is possible.
> I asked whether it is a good idea.
> Is not it simpler for you and for your potential users to declare that
> your language can not call external C functions with variable number of
> arguments? To me it does not sound like this ability is either necessary
> or very valuable.
>
> Above I assume that we are talking about your scripting language.
>
> W.r.t. your other language, I have no strong opinion. But my weak
> opinion is that it also does not need it, possibly with exception for
> ability to do few (very few, hopefully) historically idiotically
> defined Unix system calls that can be handled individually as special
> cases.
Well, some important interfaces depend on varargs functions. And
while you may handle such cases via user-written wrappers, it is
much nicer if FFI machinery handles varargs.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-08 18:55 +0100 |
| Message-ID | <10maimk$24mf9$1@dont-email.me> |
| In reply to | #396646 |
On 08/02/2026 17:50, Waldek Hebisch wrote: > Michael S <already5chosen@yahoo.com> wrote: >> On Fri, 6 Feb 2026 13:04:34 +0000 >> Bart <bc@freeuk.com> wrote: >> >>> On 06/02/2026 12:47, Michael S wrote: >>>> On Fri, 6 Feb 2026 12:39:55 +0000 >>>> Bart <bc@freeuk.com> wrote: >>>> >>>>> On 06/02/2026 05:10, Keith Thompson wrote: >>>>>> 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. >>>>> >>>>> I guess you've never used printf-family functions via the FFI of >>>>> another language! >>>>> >>>>> >>>> >>>> Vararg via FFI? Is it really a good idea? >>>> >>> >>> It's covered by platform ABIs of both Windows and SYS V. >>> >> >> My question was not about technical possibility. I understand that with >> enough of effort everything is possible. >> I asked whether it is a good idea. >> Is not it simpler for you and for your potential users to declare that >> your language can not call external C functions with variable number of >> arguments? To me it does not sound like this ability is either necessary >> or very valuable. >> >> Above I assume that we are talking about your scripting language. >> >> W.r.t. your other language, I have no strong opinion. But my weak >> opinion is that it also does not need it, possibly with exception for >> ability to do few (very few, hopefully) historically idiotically >> defined Unix system calls that can be handled individually as special >> cases. > > Well, some important interfaces depend on varargs functions. And > while you may handle such cases via user-written wrappers, it is > much nicer if FFI machinery handles varargs. > There are only a few standard C functions that are variadic, but they are quite important ones (with the *printf family at the top). But there is little doubt that C's handling of variadic functions is very unsafe, and implementations are often challenging (the SysV ABI for x86-64 is awkward and complex for variadic functions - the Win64 ABI is easier for variadics at the expense of making many other function calls less efficient). It is a weak point in the design of C. And for other languages trying to access C code via a FFI, variadic functions are going to be inefficient, complicated, and unsafe (unless you are /very/ sure of the calling parameters). If your alternative language is safer, neater, or easier to write than C (and if it isn't, why bother with it?), you'll want a better way to handle formatted printing than C's printf.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-08 19:54 +0000 |
| Message-ID | <10mapli$26q2a$2@dont-email.me> |
| In reply to | #396647 |
On 08/02/2026 17:55, David Brown wrote:
> On 08/02/2026 17:50, Waldek Hebisch wrote:
>> Michael S <already5chosen@yahoo.com> wrote:
>>> On Fri, 6 Feb 2026 13:04:34 +0000
>>> Bart <bc@freeuk.com> wrote:
>>>
>>>> On 06/02/2026 12:47, Michael S wrote:
>>>>> On Fri, 6 Feb 2026 12:39:55 +0000
>>>>> Bart <bc@freeuk.com> wrote:
>>>>>> On 06/02/2026 05:10, Keith Thompson wrote:
>>>>>>> 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.
>>>>>>
>>>>>> I guess you've never used printf-family functions via the FFI of
>>>>>> another language!
>>>>>>
>>>>>
>>>>> Vararg via FFI? Is it really a good idea?
>>>>
>>>> It's covered by platform ABIs of both Windows and SYS V.
>>>>
>>>
>>> My question was not about technical possibility. I understand that with
>>> enough of effort everything is possible.
>>> I asked whether it is a good idea.
>>> Is not it simpler for you and for your potential users to declare that
>>> your language can not call external C functions with variable number of
>>> arguments? To me it does not sound like this ability is either necessary
>>> or very valuable.
>>>
>>> Above I assume that we are talking about your scripting language.
>>>
>>> W.r.t. your other language, I have no strong opinion. But my weak
>>> opinion is that it also does not need it, possibly with exception for
>>> ability to do few (very few, hopefully) historically idiotically
>>> defined Unix system calls that can be handled individually as special
>>> cases.
>>
>> Well, some important interfaces depend on varargs functions. And
>> while you may handle such cases via user-written wrappers, it is
>> much nicer if FFI machinery handles varargs.
>>
>
> There are only a few standard C functions that are variadic, but they
> are quite important ones (with the *printf family at the top). But
> there is little doubt that C's handling of variadic functions is very
> unsafe, and implementations are often challenging (the SysV ABI for
> x86-64 is awkward and complex for variadic functions - the Win64 ABI is
> easier for variadics at the expense of making many other function calls
> less efficient). It is a weak point in the design of C.
>
> And for other languages trying to access C code via a FFI, variadic
> functions are going to be inefficient, complicated, and unsafe (unless
> you are /very/ sure of the calling parameters). If your alternative
> language is safer, neater, or easier to write than C (and if it isn't,
> why bother with it?), you'll want a better way to handle formatted
> printing than C's printf.
For about the last 30 years I've used the C library to do i/o, as it was
simpler than Win32 calls. (I didn't even know it was supposed to be for
C; it just look like an easier library with shorter function names, that
also shipped with Windows.)
So while I do do most of my own conversion and formating, actual i/o,
and a few cases such as floating point which are fiddly, uses calls like
this:
sprintf(s, "%f", x)
sscanf(str, "%lf%n", &x, &numlength)
printf("%.*s", length, s)
fprintf(f, "%.*s", length, s)
The last two are generally called when I have a buffer-full of output.
The sscanf call is the only I ever time use *scanf functions.
In the prior 15 years of course, I did have to do everything.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-08 21:27 +0100 |
| Message-ID | <10marim$285e2$1@dont-email.me> |
| In reply to | #396650 |
On 08/02/2026 20:54, Bart wrote:
> On 08/02/2026 17:55, David Brown wrote:
>> On 08/02/2026 17:50, Waldek Hebisch wrote:
>>> Michael S <already5chosen@yahoo.com> wrote:
>>>> On Fri, 6 Feb 2026 13:04:34 +0000
>>>> Bart <bc@freeuk.com> wrote:
>>>>
>>>>> On 06/02/2026 12:47, Michael S wrote:
>>>>>> On Fri, 6 Feb 2026 12:39:55 +0000
>>>>>> Bart <bc@freeuk.com> wrote:
>>>>>>> On 06/02/2026 05:10, Keith Thompson wrote:
>>>>>>>> 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.
>>>>>>>
>>>>>>> I guess you've never used printf-family functions via the FFI of
>>>>>>> another language!
>>>>>>>
>>>>>>
>>>>>> Vararg via FFI? Is it really a good idea?
>>>>>
>>>>> It's covered by platform ABIs of both Windows and SYS V.
>>>>>
>>>>
>>>> My question was not about technical possibility. I understand that with
>>>> enough of effort everything is possible.
>>>> I asked whether it is a good idea.
>>>> Is not it simpler for you and for your potential users to declare that
>>>> your language can not call external C functions with variable number of
>>>> arguments? To me it does not sound like this ability is either
>>>> necessary
>>>> or very valuable.
>>>>
>>>> Above I assume that we are talking about your scripting language.
>>>>
>>>> W.r.t. your other language, I have no strong opinion. But my weak
>>>> opinion is that it also does not need it, possibly with exception for
>>>> ability to do few (very few, hopefully) historically idiotically
>>>> defined Unix system calls that can be handled individually as special
>>>> cases.
>>>
>>> Well, some important interfaces depend on varargs functions. And
>>> while you may handle such cases via user-written wrappers, it is
>>> much nicer if FFI machinery handles varargs.
>>>
>>
>> There are only a few standard C functions that are variadic, but they
>> are quite important ones (with the *printf family at the top). But
>> there is little doubt that C's handling of variadic functions is very
>> unsafe, and implementations are often challenging (the SysV ABI for
>> x86-64 is awkward and complex for variadic functions - the Win64 ABI
>> is easier for variadics at the expense of making many other function
>> calls less efficient). It is a weak point in the design of C.
>>
>> And for other languages trying to access C code via a FFI, variadic
>> functions are going to be inefficient, complicated, and unsafe (unless
>> you are /very/ sure of the calling parameters). If your alternative
>> language is safer, neater, or easier to write than C (and if it isn't,
>> why bother with it?), you'll want a better way to handle formatted
>> printing than C's printf.
>
> For about the last 30 years I've used the C library to do i/o, as it was
> simpler than Win32 calls. (I didn't even know it was supposed to be for
> C; it just look like an easier library with shorter function names, that
> also shipped with Windows.)
>
> So while I do do most of my own conversion and formating, actual i/o,
> and a few cases such as floating point which are fiddly, uses calls like
> this:
>
> sprintf(s, "%f", x)
> sscanf(str, "%lf%n", &x, &numlength)
> printf("%.*s", length, s)
> fprintf(f, "%.*s", length, s)
>
> The last two are generally called when I have a buffer-full of output.
>
> The sscanf call is the only I ever time use *scanf functions.
>
> In the prior 15 years of course, I did have to do everything.
>
Doing your print's by building up a C string in your own
language/runtime and then calling C's "printf("%s", p")" is safe and
should be simple enough to implement.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-02-08 19:59 +0000 |
| Message-ID | <10mapu3$318ec$2@paganini.bofh.team> |
| In reply to | #396647 |
David Brown <david.brown@hesbynett.no> wrote:
> On 08/02/2026 17:50, Waldek Hebisch wrote:
>> Michael S <already5chosen@yahoo.com> wrote:
>>> On Fri, 6 Feb 2026 13:04:34 +0000
>>> Bart <bc@freeuk.com> wrote:
>>>
>>>> On 06/02/2026 12:47, Michael S wrote:
>>>>> On Fri, 6 Feb 2026 12:39:55 +0000
>>>>> Bart <bc@freeuk.com> wrote:
>>>>>
>>>>>> On 06/02/2026 05:10, Keith Thompson wrote:
>>>>>>> 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.
>>>>>>
>>>>>> I guess you've never used printf-family functions via the FFI of
>>>>>> another language!
>>>>>>
>>>>>>
>>>>>
>>>>> Vararg via FFI? Is it really a good idea?
>>>>>
>>>>
>>>> It's covered by platform ABIs of both Windows and SYS V.
>>>>
>>>
>>> My question was not about technical possibility. I understand that with
>>> enough of effort everything is possible.
>>> I asked whether it is a good idea.
>>> Is not it simpler for you and for your potential users to declare that
>>> your language can not call external C functions with variable number of
>>> arguments? To me it does not sound like this ability is either necessary
>>> or very valuable.
>>>
>>> Above I assume that we are talking about your scripting language.
>>>
>>> W.r.t. your other language, I have no strong opinion. But my weak
>>> opinion is that it also does not need it, possibly with exception for
>>> ability to do few (very few, hopefully) historically idiotically
>>> defined Unix system calls that can be handled individually as special
>>> cases.
>>
>> Well, some important interfaces depend on varargs functions. And
>> while you may handle such cases via user-written wrappers, it is
>> much nicer if FFI machinery handles varargs.
>>
>
> There are only a few standard C functions that are variadic, but they
> are quite important ones (with the *printf family at the top). But
> there is little doubt that C's handling of variadic functions is very
> unsafe, and implementations are often challenging (the SysV ABI for
> x86-64 is awkward and complex for variadic functions - the Win64 ABI is
> easier for variadics at the expense of making many other function calls
> less efficient). It is a weak point in the design of C.
>
> And for other languages trying to access C code via a FFI, variadic
> functions are going to be inefficient, complicated, and unsafe (unless
> you are /very/ sure of the calling parameters). If your alternative
> language is safer, neater, or easier to write than C (and if it isn't,
> why bother with it?), you'll want a better way to handle formatted
> printing than C's printf.
For me 'printf' is mainly a debugging helper. Example of "important
interface" is X11. Part of that interface is variadic and there is
no way around this. Concerning safety, when using FFI there is
always problem of "passing" type information across the interface.
Smaller or bigger part of type information is provide by hand,
which in inherently unsafe. The point is to minimize and
encapsulate this part so users can assume that it just works.
Variadic functions decrease safety, but IMO this is just modest
decrease compared to "normal" troubls with FFI.
Concerning "inefficient", in cases interesting to me FFI is
inefficient and variadic functions do not change this much. Simply,
foreign calls are for serious, relatively expensive tasks.
And to make things clear: I do not advocate writing variadic
functions. But there are already libraries exporting variadic
and FFI should allow using them.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-02-08 21:51 +0100 |
| Message-ID | <10masvl$1h1k5$3@dont-email.me> |
| In reply to | #396647 |
On 2026-02-08 18:55, David Brown wrote:
> On 08/02/2026 17:50, Waldek Hebisch wrote:
>>
>> Well, some important interfaces depend on varargs functions. And
>> while you may handle such cases via user-written wrappers, it is
>> much nicer if FFI machinery handles varargs.
>
> There are only a few standard C functions that are variadic, but they
> are quite important ones (with the *printf family at the top).
Hmm.. - if I'm thinking of using "C" standard library functions from
other languages the 'printf' (or 'scanf') family would be the least
I'd be thinking of; I/O can typically be found natively in languages,
and these ("unsafe") "C" functions I'd not really consider a paragon
to abstain from a direct, type-safe, safe, and efficient use of any
native function. - So I'd not call these "C"-functions "important"
(from the perspective of the respective native language).
I was seeking for other variadic standard "C" functions but didn't
find (m)any.
Where do we need variadic functions? Functions like printf/scanf which
are costly (due to the additional format interpretation), or (as found
in other languages) things like min/max which are homogeneous in types
and are certainly better represented by arrays.
I seem to recall we used varargs in the early 1990's in context of a
logging framework, but that was all. Were do folks here use them for?
I'm really curious to hear where they're are actually used in projects.
> But
> there is little doubt that C's handling of variadic functions is very
> unsafe, and implementations are often challenging (the SysV ABI for
> x86-64 is awkward and complex for variadic functions - the Win64 ABI is
> easier for variadics at the expense of making many other function calls
> less efficient). It is a weak point in the design of C.
>
> And for other languages trying to access C code via a FFI, variadic
> functions are going to be inefficient, complicated, and unsafe (unless
> you are /very/ sure of the calling parameters). If your alternative
> language is safer, neater, or easier to write than C (and if it isn't,
> why bother with it?), you'll want a better way to handle formatted
> printing than C's printf.
Indeed.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-08 19:43 +0000 |
| Message-ID | <10map03$26q2a$1@dont-email.me> |
| In reply to | #396643 |
On 08/02/2026 08:52, Michael S wrote:
> On Fri, 6 Feb 2026 13:04:34 +0000
> Bart <bc@freeuk.com> wrote:
>
>>> Vararg via FFI? Is it really a good idea?
>>>
>>
>> It's covered by platform ABIs of both Windows and SYS V.
>>
>
> My question was not about technical possibility. I understand that with
> enough of effort everything is possible.
> I asked whether it is a good idea.
> Is not it simpler for you and for your potential users to declare that
> your language can not call external C functions with variable number of
> arguments? To me it does not sound like this ability is either necessary
> or very valuable.
>
> Above I assume that we are talking about your scripting language.
>
> W.r.t. your other language, I have no strong opinion. But my weak
> opinion is that it also does not need it, possibly with exception for
> ability to do few (very few, hopefully) historically idiotically
> defined Unix system calls that can be handled individually as special
> cases.
It's needed if any program in either of my languages needs to call an
FFI function in a library that happens to use variadic arguments.
I already know that at least one language needs to call *printf with at
least two arguments.
But it can come up elsewhere. Looking around:
extern DECLSPEC void SDLCALL SDL_Log(SDL_PRINTF_FORMAT_STRING const
char *fmt, ...) SDL_PRINTF_VARARG_FUNC(1);
SQLITE_API int sqlite3_config(int, ...); // many like this
SQLITE_PRIVATE void sqlite3VdbeMultiLoad(Vdbe*,int,const char*,...);
LUA_API int (lua_gc) (lua_State *L, int what, ...);
int *elem(array a, ...){
static void error(const char *msg, ...)
int open(const char* filename, int flags, ...)
int wsprintfW(LPWSTR,LPCWSTR,...);
Mostly likely variadic functions were only created in order to implement
'print', but nothing stops people using them for other purposes.
So the likelihood is there for them to occur in APIs.
In my case, most support I have to do is within my backend, and the same
backend is needed for my C compiler. So it is needed anyway.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-02-06 14:06 +0100 |
| Message-ID | <10m4p0h$62n5$1@dont-email.me> |
| In reply to | #396624 |
On 06/02/2026 13:47, Michael S wrote: > On Fri, 6 Feb 2026 12:39:55 +0000 > Bart <bc@freeuk.com> wrote: > >> On 06/02/2026 05:10, Keith Thompson wrote: >>> 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. >> >> I guess you've never used printf-family functions via the FFI of >> another language! >> >> > > Vararg via FFI? Is it really a good idea? > No. Every language I have used has had its own way to handle printing. Usually that is more convenient, in at least some aspects, than C's printf family. But if some other language wants to do its printing by calling C's printf, and that leads to troubles or limitations, that's the fault of the other language. (We can recall that Bart has regularly blamed C for issues, complications or limitations in his own language - as though the original designers of C had an obligation to make it easier for Bart to make tools for a completely different language.)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-02-07 18:07 +0000 |
| Message-ID | <20260207095555.618@kylheku.com> |
| In reply to | #396624 |
On 2026-02-06, Michael S <already5chosen@yahoo.com> wrote:
> On Fri, 6 Feb 2026 12:39:55 +0000
> Bart <bc@freeuk.com> wrote:
>
>> On 06/02/2026 05:10, Keith Thompson wrote:
>> > 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.
>>
>> I guess you've never used printf-family functions via the FFI of
>> another language!
>>
>>
>
> Vararg via FFI? Is it really a good idea?
I support it in TXR Lisp. However, it's limited in that the FFI
definition is nailed to a particular choice of arguments.
For instance we could make a function foo which takes two arguments:
a str and an int, and calls the variadic printf.
Then we can call (foo "%d" 42). It will call printf("%d", 42).
We cannot pass fewer or more than two arguments to foo, and they have to
be compatible with str and int.
Demo:
$ txr
This is the TXR Lisp interactive listener of TXR 302.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
1> (with-dyn-lib nil
(deffi printf-int "printf" int (str : int)))
printf-int
2> (printf-int "%d\n" 42)
42
3
42 is output; 3 is the result value (3 characters output).
The : syntax in the deffi macro call indicates the variadic list.
It's not the case that we can make a variadic Lisp function pass its arguments
as an arbitrarily long variadic list with arbitrary types to the wrapped FFI
function. Fixed parameters must be declared after the colon.
A dynamic treatment could be arranged via a heavy weight wrapper mechanism which
dynamically analyzes the actual arguments, builds a libffi function descriptor
on the fly, then uses it to make the call; it could be wortwhile for someone,
but I didn't implement such a thing. Metaprogramming tricks revolving around
dynamically evaluating deffi are also possible.
--
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:32 +0000 |
| Message-ID | <10m87g6$1cvj8$1@dont-email.me> |
| In reply to | #396638 |
On 07/02/2026 18:07, Kaz Kylheku wrote:
> On 2026-02-06, Michael S <already5chosen@yahoo.com> wrote:
>> On Fri, 6 Feb 2026 12:39:55 +0000
>> Bart <bc@freeuk.com> wrote:
>>
>>> On 06/02/2026 05:10, Keith Thompson wrote:
>>>> 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.
>>>
>>> I guess you've never used printf-family functions via the FFI of
>>> another language!
>>>
>>>
>>
>> Vararg via FFI? Is it really a good idea?
>
> I support it in TXR Lisp. However, it's limited in that the FFI
> definition is nailed to a particular choice of arguments.
>
> For instance we could make a function foo which takes two arguments:
> a str and an int, and calls the variadic printf.
>
> Then we can call (foo "%d" 42). It will call printf("%d", 42).
>
> We cannot pass fewer or more than two arguments to foo, and they have to
> be compatible with str and int.
>
> Demo:
>
> $ txr
> This is the TXR Lisp interactive listener of TXR 302.
> Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
> 1> (with-dyn-lib nil
> (deffi printf-int "printf" int (str : int)))
> printf-int
> 2> (printf-int "%d\n" 42)
> 42
> 3
>
> 42 is output; 3 is the result value (3 characters output).
>
> The : syntax in the deffi macro call indicates the variadic list.
> It's not the case that we can make a variadic Lisp function pass its arguments
> as an arbitrarily long variadic list with arbitrary types to the wrapped FFI
> function. Fixed parameters must be declared after the colon.
There's another issue with calling variadic functions, unrelated to the
number of args. I can't tell from the above whether it's convered.
Normally an arg that is passed in a register, will be passed in GPR for
integer, or a floating point register if not.
But a variadic float argument has to be passed in both, so for Win64
ABI/x64 it might be in both rcx and xmm1. I think it is similar on SYS V
for both x64 and arm64 (maybe on the latter both are passed in the GPR;
I'd have to go and look it up).
> A dynamic treatment could be arranged via a heavy weight wrapper mechanism which
> dynamically analyzes the actual arguments, builds a libffi function descriptor
> on the fly, then uses it to make the call; it could be wortwhile for someone,
> but I didn't implement such a thing. Metaprogramming tricks revolving around
> dynamically evaluating deffi are also possible.
My LIBFFI approach just uses assembly; it's the simplest way to do it.
(The LIBFFI 'C' library also uses assembly to do the tricky bits.)
There, for Win64 ABI, I found it easiest to just load all the register
args to both integer and float registers, whether the called function
was variadic or not. That's far more efficient than figuring out the
right register argument by argument.
I haven't implemented that for SYS V; that's more of a nightmare ABI
where up to 6-12 args (8-16 on aarch64) can be passed between int and
float registers depending on the mix of types.
On Win64 ABI, it is 4 args, always.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-02-07 22:48 +0000 |
| Message-ID | <10m8ffu$2moia$1@paganini.bofh.team> |
| In reply to | #396639 |
Bart <bc@freeuk.com> wrote:
> On 07/02/2026 18:07, Kaz Kylheku wrote:
>> On 2026-02-06, Michael S <already5chosen@yahoo.com> wrote:
>>> On Fri, 6 Feb 2026 12:39:55 +0000
>>> Bart <bc@freeuk.com> wrote:
>>>
>>>> On 06/02/2026 05:10, Keith Thompson wrote:
>>>>> 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.
>>>>
>>>> I guess you've never used printf-family functions via the FFI of
>>>> another language!
>>>>
>>>>
>>>
>>> Vararg via FFI? Is it really a good idea?
>>
>> I support it in TXR Lisp. However, it's limited in that the FFI
>> definition is nailed to a particular choice of arguments.
>>
>> For instance we could make a function foo which takes two arguments:
>> a str and an int, and calls the variadic printf.
>>
>> Then we can call (foo "%d" 42). It will call printf("%d", 42).
>>
>> We cannot pass fewer or more than two arguments to foo, and they have to
>> be compatible with str and int.
>>
>> Demo:
>>
>> $ txr
>> This is the TXR Lisp interactive listener of TXR 302.
>> Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
>> 1> (with-dyn-lib nil
>> (deffi printf-int "printf" int (str : int)))
>> printf-int
>> 2> (printf-int "%d\n" 42)
>> 42
>> 3
>>
>> 42 is output; 3 is the result value (3 characters output).
>>
>> The : syntax in the deffi macro call indicates the variadic list.
>> It's not the case that we can make a variadic Lisp function pass its arguments
>> as an arbitrarily long variadic list with arbitrary types to the wrapped FFI
>> function. Fixed parameters must be declared after the colon.
>
> There's another issue with calling variadic functions, unrelated to the
> number of args. I can't tell from the above whether it's convered.
>
> Normally an arg that is passed in a register, will be passed in GPR for
> integer, or a floating point register if not.
>
> But a variadic float argument has to be passed in both, so for Win64
> ABI/x64 it might be in both rcx and xmm1. I think it is similar on SYS V
> for both x64 and arm64 (maybe on the latter both are passed in the GPR;
> I'd have to go and look it up).
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.
>> A dynamic treatment could be arranged via a heavy weight wrapper mechanism which
>> dynamically analyzes the actual arguments, builds a libffi function descriptor
>> on the fly, then uses it to make the call; it could be wortwhile for someone,
>> but I didn't implement such a thing. Metaprogramming tricks revolving around
>> dynamically evaluating deffi are also possible.
>
> My LIBFFI approach just uses assembly; it's the simplest way to do it.
> (The LIBFFI 'C' library also uses assembly to do the tricky bits.)
>
> There, for Win64 ABI, I found it easiest to just load all the register
> args to both integer and float registers, whether the called function
> was variadic or not. That's far more efficient than figuring out the
> right register argument by argument.
>
> I haven't implemented that for SYS V; that's more of a nightmare ABI
> where up to 6-12 args (8-16 on aarch64) can be passed between int and
> float registers depending on the mix of types.
>
> On Win64 ABI, it is 4 args, always.
My code works fine for SYS V on amd64 and arm32. I do not think FFI
for aarch64 will be any harder, but ATM I do not have code generator
for aarch64, no need for FFI there.
I did not bother with Windows, since I do not use it it would be
untested and hence buggy code anyway.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-07 23:54 +0000 |
| Message-ID | <10m8jbb$1hasa$1@dont-email.me> |
| In reply to | #396641 |
On 07/02/2026 22:48, Waldek Hebisch wrote: > Bart <bc@freeuk.com> wrote: >> On 07/02/2026 18:07, Kaz Kylheku wrote: >>> The : syntax in the deffi macro call indicates the variadic list. >>> It's not the case that we can make a variadic Lisp function pass its arguments >>> as an arbitrarily long variadic list with arbitrary types to the wrapped FFI >>> function. Fixed parameters must be declared after the colon. >> >> There's another issue with calling variadic functions, unrelated to the >> number of args. I can't tell from the above whether it's convered. >> >> Normally an arg that is passed in a register, will be passed in GPR for >> integer, or a floating point register if not. >> >> But a variadic float argument has to be passed in both, so for Win64 >> ABI/x64 it might be in both rcx and xmm1. I think it is similar on SYS V >> for both x64 and arm64 (maybe on the latter both are passed in the GPR; >> I'd have to go and look it up). > > 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. 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. And even then, because the int and non-int args are spilled to separate blocks, it has to keep track of where the next arg is in which block. I think MS made the better call here; the necessary code is trivial for Win64 ABI. >>> A dynamic treatment could be arranged via a heavy weight wrapper mechanism which >>> dynamically analyzes the actual arguments, builds a libffi function descriptor >>> on the fly, then uses it to make the call; it could be wortwhile for someone, >>> but I didn't implement such a thing. Metaprogramming tricks revolving around >>> dynamically evaluating deffi are also possible. >> >> My LIBFFI approach just uses assembly; it's the simplest way to do it. >> (The LIBFFI 'C' library also uses assembly to do the tricky bits.) >> >> There, for Win64 ABI, I found it easiest to just load all the register >> args to both integer and float registers, whether the called function >> was variadic or not. That's far more efficient than figuring out the >> right register argument by argument. >> >> I haven't implemented that for SYS V; that's more of a nightmare ABI >> where up to 6-12 args (Actually, 6-14 args; 6 max in GPRs and 8 in xmm regs) > (8-16 on aarch64) can be passed between int and >> float registers depending on the mix of types. >> >> On Win64 ABI, it is 4 args, always. > > My code works fine for SYS V on amd64 and arm32. I do not think FFI > for aarch64 will be any harder, but ATM I do not have code generator > for aarch64, no need for FFI there. > > I did not bother with Windows, since I do not use it it would be > untested and hence buggy code anyway. 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!). 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. (I understand that neither LLVM or Cranelist backends support them directly; they need to be dealt with earlier on, so the user of those IRs needs to figure it out.) >and hence buggy code anyway. I think you'd find it much simpler.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-02-08 19:21 +0000 |
| Message-ID | <10mano3$318ec$1@paganini.bofh.team> |
| In reply to | #396642 |
Bart <bc@freeuk.com> wrote:
> On 07/02/2026 22:48, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>> On 07/02/2026 18:07, Kaz Kylheku wrote:
>
>>>> The : syntax in the deffi macro call indicates the variadic list.
>>>> It's not the case that we can make a variadic Lisp function pass its arguments
>>>> as an arbitrarily long variadic list with arbitrary types to the wrapped FFI
>>>> function. Fixed parameters must be declared after the colon.
>>>
>>> There's another issue with calling variadic functions, unrelated to the
>>> number of args. I can't tell from the above whether it's convered.
>>>
>>> Normally an arg that is passed in a register, will be passed in GPR for
>>> integer, or a floating point register if not.
>>>
>>> But a variadic float argument has to be passed in both, so for Win64
>>> ABI/x64 it might be in both rcx and xmm1. I think it is similar on SYS V
>>> for both x64 and arm64 (maybe on the latter both are passed in the GPR;
>>> I'd have to go and look it up).
>>
>> 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 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. So, this affects only "intermediate"
functions that want to repack/shuffle arguments before passing them
to some other function. That happens, but is reasonably rare.
In one such case I just decided that intermediate function will
work only for arguments passed in integer registers (this covered
the actual use case). Note that regardless of types there is still
problem of number of arguments. In my case the intermediate function
just grabs 20 arguments and passes them further. Of course this
is undefined behaviour in C, but in practice the function just
gets garbage for non-existing arguments. The final recipient knows
how many arguments were really passed and ignores extra garbage.
> And even then, because the int and non-int args are spilled to separate
> blocks, it has to keep track of where the next arg is in which block.
>
> I think MS made the better call here; the necessary code is trivial for
> Win64 ABI.
>
>>>> A dynamic treatment could be arranged via a heavy weight wrapper mechanism which
>>>> dynamically analyzes the actual arguments, builds a libffi function descriptor
>>>> on the fly, then uses it to make the call; it could be wortwhile for someone,
>>>> but I didn't implement such a thing. Metaprogramming tricks revolving around
>>>> dynamically evaluating deffi are also possible.
>>>
>>> My LIBFFI approach just uses assembly; it's the simplest way to do it.
>>> (The LIBFFI 'C' library also uses assembly to do the tricky bits.)
>>>
>>> There, for Win64 ABI, I found it easiest to just load all the register
>>> args to both integer and float registers, whether the called function
>>> was variadic or not. That's far more efficient than figuring out the
>>> right register argument by argument.
>>>
>>> I haven't implemented that for SYS V; that's more of a nightmare ABI
>>> where up to 6-12 args
>
> (Actually, 6-14 args; 6 max in GPRs and 8 in xmm regs)
>
>> (8-16 on aarch64) can be passed between int and
>>> float registers depending on the mix of types.
>>>
>>> On Win64 ABI, it is 4 args, always.
>>
>> My code works fine for SYS V on amd64 and arm32. I do not think FFI
>> for aarch64 will be any harder, but ATM I do not have code generator
>> for aarch64, no need for FFI there.
>>
>> I did not bother with Windows, since I do not use it it would be
>> untested and hence buggy code anyway.
>
> 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.
> 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:
static void
store_single(arg_state * as, void * sp, reg_buff * rp, float val) {
float * dst;
int sfi = as->sfi;
if (sfi < 16) {
int dfi1 = sfi >> 1;
if (sfi & 1) {
dst = &(rp->f_reg[dfi1].sf2.sh);
as->sfi = (as->dfi)<<1;
} else {
dst = &(rp->f_reg[dfi1].sf2.sl);
as->sfi++;
as->dfi = (as->dfi > dfi1)?as->dfi:(dfi1 + 1);
}
} else {
dst = (float *)sp + as->si;
as->si++;
}
memcpy(dst, &val, sizeof(val));
}
static void
store_double(arg_state * as, void * sp, reg_buff * rp, double val) {
int dfi = as->dfi;
double * dst;
if (dfi < 8) {
dst = &(rp->f_reg[dfi].d);
as->dfi++;
if (as->sfi == (dfi<<1)) {
as->sfi = (as->dfi<<1);
}
} else {
int si = as->si;
as->sfi = 16;
si = (si + 1)&(~1);
dst = (double *)sp + (si>>1);
as->si = si + 2;
}
memcpy(dst, &val, sizeof(val));
}
static void
store_int(arg_state * as, void * sp, reg_buff * rp, int val) {
int ni = as->ni;
if (ni < 4) {
rp->i_reg[ni] = val;
as->ni++;
} else {
*((int *)sp + as->si) = val;
as->si++;
}
}
There is main loop that goes over argument and calls 'store_int',
'store_double' or 'store_single' as apropriate (actual determiantion
of types is specific to my program, so I skip this part, the above
in principle is reusable).
> (I understand that neither LLVM or Cranelist backends support them
> directly; they need to be dealt with earlier on, so the user of those
> IRs needs to figure it out.)
>
>>and hence buggy code anyway.
>
> I think you'd find it much simpler.
>
>
>
--
Waldek Hebisch
PR_AS;
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-02-08 23:35 +0000 |
| Message-ID | <10mb6k2$2c1be$1@dont-email.me> |
| In reply to | #396648 |
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.
>> 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?
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web