Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #379646 > unrolled thread
| Started by | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| First post | 2023-12-26 16:59 +0100 |
| Last post | 2024-01-08 22:20 -0800 |
| Articles | 20 on this page of 671 — 31 participants |
Back to article view | Back to comp.lang.c
Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-26 16:59 +0100
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-26 17:45 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-26 22:50 +0000
Re: Effect of CPP tags Spiros Bousbouras <spibou@gmail.com> - 2023-12-27 17:11 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 14:45 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-28 17:34 +0100
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-28 14:11 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-28 13:13 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:47 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-28 15:12 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-20 14:29 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 04:46 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 10:56 -0500
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 12:11 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 17:55 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 21:57 -0500
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-24 07:42 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-31 12:43 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 13:41 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-02-01 09:19 +0100
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:11 -0700
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 23:56 -0700
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:12 -0700
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 17:38 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:33 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:42 +0000
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-28 18:04 -0500
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 16:11 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 16:04 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 17:51 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:22 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-29 15:52 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 17:27 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 11:01 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-29 22:18 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-31 14:40 +0100
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-12-31 12:43 -0500
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 12:57 +0100
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 18:32 -0800
usleep (Was: Effect of CPP tags) gazelle@shell.xmission.com (Kenny McCormack) - 2023-12-29 18:10 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-29 02:35 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-29 13:31 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-29 15:58 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 10:33 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 20:23 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-29 22:40 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 01:28 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-30 01:58 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 01:36 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 02:06 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:33 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 13:09 +0100
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-03 00:20 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 12:49 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 09:11 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 21:41 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-31 16:25 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 15:45 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:40 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 18:44 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 19:37 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 22:00 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 16:03 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 02:58 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 19:18 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-01 05:38 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 22:56 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 08:54 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 20:00 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 15:38 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 21:44 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 13:51 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 00:12 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 22:57 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 07:00 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:03 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:06 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 09:18 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 15:44 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 15:54 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 11:42 +0100
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:04 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 16:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 18:34 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 20:24 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-02 13:00 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-02 13:02 -0800
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-03 00:24 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 02:41 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-03 03:29 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 11:55 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-03 15:32 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 17:14 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 20:16 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-03 19:57 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 09:46 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-04 18:57 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 23:48 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 01:57 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 02:20 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 16:08 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 18:35 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-04 20:55 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 20:17 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 15:22 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-05 10:03 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 18:37 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 19:25 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 21:14 +0000
Re: Effect of CPP tags Jim Jackson <jj@franjam.org.uk> - 2024-01-04 22:07 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 22:48 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-04 23:14 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 23:48 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-04 23:25 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 01:53 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-05 04:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-05 15:05 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 07:58 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-05 17:34 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 18:42 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 08:39 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 19:15 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:21 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 10:06 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 16:29 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 18:44 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 19:33 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 20:06 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 14:50 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 01:09 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 17:55 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-07 01:00 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:56 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 10:02 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 22:19 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 22:43 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 02:04 +0000
Re: Effect of CPP tags Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-05 23:02 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 01:45 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 18:17 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 10:09 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 10:27 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 15:23 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 13:40 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 00:09 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:16 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 16:40 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:58 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-07 03:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-07 15:48 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 15:34 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 13:50 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 15:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 20:50 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 01:05 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 08:30 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 11:11 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 15:56 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 17:46 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 19:56 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 20:52 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 13:15 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 21:33 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-09 21:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 22:22 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 09:37 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 12:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 14:17 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 14:31 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 16:51 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 18:57 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:55 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 20:49 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 11:26 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:19 -0800
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-11 00:30 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 01:14 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:25 -0800
Re: Effect of CPP tags Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-11 17:56 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 18:31 +0000
Make (was: Re: Effect of CPP tags) vallor <vallor@cultnix.org> - 2024-01-15 21:01 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 02:29 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-10 17:46 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 14:51 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 17:58 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 19:16 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:30 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:27 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 14:22 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 17:37 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 23:27 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 16:05 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 00:40 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 16:49 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 02:04 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 19:17 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:26 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-10 11:22 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 01:54 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-10 02:57 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 05:28 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-10 06:28 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 09:50 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-09 23:40 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:10 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:10 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:11 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 11:55 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 11:42 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 14:59 -0800
Re: Effect of CPP tags vallor <vallor@cultnix.org> - 2024-01-11 14:58 +0000
A good place to discuss Makefiles? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-11 16:56 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 02:00 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 02:14 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:16 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 14:49 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 18:13 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 10:39 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 19:24 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 11:39 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:42 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 20:20 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 12:42 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 21:43 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 22:36 +0000
Re: Effect of CPP tags Paul <nospam@needed.invalid> - 2024-01-10 21:39 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 02:46 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 11:44 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 12:19 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 16:13 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-11 17:00 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 21:18 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-11 23:03 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 23:58 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 09:08 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 18:49 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 12:16 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 22:02 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 23:20 +0000
Re: Effect of CPP tags Anthony Cuozzo <anthony@cuozzo.us> - 2024-01-11 19:02 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 16:23 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 14:40 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 16:01 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 16:28 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:16 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 20:21 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 16:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 17:34 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 17:09 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:02 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 21:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 13:07 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 21:51 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 00:13 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 16:47 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 01:12 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 17:40 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-13 15:07 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-13 16:02 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:17 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 12:03 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-13 13:42 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 22:39 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-14 00:02 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 14:33 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-13 15:26 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 00:36 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-14 16:20 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:19 +0100
Makefile as an implementation instance of a transformation process (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-15 15:46 +0100
Re: Makefile as an implementation instance of a transformation process (was Re: Effect of CPP tags) Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-15 15:41 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:54 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 18:17 +0000
Re: Effect of CPP tags Anthony Cuozzo <anthony@cuozzo.us> - 2024-01-14 13:44 -0500
Re: Effect of CPP tags Jim Jackson <jj@franjam.org.uk> - 2024-01-14 19:16 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 19:57 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 13:14 -0800
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 09:51 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 11:39 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:57 +0100
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:40 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:41 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 18:41 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 19:12 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 19:32 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 20:12 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 23:28 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 00:04 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 18:23 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:22 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 21:16 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 15:24 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:45 +0100
Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 06:01 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 11:44 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 12:21 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 14:10 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 19:35 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:48 +0100
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:42 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 14:56 +0000
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:43 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:10 +0100
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-15 11:22 -0500
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:22 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 01:02 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 06:54 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 14:08 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 01:13 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 12:57 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 12:45 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-15 14:11 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 19:44 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 20:09 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 21:06 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 12:41 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:40 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:06 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 16:50 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:43 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 17:59 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:10 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 18:53 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 19:18 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 20:16 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:18 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:15 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 12:59 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 04:36 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:01 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:05 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:08 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:31 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 07:13 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 19:15 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 20:14 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:12 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:46 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:52 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:57 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 21:39 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:22 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 18:10 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 13:11 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-14 14:58 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 01:05 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 20:44 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 20:39 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-14 21:47 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 22:37 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 14:20 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:21 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 00:52 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 12:09 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:16 +0000
Re: Effect of CPP tags Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-12 23:04 +0000
Re: Effect of CPP tags Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-12 23:30 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-13 00:16 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 11:16 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 18:47 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 19:42 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 22:18 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 23:48 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-17 16:23 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 00:25 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 00:47 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 04:30 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 10:26 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 19:40 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 20:21 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 11:07 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 11:17 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 12:41 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 13:18 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 15:42 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 15:03 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 18:12 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 18:28 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-19 18:43 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 19:48 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-19 17:32 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 17:05 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 19:50 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-19 14:18 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-19 14:14 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-19 16:18 +0000
Re: Effect of CPP tags dave_thompson_2@comcast.net - 2024-02-26 04:17 -0500
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-02-26 15:56 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 15:16 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-18 21:47 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 23:46 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 23:29 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:23 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-21 00:40 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 12:42 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 21:31 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:04 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 12:18 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 00:34 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 02:14 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 07:07 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 23:36 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 07:40 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 17:04 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 17:29 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:27 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 23:24 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 18:18 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:38 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 16:55 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 17:08 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 02:21 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:34 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 18:35 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 03:03 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 19:59 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 13:28 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-17 12:55 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:24 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 20:02 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 11:54 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:42 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-16 15:08 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:54 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:57 +0000
CPU's MAC instructions (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 06:25 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 18:52 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 14:15 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 14:35 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 15:44 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:35 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 18:55 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 19:19 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:31 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 01:21 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 11:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 15:06 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 17:04 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 13:43 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-17 13:00 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-18 13:00 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:28 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:58 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:55 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 22:02 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:55 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 18:39 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 00:11 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 16:11 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:42 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:44 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:28 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 16:39 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 16:23 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 21:25 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 20:41 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 15:08 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 16:02 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 19:03 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 18:45 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 23:00 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 22:10 +0000
Re: Effect of CPP tags Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-16 22:18 +0000
NO vs. SE (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 07:11 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 14:17 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 16:33 +0000
Re: NO vs. SE (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 18:47 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 18:04 +0000
Re: NO vs. SE (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 19:15 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) om@iki.fi (Otto J. Makela) - 2024-01-18 17:22 +0200
Re: NO vs. SE (was Re: Effect of CPP tags) Phil Carmody <pc+usenet@asdf.org> - 2024-03-24 14:24 +0200
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 12:26 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:29 +0100
Interpreter Dispatch in C (was: Effect of CPP Tags) bart <bc@freeuk.com> - 2024-01-16 19:21 +0000
Re: Interpreter Dispatch in C David Brown <david.brown@hesbynett.no> - 2024-01-16 23:24 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 15:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 18:46 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 22:42 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 14:25 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 14:51 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 19:07 +0100
Optimization and inline assembly (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 07:07 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 18:58 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 19:01 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 09:52 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 09:41 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:20 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 13:24 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 13:45 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 14:55 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-11 12:27 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:04 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 16:24 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:36 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:43 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:36 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 20:05 -0500
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:54 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 01:32 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:45 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:33 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:48 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:49 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 22:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:23 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 19:23 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:46 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 08:21 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 19:20 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 20:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 13:12 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 21:37 +0000
Re: Effect of CPP tags Ike Naar <ike@sdf.org> - 2024-01-09 21:51 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 16:42 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 12:04 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 18:12 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 12:11 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 21:51 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 01:50 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:28 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-09 07:38 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-07 02:12 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:45 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:47 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 02:16 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 17:15 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 02:25 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 19:28 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 15:26 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 15:51 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 01:32 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 20:35 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 13:28 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:25 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 18:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 19:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 11:22 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 11:21 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 16:00 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 18:02 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:39 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 21:36 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:32 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 21:41 +0100
Re: Effect of CPP tags Ike Naar <ike@sdf.org> - 2024-01-08 08:53 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 09:59 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 12:53 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 14:11 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 15:28 +0100
Re: Effect of CPP tags Richard Damon <richard@damon-family.org> - 2024-01-06 09:56 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 15:57 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-06 23:58 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-06 23:45 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 00:21 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:26 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 02:14 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 12:14 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 19:29 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 22:41 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 23:27 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 15:43 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-07 03:32 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 11:37 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 14:41 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 22:54 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 16:06 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 15:54 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 16:23 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 09:55 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 12:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 15:29 +0100
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-06 05:33 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 17:41 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 21:32 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 15:13 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-03 13:42 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 12:46 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 12:37 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 12:51 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 18:21 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 10:43 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 17:39 -0500
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 12:33 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 10:36 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 21:59 +0100
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 16:38 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-02 20:23 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:35 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-02 20:54 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 20:28 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:45 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 23:08 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 18:16 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:05 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 21:45 +0000
Re: Effect of CPP tags Richard Damon <richard@damon-family.org> - 2023-12-29 11:58 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 17:44 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 10:54 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 20:19 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-12-30 06:51 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 16:16 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 23:21 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 19:14 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 01:34 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 02:18 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 23:46 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 15:26 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 17:26 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 19:23 +0000
Re: Effect of CPP tags Richard Damon <news.x.richarddamon@xoxy.net> - 2023-12-31 14:46 -0500
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-31 15:49 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 23:46 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 01:33 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 02:00 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 11:56 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-01 13:06 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 20:13 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-01 20:20 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 02:34 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:39 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:38 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 22:51 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 23:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 23:45 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 00:05 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 01:14 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 01:58 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 20:41 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 22:21 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 06:23 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 06:47 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 12:24 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:04 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 20:11 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 20:43 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 23:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 02:08 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 02:40 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 12:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 13:03 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 19:14 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-03 15:33 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-03 08:37 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:54 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 20:05 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-01 15:45 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 20:06 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 04:48 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:00 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:40 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:49 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 00:06 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 16:29 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 16:38 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:01 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:37 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-31 16:59 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 20:12 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 16:07 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 16:36 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 18:31 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 19:08 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 12:36 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-01 05:56 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 22:59 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:20 -0800
Page 28 of 34 — ← Prev page 1 … 26 27 [28] 29 30 … 34 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-08 11:21 -0800 |
| Message-ID | <87sf37pr5s.fsf@nosuchdomain.example.com> |
| In reply to | #379932 |
Bart <bc@freeuk.cm> writes:
> On 08/01/2024 18:25, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
[...]
>>> It's not even clear if it is actually wrong in your example other than
>>> using more memory than expected. Look at the output of the gcc example
>>> above: what's with the missing 3 bytes?
>> What missing 3 bytes? The gcc output looked correct to me.
>
> Look carefully at the last digit. It should be '5' for SIZE_MAX, but
> sizeof() reports a value with '2' at the end.
>
> This is a complete program:
>
>
> #include <stdio.h>
> #include <stdint.h>
>
> int main(void) {
> unsigned long long int n=SIZE_MAX;
> int A[n];
>
> printf("%zu\n",sizeof(A));
> printf("%zu\n",SIZE_MAX);
> }
I see; I didn't know which gcc example you were referring to.
sizeof A would be 4*SIZE_MAX if that were possible. Mathematically,
SIZE_MAX is 0xffffffffffffffff for this implementation, and SIZE_MAX*4
would be 0x3fffffffffffffffc. Taking the lower 64 bits gives
0x3fffffffffffffffc, which is 18446744073709551612 in decimal.
The code exceeds a capacity limit. The standard doesn't explicitly say
that an object size can't exceed SIZE_MAX bytes, but I'd say the code
has undefined behavior at best.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-08 16:00 +0100 |
| Message-ID | <unh2nb$1iplq$1@dont-email.me> |
| In reply to | #379920 |
On 08/01/2024 02:32, Bart wrote:
> On 07/01/2024 23:51, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>
>> Here's a small non-executable example:
>>
>> #include <stddef.h>
>>
>> size_t foo_size;
>> size_t bar_size;
>>
>> void func(void) {
>> int n = 42;
>> typedef int vla[n];
>> vla foo;
>> vla bar;
>
> This isn't how VLAs are typically used. I think there are three kinds of
> people when it comes to VLAs:
>
> (1) Those who don't know about them and only inadvertently create
> them because the dimension is a variable not a compiler-time
> expression
>
> (2) Those who know about VLAs, but who will supply the dimensions to
> the variable declaration
>
> (3) A minority who know that VLA dimensions can also be used in
> typedefs.
>
I would have thought that a majority of C programmers know that an array
size can be used in a typedef. If they also know that array sizes can
be non-constant (not every C programmer knows VLAs exist), it seems a
small step to know that you can use typedef with VLAs.
I think quite a lot of VLAs are of sizes that are known at compile time,
but are not "constants" according to C's strict definitions. For example :
void foo(void) {
const int rows = 10;
const int cols = 20;
const int entries = rows * cols;
int data[entries];
}
"data" is a VLA in C - yet its dimension can be fully established at
compile-time. (It would be legal in C++, where there are no C-style
VLAs but where a wider range of things can be view as "constant enough"
to be the size of an array.)
If I want to make a VLA of size based on a variable, I'll define it
directly. If I want to make several VLA's of the same size, I might use
a typedef - or I might define them all directly, whatever is (IMHO)
clearest in the code. I don't expect the compiler to treat them
differently. Far and away the most common situation, I think, is that
you have just one VLA.
> In the case of (2), what happens is that some storage is reserved for a
> size. A clever compiler can use one lot of storage if it realises
> multiple variables use that same size.
>
An even cleverer compiler usually doesn't need to store the size at all,
anywhere. A typical real-world implementation of a VLA like "T xs[n]"
will mean preserving the current stack pointer, then subtracting
sizeof(T) * n. The new stack pointer is the address of xs, and if you
need its size, it is available as "n". It is only if the variable "n"
is later changed - which would likely be a silly way to write your code,
but people do silly things - that the compiler has to preserve the
original "n" in some way. But it will do that as though you had written
"const sizeof_t original_n = n;" at the VLA definition. Storing on the
stack, or in a register, or combining with other things, is just part of
the daily grind for a compiler, optimised as well or as badly as it does
for anything else.
You seem to imagine this is all special, and complicated, and difficult,
full of corner cases. It is not - it needs nothing more than a local
constant variable that is hidden from the user. Everything else is
normal compiler work. (Optimising register allocation, stack slot
usage, variable lifetimes, etc., - /that/ is hard work. Adding an
another constant variable to the function is not.)
> But whatever it is, you saying that bit of storage is to do with the
> type; I'm saying it's to do with the instance of that type. In the end
> it probably doesn't matter.
It doesn't matter to the VLA user, certainly. And since each variable
has a type, the compiler could attach information about the type to each
instance of that type - but it would probably be an unhelpful way to
think about things.
After all, having types that are anonymous and only ever used once is
not new in C :
struct { int a; int b; } x;
struct { int a; int b; } y;
x and y are different types, used only once, and with no way to refer to
the type again (until C23 "typeof").
>
> It does however still bother me that a mere typedef, not actually used
> for anything, could take up runtime resources.
That's a matter of implementation quality. Lots of things that are not
actually used can take up runtime resources, from debug information
taking up run-time memory to unoptimised code that does calculations or
has variables or stage usage that never actually affects the outcome of
the program.
>
>
>>> At the next level up, if row_count and col_count are really not known
>>> until runtime (your example would be better off as enums), then yes,
>>> there would be 1000 rows, and each row is a 2000-element array
>>> containing its length.
>>
>> If row_count and col_count were enums, they would be constants, and
>> vla_2d would not be a VLA. The whole point is that we're talking about
>> VLAs.
>
> This is actually an important point. Many examples of VLAs I've seen are
> exactly like your example, due to point (1) above.
>
I agree that many uses of VLA's are actually with sizes that are known
at compile time. A good compiler will not need to store the size
anywhere, a less optimising compiler might store the size somewhere.
(Since you are not trying to make a conforming compiler, you could quite
reasonably allow such VLA's, treating them identically to normal arrays,
while disallowing VLA's whose size is not known until compile time.)
>
>> Yes, VLAs can result in stack overflows. So can ordinary fixed-length
>> arrays.
>
> VLAs can do so much more easily:
>
> void F(int n) { int A[n];}
>
> What are the likely values of n? Without VLAs you have to knowingly use
> large fixed values of n, and/or rely on deep recursion, to get overflow.
>
This is a myth that is regularly trotted out by people who, for unknown
reasons, don't like VLAs. They pretend that somehow heap allocation is
"safer" because malloc will return 0 if an allocation fails, while VLA's
have no such mechanism. In reality, if you were to write "malloc(n)"
with no idea what "n" might be, your program is as hopelessly unsound as
one that writes "int A[n];" with no idea what "n" might be. If you are
writing a good, safe program, you know the range for "n", and know
whether it makes sense for a VLA. Sanitizing your inputs is one of the
first lessons in programming. So please, let this be the last time this
silly complaint about VLAs turns up.
>> If you define a VLA that you know can't be longer than N
>> elements, then that's no more dangerous that defining an ordinary array
>> with a length of exactly N.
>
> The compiler likely doesn't know. Some compilers (like gcc on Windows)
> use a call like __checkstk() to allocate local storage which it either
> knows will exceed 4KB, or it might do (like a VLA, even if n turns out
> to be only 3).
>
Keith wrote "that /you/ know can't be longer than N". The programmer is
responsible for writing correct code, not the compiler.
>
>> This is clearly a bug in lccwin. Feel free to report it to jacob navia
>> and/or post to comp.compilers.lcc. I don't think he'd be interested in
>> hearing about it from me.
>
> This is important too. If someone that experienced with implementing C
> has some trouble, then I've got no chance.
/You/ are experienced in implementing C. But both you and Jacob suffer
from the same problem here - you are trying to do everything yourself.
Most people understand that they can make mistakes or misunderstanding,
and for something as advanced and complicated as a compiler, it is
usually better to be more than one person. Jacob is a smart guy, but he
is only one person, and only human - mistakes in his tools are not a
surprise.
>
> (BTW why did VLAs become optional from C11?)
I don't know for sure. But I do know that not all C implementations use
a stack, and for some targets a "true VLA" (as distinct from a VLA where
the size is known at compile time) would be extremely inefficient to
implement. It is possible that this has something to do with it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-08 18:02 +0000 |
| Message-ID | <unhdbd$1kf2s$1@dont-email.me> |
| In reply to | #379925 |
On 08/01/2024 15:00, David Brown wrote:
> On 08/01/2024 02:32, Bart wrote:
>> On 07/01/2024 23:51, Keith Thompson wrote:
>>> Bart <bc@freeuk.cm> writes:
>>
>>> Here's a small non-executable example:
>>>
>>> #include <stddef.h>
>>>
>>> size_t foo_size;
>>> size_t bar_size;
>>>
>>> void func(void) {
>>> int n = 42;
>>> typedef int vla[n];
>>> vla foo;
>>> vla bar;
>>
>> This isn't how VLAs are typically used. I think there are three kinds
>> of people when it comes to VLAs:
>>
>> (1) Those who don't know about them and only inadvertently create
>> them because the dimension is a variable not a compiler-time
>> expression
>>
>> (2) Those who know about VLAs, but who will supply the dimensions to
>> the variable declaration
>>
>> (3) A minority who know that VLA dimensions can also be used in
>> typedefs.
>>
>
> I would have thought that a majority of C programmers know that an array
> size can be used in a typedef.
Even that, having a fixed size array as a type, would be unusual, and
typically used for small arrays with special uses, for example:
typedef float vector[4];
typedef float matrix[4][4];
typedef quad byte[4]; // an actual one of mine
I can't even think of a use for such an array to have a size known at
runtime, unless somebody does this:
const int size = 4;
typedef float vector[size];
typedef float matrix[size][size];
(How many even know that you can typedef an actual function, not just a
function pointer:
#include <stdio.h>
typedef int Op(int a, int b);
Op add {return a+b;}
Op sub {return a-b;}
Op mul {return a*b;}
Op div {return a/b;}
int main(void) {
printf("%d\n", add(2, mul(3,4)));
}
Here, most compilers accept that typedef. However only two allow you to
use that typedef in the way shown, to provide a common template for a
function signature: Tiny C, and mine. Those produce a program that
displays 14.)
> An even cleverer compiler usually doesn't need to store the size at all,
> anywhere. A typical real-world implementation of a VLA like "T xs[n]"
> will mean preserving the current stack pointer, then subtracting
> sizeof(T) * n.
That seems simple enough with one VLA in a function, and well structured
flow.
In practice there could be a dozen active VLAs, there could be loops so
that some VLAs are destroyed and recreated as a different size; there
could be gotos in and out of blocks [jump into a VLA scope is an error;
jumping out isn't, but a compiler needs to detect all this], early
returns and so on.
>(Optimising register allocation, stack slot
> usage, variable lifetimes, etc., - /that/ is hard work. Adding an
> another constant variable to the function is not.)
That's also optional; you can make that as complex or simple as you
like. With a VLA the options are fewer.
> (Since you are not trying to make a conforming compiler, you could quite
> reasonably allow such VLA's, treating them identically to normal arrays,
> while disallowing VLA's whose size is not known until compile time.)
Any VLAs I might implement would use heap allocation (but that
introduces other matters of implicit calls to support functions that I
would prefer to keep out of a C implementation).
>> What are the likely values of n? Without VLAs you have to knowingly
>> use large fixed values of n, and/or rely on deep recursion, to get
>> overflow.
>>
>
> This is a myth that is regularly trotted out by people who, for unknown
> reasons, don't like VLAs. They pretend that somehow heap allocation is
> "safer" because malloc will return 0 if an allocation fails, while VLA's
> have no such mechanism. In reality, if you were to write "malloc(n)"
> with no idea what "n" might be, your program is as hopelessly unsound as
> one that writes "int A[n];" with no idea what "n" might be.
Except that the memory that malloc can draw on can be 1000 times larger
than stack memory.
In an earlier example, creating a VLA with int A[SIZE_MAX] didn't fail
(it would only do so if trying to write beyond the stack size), but
malloc(SIZE_MAX) did return NULL.
> Keith wrote "that /you/ know can't be longer than N". The programmer is
> responsible for writing correct code, not the compiler.
Say you write a library function that looks like this:
int F(int n) {
int A[n];
....
or like this:
bool G(char* s) {
int A[strlen(s)];
....
You don't know who or what will call your function; what checks would
you insert?
What should your docs say about the range of n? You'd want the range to
be as high as possible, or to work with as long strings as possible.
At the same time, you want them to be efficient when n or strlen(s) is
small, which may be most of the time; you don't want the extra overheads
of VLAs, and on gcc-Windows, there can be extra overheads.
(My solution to those examples is extra code to either use a small,
fixed-length array, or use the heap, depending on N.)
> /You/ are experienced in implementing C. But both you and Jacob suffer
> from the same problem here - you are trying to do everything yourself.
Above you say that VLAs are simple to implement. Here you suggest it
might be too much for an individual.
Although two persons who don't know how it works won't help! You
probably mean looking for existing solutions and implementations from
somebody who eventually figured it out.
I prefer language features that don't present difficulties. The only
open-ended aspect of compilation I will acknowledge, is back-end
optimisation. And I said that there, you can go as far as you like.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-08 10:39 -0800 |
| Message-ID | <87wmsjpt4k.fsf@nosuchdomain.example.com> |
| In reply to | #379928 |
Bart <bc@freeuk.cm> writes:
[...]
> (How many even know that you can typedef an actual function, not just
> a function pointer:
I know that, and I've used it.
> #include <stdio.h>
>
> typedef int Op(int a, int b);
>
> Op add {return a+b;}
> Op sub {return a-b;}
> Op mul {return a*b;}
> Op div {return a/b;}
>
> int main(void) {
> printf("%d\n", add(2, mul(3,4)));
> }
>
> Here, most compilers accept that typedef.
Most? Are there any that don't? Any conforming C compiler must accept
that typedef.
> However only two allow you
> to use that typedef in the way shown, to provide a common template for
> a function signature: Tiny C, and mine. Those produce a program that
> displays 14.)
Probably because the language doesn't permit using a function typedef in
a function definition. Apparently Tiny C and your compiler provide this
as an extension -- which is fine, as long as they either issue a
diagnostic in conforming mode or don't claim to be fully conforming.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-08 21:36 +0100 |
| Message-ID | <unhmcg$1lqru$1@dont-email.me> |
| In reply to | #379928 |
On 08/01/2024 19:02, Bart wrote:
> On 08/01/2024 15:00, David Brown wrote:
>> On 08/01/2024 02:32, Bart wrote:
>>> On 07/01/2024 23:51, Keith Thompson wrote:
>>>> Bart <bc@freeuk.cm> writes:
>>>
>>>> Here's a small non-executable example:
>>>>
>>>> #include <stddef.h>
>>>>
>>>> size_t foo_size;
>>>> size_t bar_size;
>>>>
>>>> void func(void) {
>>>> int n = 42;
>>>> typedef int vla[n];
>>>> vla foo;
>>>> vla bar;
>>>
>>> This isn't how VLAs are typically used. I think there are three kinds
>>> of people when it comes to VLAs:
>>>
>>> (1) Those who don't know about them and only inadvertently create
>>> them because the dimension is a variable not a compiler-time
>>> expression
>>>
>>> (2) Those who know about VLAs, but who will supply the dimensions to
>>> the variable declaration
>>>
>>> (3) A minority who know that VLA dimensions can also be used in
>>> typedefs.
>>>
>>
>> I would have thought that a majority of C programmers know that an
>> array size can be used in a typedef.
>
>
> Even that, having a fixed size array as a type, would be unusual, and
> typically used for small arrays with special uses, for example:
>
> typedef float vector[4];
> typedef float matrix[4][4];
> typedef quad byte[4]; // an actual one of mine
>
> I can't even think of a use for such an array to have a size known at
> runtime, unless somebody does this:
>
> const int size = 4;
> typedef float vector[size];
> typedef float matrix[size][size];
>
That all seems fine to me - now you have typedefs of VLAs.
> (How many even know that you can typedef an actual function, not just a
> function pointer:
>
> #include <stdio.h>
>
> typedef int Op(int a, int b);
>
> Op add {return a+b;}
> Op sub {return a-b;}
> Op mul {return a*b;}
> Op div {return a/b;}
>
> int main(void) {
> printf("%d\n", add(2, mul(3,4)));
> }
>
> Here, most compilers accept that typedef.
There's nothing wrong with the typedef, and I'd be surprised to see a
compiler that did not accept it even if the compiler did not claim to be
a full C compiler. Some people (such as myself) prefer to typedef
function pointer types, others prefer to typedef function types and
declare pointers to those typedefs. Each is valid, and it is a
stylistic choice.
> However only two allow you to
> use that typedef in the way shown, to provide a common template for a
> function signature: Tiny C, and mine. Those produce a program that
> displays 14.)
Such compilers would be non-compliant - there is nothing in the syntax
and constraints of C that would allow such a syntax. In fact, under
6.9.1 "Function definitions", there is a footnote saying explicitly that
this is wrong :
typedef int F(void);
F f { /* */ } // WRONG: syntax/constraint error
(Again, the typedef is fine - the use of it in a function definition is
not.)
"Op add, sub, mult, div;" as a declaration of the functions is fine.
So whoever wrote those two compilers either failed to do even a basic
reading of fundamental parts of the C standards, or decided
intentionally that this would be a useful extension to add to their
compiler.
>> An even cleverer compiler usually doesn't need to store the size at
>> all, anywhere. A typical real-world implementation of a VLA like "T
>> xs[n]" will mean preserving the current stack pointer, then
>> subtracting sizeof(T) * n.
>
> That seems simple enough with one VLA in a function, and well structured
> flow.
>
The most common case.
> In practice there could be a dozen active VLAs, there could be loops so
> that some VLAs are destroyed and recreated as a different size; there
> could be gotos in and out of blocks [jump into a VLA scope is an error;
> jumping out isn't, but a compiler needs to detect all this], early
> returns and so on.
It all fits in the same way. Complicated structure would hinder
compiler optimisations such as combining stack manipulation. But
there's nothing to stop the compiler treating:
{
...
T xs[n];
...
}
as roughly :
{
...
const sizeof_t n_for_xs = n;
const void * old_sp = SP;
SP -= (n_for_xs * sizeof(T));
T * xs = SP;
...
SP = old_sp;
}
If there are a dozen VLA's (/highly/ unlikely), do this a dozen times.
Everything else, including these new secret variables, works as normal.
I agree that gotos could potentially cause trouble here. Fortunately,
the C standards committee thought so too, and "A goto statement shall
not jump from outside the scope of an identifier having a variably
modified type to inside the scope of that identifier." (6.8.6.1p1).
>
>> (Optimising register allocation, stack slot usage, variable lifetimes,
>> etc., - /that/ is hard work. Adding an another constant variable to
>> the function is not.)
>
> That's also optional; you can make that as complex or simple as you
> like. With a VLA the options are fewer.
>
>> (Since you are not trying to make a conforming compiler, you could
>> quite reasonably allow such VLA's, treating them identically to normal
>> arrays, while disallowing VLA's whose size is not known until compile
>> time.)
>
> Any VLAs I might implement would use heap allocation (but that
> introduces other matters of implicit calls to support functions that I
> would prefer to keep out of a C implementation).
>
Putting VLA's on the heap would be a strange idea that would run
contrary to people's expectations (though I think the standards would
allow it - after all, the C standards don't require a stack at all).
Still, as you are the only user, that's up to you and your own preferences.
>>> What are the likely values of n? Without VLAs you have to knowingly
>>> use large fixed values of n, and/or rely on deep recursion, to get
>>> overflow.
>>>
>>
>> This is a myth that is regularly trotted out by people who, for
>> unknown reasons, don't like VLAs. They pretend that somehow heap
>> allocation is "safer" because malloc will return 0 if an allocation
>> fails, while VLA's have no such mechanism. In reality, if you were to
>> write "malloc(n)" with no idea what "n" might be, your program is as
>> hopelessly unsound as one that writes "int A[n];" with no idea what
>> "n" might be.
>
> Except that the memory that malloc can draw on can be 1000 times larger
> than stack memory.
That means nothing at all. If you have got your "n" from some random
unchecked and unsanitized input, it's madness to use it - a factor of
1000 won't save you.
>
> In an earlier example, creating a VLA with int A[SIZE_MAX] didn't fail
> (it would only do so if trying to write beyond the stack size), but
> malloc(SIZE_MAX) did return NULL.
>
>> Keith wrote "that /you/ know can't be longer than N". The programmer
>> is responsible for writing correct code, not the compiler.
>
> Say you write a library function that looks like this:
>
> int F(int n) {
> int A[n];
> ....
>
Let's say that I would not do so, unless it were appropriate for me to
specify that the function only has defined behaviour for certain ranges
of "n". Then the caller has full responsibility for making sure "n" is
appropriate, and if there is a crash from a bad "n", it is their fault
alone.
> or like this:
>
> bool G(char* s) {
> int A[strlen(s)];
> ....
>
The same applies here. (There's a reason why people often prefer
memchr() to strlen() when the input is not known to be safe.)
>
> You don't know who or what will call your function; what checks would
> you insert?
I specify my functions. It is up to users to use them correctly,
according to the specifications - or the program will have undefined
behaviour. If I suspect that the users might be newbies, or incompetent
programmers, and the functions don't have to be optimally efficient,
then I might put in extra checks to ensure that the parameters are safe
and crash with debug information if not (i.e., I'd use something like an
assert()), if such checks are feasible.
>
> What should your docs say about the range of n? You'd want the range to
> be as high as possible, or to work with as long strings as possible.
Why do you think that? It depends entirely on what the function does.
There is no range of "n" that would be suitable for all situations for a
stack-allocated VLA. Equally, there is no range of "n" that would be
suitable for all situations with heap-allocated data.
>
> At the same time, you want them to be efficient when n or strlen(s) is
> small, which may be most of the time; you don't want the extra overheads
> of VLAs, and on gcc-Windows, there can be extra overheads.
>
> (My solution to those examples is extra code to either use a small,
> fixed-length array, or use the heap, depending on N.)
>
>
>> /You/ are experienced in implementing C. But both you and Jacob
>> suffer from the same problem here - you are trying to do everything
>> yourself.
>
> Above you say that VLAs are simple to implement. Here you suggest it
> might be too much for an individual.
No, I think they should - at least most of the time - be simple to
implement. But there might be odd cases that are challenging, and if
particular individuals find them difficult to understand, then they
should try to discuss ideas with others in order to learn the details.
I also believe quite strongly that people make mistakes sometimes, even
for things that they can, or should, understand.
>
> Although two persons who don't know how it works won't help! You
> probably mean looking for existing solutions and implementations from
> somebody who eventually figured it out.
>
> I prefer language features that don't present difficulties. The only
> open-ended aspect of compilation I will acknowledge, is back-end
> optimisation. And I said that there, you can go as far as you like.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-08 10:32 -0800 |
| Message-ID | <871qarr80o.fsf@nosuchdomain.example.com> |
| In reply to | #379925 |
David Brown <david.brown@hesbynett.no> writes:
> On 08/01/2024 02:32, Bart wrote:
[...]
>> (BTW why did VLAs become optional from C11?)
>
> I don't know for sure. But I do know that not all C implementations
> use a stack, and for some targets a "true VLA" (as distinct from a VLA
> where the size is known at compile time) would be extremely
> inefficient to implement. It is possible that this has something to
> do with it.
I'm skeptical that that's the reason. Almost all C implementations do
use a "stack", in the sense of a contiguously allocated region of memory
in which automatic objects are allocated, with addresses uniformly
increasing or decreasing for new allocations. (All C implementations
use a "stack" in the sense of a last-in/first-out data structure.) I'm
not aware that any implementers of non-stack implementations objected to
VLAs. For that matter, I don't know why VLAs would be extremely
inefficient in such an implementation. They need to have the ability to
allocate new stack frames anyway, and determining the allocation size at
run time shouldn't be a huge burden.
I've seen suggestions that the intent was to make it possible to create
conforming C implementations for small embedded processors. That might
make sense, but it could have been addressed by making VLAs optional
only for freestanding implementations.
I think Microsoft has chosen not to implement VLAs in their C compiler.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-08 21:41 +0100 |
| Message-ID | <unhml7$1lqru$2@dont-email.me> |
| In reply to | #379930 |
On 08/01/2024 19:32, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 08/01/2024 02:32, Bart wrote: > [...] >>> (BTW why did VLAs become optional from C11?) >> >> I don't know for sure. But I do know that not all C implementations >> use a stack, and for some targets a "true VLA" (as distinct from a VLA >> where the size is known at compile time) would be extremely >> inefficient to implement. It is possible that this has something to >> do with it. > > I'm skeptical that that's the reason. Almost all C implementations do > use a "stack", in the sense of a contiguously allocated region of memory > in which automatic objects are allocated, with addresses uniformly > increasing or decreasing for new allocations. (All C implementations > use a "stack" in the sense of a last-in/first-out data structure.) I'm > not aware that any implementers of non-stack implementations objected to > VLAs. For that matter, I don't know why VLAs would be extremely > inefficient in such an implementation. They need to have the ability to > allocate new stack frames anyway, and determining the allocation size at > run time shouldn't be a huge burden. > > I've seen suggestions that the intent was to make it possible to create > conforming C implementations for small embedded processors. That might > make sense, but it could have been addressed by making VLAs optional > only for freestanding implementations. That would have been a little odd, as the differences between freestanding and hosted requirements are almost all a matter of library support. But it is certainly possible. > > I think Microsoft has chosen not to implement VLAs in their C compiler. > This is also entirely possible. The C (and C++) standards have a some absolute piddle as a result of trying to please Microsoft (such as the madness of so many different character types, or Microsoft's attempts at "safe" library functions in C). But as I say, I don't know for sure - your guess is at least as good as mine!
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2024-01-08 08:53 +0000 |
| Message-ID | <slrnupndvo.s7h.ike@iceland.freeshell.org> |
| In reply to | #379918 |
On 2024-01-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> C *does not have* VLAs whose type is "determined at runtime but can
> grow". Logically associating the length of a VLA type with the type
> *works*.
>
> Here's a small non-executable example:
>
> #include <stddef.h>
>
> size_t foo_size;
> size_t bar_size;
>
> void func(void) {
> int n = 42;
> typedef int vla[n];
> vla foo;
> vla bar;
> foo_size = sizeof foo;
> bar_size = sizeof bar;
> }
>
> When I compile it with "gcc -S", I get assembly code that appears to
> store the value 42 just once:
> movl $42, -52(%rbp)
> and retrieves that value from the same place to copy it to foo_size and
> bar_size. (I'm not an expert in x86_64 assembly language, but I'm
> fairly sure that's what's going on.) Please take a look at the
> generated assembly code yourself, using any C compilers you like. Do
> any of them store the sizes of foo and bar separately? Why do you think
> it would be better to do so?
The movl instruction most likely stores 42 in n.
If sizeof (int) > 1, it's unlikely that 42 is copied to foo_size or bar_size,
because (sizeof foo) and (sizeof bar) are (42 * sizeof (int)).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-08 09:59 -0800 |
| Message-ID | <87cyubr9jp.fsf@nosuchdomain.example.com> |
| In reply to | #379922 |
Ike Naar <ike@sdf.org> writes:
> On 2024-01-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> Here's a small non-executable example:
>>
>> #include <stddef.h>
>>
>> size_t foo_size;
>> size_t bar_size;
>>
>> void func(void) {
>> int n = 42;
>> typedef int vla[n];
>> vla foo;
>> vla bar;
>> foo_size = sizeof foo;
>> bar_size = sizeof bar;
>> }
>>
>> When I compile it with "gcc -S", I get assembly code that appears to
>> store the value 42 just once:
>> movl $42, -52(%rbp)
>> and retrieves that value from the same place to copy it to foo_size and
>> bar_size. (I'm not an expert in x86_64 assembly language, but I'm
>> fairly sure that's what's going on.) Please take a look at the
>> generated assembly code yourself, using any C compilers you like. Do
>> any of them store the sizes of foo and bar separately? Why do you think
>> it would be better to do so?
>
> The movl instruction most likely stores 42 in n.
>
> If sizeof (int) > 1, it's unlikely that 42 is copied to foo_size or bar_size,
> because (sizeof foo) and (sizeof bar) are (42 * sizeof (int)).
I believe you're right. I'll investigate further.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-06 12:53 +0000 |
| Message-ID | <unbih3$juqo$1@dont-email.me> |
| In reply to | #379878 |
On 06/01/2024 09:09, David Brown wrote:
> On 05/01/2024 23:19, Bart wrote:
>> On 05/01/2024 14:05, David Brown wrote:
>>> On 05/01/2024 02:53, Bart wrote:
>>
>>>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>>>
>>>
>>> One option for a useful array length operator/function/macro is a
>>> simple and limited feature that works for arrays of known size and
>>> gives a hard (compile-time) error when the size is not known. The
>>> one you have in your own language covers most of that, except for the
>>> insanity of evaluating to 0 when given a pointer/reference to an
>>> "unbounded" array.
>>
>> It gives zero because that is actually the compile-time type of the
>> array. But it is low priority because it is never used that way.
>>
>
> That's the kind of potentially confusing short-cut you can make when
> only you ever use the language.
I spent 10 mins trying to fix this today. So that '.len' on bounds
specified as `[]` rather than `[0]`, and not later set by init data,
would be an error.
Then I got stuck on examples like '[]int a = ()' and realised it's
tricky. And then I thought, why the hell am I doing this? A language
I've already used for a million lines of code.
Because somebody on the internet (who has never created and implemented
a real language AFAIK) told me so?
I don't claim it to be perfect, just that it does a better job than C.
At least it has '.len' and quite a few extra bits to do with fixed-size
arrays:
'M' C
Value arrays Y N
Ptr to array params Y N (also Y but non-idiomatic)
Pass-by-reference Y N
Index a pointer N Y
Deref an array N Y
0-based arrays Y Y
1-based Y N
N-based Y N
Number of bytes X.bytes sizeof(X)
T.bytes sizeof(T)
Array Length X.len sizeof(X)/sizeof(X[0])
T.len ?
Array Lower Bound X.lwb 0
T.lwb 0
Array Upper Bound X.upb sizeof(X)/sizeof(X[0])-1
T.upb ?
Table Indexing A[i,j] A[i][j] or j[A[i]] or j[i[A]]
Loop over bounds For i in A.bounds do
for (int i=0;
i<sizeof(A)/sizeof(A[0]); ++i)
Loop over values For x in A do
For i,x in A do # (both)
for (int i=0;
i<sizeof(A)/sizeof(A[0]); ++i) {
T x = A[i]; ...
Zero array clear A memset(A, 0, sizeof(A)/sizeof(A[0]));
Slices Y N
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-06 14:11 +0000 |
| Message-ID | <unbn37$knul$1@dont-email.me> |
| In reply to | #379880 |
On 06/01/2024 12:53, Bart wrote:
> On 06/01/2024 09:09, David Brown wrote:
>> On 05/01/2024 23:19, Bart wrote:
> At least it has '.len' and quite a few extra bits to do with
fixed-size arrays:
>
> 'M' C
>
> Value arrays Y N
> Ptr to array params Y N (also Y but non-idiomatic)
> Pass-by-reference Y N
>
> Index a pointer N Y
> Deref an array N Y
>
> 0-based arrays Y Y
> 1-based Y N
> N-based Y N
>
> Number of bytes X.bytes sizeof(X)
> T.bytes sizeof(T)
>
> Array Length X.len sizeof(X)/sizeof(X[0])
> T.len ?
>
> Array Lower Bound X.lwb 0
> T.lwb 0
>
> Array Upper Bound X.upb sizeof(X)/sizeof(X[0])-1
> T.upb ?
>
> Table Indexing A[i,j] A[i][j] or j[A[i]] or j[i[A]]
>
> Loop over bounds For i in A.bounds do
> for (int i=0;
i<sizeof(A)/sizeof(A[0]); ++i)
>
> Loop over values For x in A do
> For i,x in A do # (both)
> for (int i=0;
i<sizeof(A)/sizeof(A[0]); ++i) {
> T x = A[i]; ...
>
> Zero array clear A memset(A, 0, sizeof(A)/sizeof(A[0]));
The C is wrong; it should be just sizeof(A).
You can see how sizeof or sizeof/sizeof features quite a bit in the
right-hand column, but even the shorter .len is little seen on the left.
It's easy to get it wrong or nor immediately notice (unless your
initials are SL of course).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-06 15:28 +0100 |
| Message-ID | <unbo34$koa8$2@dont-email.me> |
| In reply to | #379880 |
On 06/01/2024 13:53, Bart wrote: > On 06/01/2024 09:09, David Brown wrote: >> On 05/01/2024 23:19, Bart wrote: >>> On 05/01/2024 14:05, David Brown wrote: >>>> On 05/01/2024 02:53, Bart wrote: >>> >>>>> It doesn't need to take a heavy-handed approach like C++ or Python. >>>>> >>>> >>>> One option for a useful array length operator/function/macro is a >>>> simple and limited feature that works for arrays of known size and >>>> gives a hard (compile-time) error when the size is not known. The >>>> one you have in your own language covers most of that, except for >>>> the insanity of evaluating to 0 when given a pointer/reference to an >>>> "unbounded" array. >>> >>> It gives zero because that is actually the compile-time type of the >>> array. But it is low priority because it is never used that way. >>> >> >> That's the kind of potentially confusing short-cut you can make when >> only you ever use the language. > > I spent 10 mins trying to fix this today. So that '.len' on bounds > specified as `[]` rather than `[0]`, and not later set by init data, > would be an error. > > Then I got stuck on examples like '[]int a = ()' and realised it's > tricky. And then I thought, why the hell am I doing this? A language > I've already used for a million lines of code. > I have no idea why you are doing this. I have no idea why you thought it was a good idea to make your own personal language and write a million lines that no one can ever use again, or work with, change, re-use, maintain or update. I have no idea why you hate C, why you obsess about a language you hate and why you rave about your language that no one else uses and no one else cares about in a newsgroup for C. I have no idea why you continue to think that your language is God's gift to programming and that everyone else, the world over, is crazy to imagine there are any reasons to do something differently from the way you do things in your language. Yes, "why?" is a good question.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-01-06 09:56 -0500 |
| Message-ID | <unbpm5$2bpou$2@i2pn2.org> |
| In reply to | #379883 |
On 1/6/24 9:28 AM, David Brown wrote: > > I have no idea why you are doing this. I have no idea why you thought > it was a good idea to make your own personal language and write a > million lines that no one can ever use again, or work with, change, > re-use, maintain or update. I have no idea why you hate C, why you > obsess about a language you hate and why you rave about your language > that no one else uses and no one else cares about in a newsgroup for C. > I have no idea why you continue to think that your language is God's > gift to programming and that everyone else, the world over, is crazy to > imagine there are any reasons to do something differently from the way > you do things in your language. > > Yes, "why?" is a good question. > I think the big reason for his "Why?" is that he KNOWS that his language isn't sufficient, but will need to interface to things that others have done, and those will invariably be written in C. His complaint is that while C has become the common-tounge for inter-language linkage, it really isn't designed for that. The "shims" to perform this tend to need some part of it to be written in C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-06 15:57 +0000 |
| Message-ID | <unbt8c$lnoa$1@dont-email.me> |
| In reply to | #379884 |
On 06/01/2024 14:56, Richard Damon wrote: > On 1/6/24 9:28 AM, David Brown wrote: >> >> I have no idea why you are doing this. I have no idea why you thought >> it was a good idea to make your own personal language and write a >> million lines that no one can ever use again, or work with, change, >> re-use, maintain or update. I have no idea why you hate C, why you >> obsess about a language you hate and why you rave about your language >> that no one else uses and no one else cares about in a newsgroup for >> C. I have no idea why you continue to think that your language is >> God's gift to programming and that everyone else, the world over, is >> crazy to imagine there are any reasons to do something differently >> from the way you do things in your language. >> >> Yes, "why?" is a good question. >> > > I think the big reason for his "Why?" is that he KNOWS that his language > isn't sufficient, but will need to interface to things that others have > done, I used it for at least 10 years without needing to interface to anything. After that I needed to use OS and other libraries. and those will invariably be written in C. > > His complaint is that while C has become the common-tounge for > inter-language linkage, it really isn't designed for that. The inter-language ABI is based on sets of MACHINE types such: u8-u64, i8-i64, f32-f64, plus pointers and aggregate types. Those are common to many languages, not just C, which tend to have far more sensible and stable ways to denote such types. That is what my FFIs use too. At this point C doesn't enter into it. But it is true that many APIs (not ABIs) are defined in C terms or as C headers. And in the latter, yes C's types could be better. And often, some other aspects of C such as macros, which can include arbitrary C code, can be exposed.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-06 23:58 +0000 |
| Message-ID | <uncpea$pmqq$4@dont-email.me> |
| In reply to | #379886 |
On Sat, 6 Jan 2024 15:57:00 +0000, Bart wrote:
> But it is true that many APIs (not ABIs) are defined in C terms or as C
> headers.
I wish they would be more consistent about that. It has been about a
quarter century since C99 introduced stdbool, yet you still see rigmarole
like (from /usr/include/SDL2/SDL_egl.h):
typedef enum {
KHRONOS_FALSE = 0,
KHRONOS_TRUE = 1,
KHRONOS_BOOLEAN_ENUM_FORCE_SIZE = KHRONOS_MAX_ENUM
} khronos_boolean_enum_t;
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-06 23:45 +0000 |
| Message-ID | <uncon1$pmqq$3@dont-email.me> |
| In reply to | #379884 |
On Sat, 6 Jan 2024 09:56:05 -0500, Richard Damon wrote: > His complaint is that while C has become the common-tounge for > inter-language linkage, it really isn't designed for that. > > The "shims" to perform this tend to need some part of it to be written > in C. There is a thing called libffi, which is commonly used by many high-level languages to interface to C code (or to code that assumes that it is being called from C code). This is the basis of the ctypes module in the standard Python library, for example. I have successfully used ctypes to produce “Pythonic” wrappers for several useful facilities (e.g. Cairo graphics, D-Bus, inotify). By “Pythonic” I mean that they try to look as though the underlying facility was designed to be used from Python.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-07 00:21 +0000 |
| Message-ID | <uncqpa$pvae$2@dont-email.me> |
| In reply to | #379888 |
On 06/01/2024 23:45, Lawrence D'Oliveiro wrote: > On Sat, 6 Jan 2024 09:56:05 -0500, Richard Damon wrote: > >> His complaint is that while C has become the common-tounge for >> inter-language linkage, it really isn't designed for that. >> >> The "shims" to perform this tend to need some part of it to be written >> in C. > > There is a thing called libffi, which is commonly used by many high-level > languages to interface to C code (or to code that assumes that it is being > called from C code). This is the basis of the ctypes module in the > standard Python library, for example. > > I have successfully used ctypes to produce “Pythonic” wrappers for several > useful facilities (e.g. Cairo graphics, D-Bus, inotify). By “Pythonic” I > mean that they try to look as though the underlying facility was designed > to be used from Python. LIBFFI solves a different problem, which is that of synthesising function calls at runtime, given a function name as a string, and a sequence of N arguments as assorted types. Typically used in interpreted code. Native code calling native code across languages generally doesn't need that. It needs that information about the 1000s of different functions, types, and enums that are used in an API, in a set of bindings suitable for use in the calling language. LIBFFI doesn't help here; you still need that info whether making a statically compiled call or a dynamically synthesised one. (When you do need something like LIBFFI, then it is another of those hard-to-build C libraries. I generally don't bother with it. I use a 60-line solution of my own which cheats by using inline assembly. A lot less hassle, but it is specific to each target.)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-07 00:55 +0000 |
| Message-ID | <uncspv$q65q$3@dont-email.me> |
| In reply to | #379892 |
On Sun, 7 Jan 2024 00:21:00 +0000, Bart wrote:
> (When you do need something like LIBFFI, then it is another of those
> hard-to-build C libraries.
sudo apt-get install libffi-dev
does it for me.
If you want to learn how to build things from source, maybe look at how a
source-based distro like Gentoo does it? They provide scripts to do
automatically what you struggle to manage with your human brain. Maybe too
much exposure to Microsoft Windows?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-07 01:26 +0000 |
| Message-ID | <uncuk6$qft8$1@dont-email.me> |
| In reply to | #379894 |
On 07/01/2024 00:55, Lawrence D'Oliveiro wrote:
> On Sun, 7 Jan 2024 00:21:00 +0000, Bart wrote:
>
>> (When you do need something like LIBFFI, then it is another of those
>> hard-to-build C libraries.
>
> sudo apt-get install libffi-dev
>
> does it for me.
And then what? LIBFFI is still hard to use.
Bear in mind I would need to call LIBFFI itself across an FFI. Even if
it worked beautifully, it's a horrible dependency with the usual ghastly
build methods that require either Linux or MSVC, from what I can see.
Why, for a specific platform, can I not just get one .c and/or
one .s file to do the job?
Unlike the algorithms behind GMP, this is a task I do understand!
Below is the 60-line solution I mentioned. The function has already been
located so that a reference to it is passed.
(There is also a HLL-only version, including one in C, but it has many
restrictions.)
> If you want to learn how to build things from source, maybe look at how a
> source-based distro like Gentoo does it?
> They provide scripts to do
> automatically what you struggle to manage with your human brain. Maybe too
> much exposure to Microsoft Windows?
I can build ALL my projects using an invocation like:
mm prog
Most build in 1/10th of a second. I'm struggling to see how it can get
any simpler or faster!
This is what I do. I tried to do it with my C compiler, but the language
puts some difficulties there, so that might be more like:
mcc @prog
Still only a compiler and the source files plus this auxiliary file.
--------------------------------------
--------------------------------------
Core of 'libffi' solution for x64/Win64ABI
Not in C code.
--------------------------------------
export func os_calldllfunction(
ref proc fnaddr,
int retcode, nargs,
ref[]i64 args,
ref[]byte argcodes)u64 =
u64 a
r64 x
int nextra, pushedbytes
nextra:=0
!The stack is 16-byte aligned at this point
if nargs<4 then
nextra:=4-nargs !need at least 4 slots for shadow space
elsif nargs.odd then !need one more for a 16-byte-aligned stack
nextra:=1
fi
pushedbytes:=(nextra+nargs)*8
to nextra do
asm push 0
od
for i:=nargs downto 1 do
a:=args[i] !get generic 64-bit value to push
asm push u64 [a]
od
!blindly load first 4 args (incl unused) to both int/float regs
!(both must be loaded when calling variadic functions)
assem
mov D10,[Dstack]
movq XMM0,[Dstack]
mov D11,[Dstack+8]
movq XMM1,[Dstack+8]
mov D12,[Dstack+16]
movq XMM2,[Dstack+16]
mov D13,[Dstack+24]
movq XMM3,[Dstack+24]
end
if retcode='I' then
a:=((ref func:i64(fnaddr))^())
asm add Dstack, [pushedbytes]
return a
else
x:=((ref func:r64(fnaddr))^())
asm add Dstack, [pushedbytes]
return u64@(x) ! (type-punning cast)
fi
end
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-07 02:14 +0000 |
| Message-ID | <und1eh$qmhu$3@dont-email.me> |
| In reply to | #379899 |
On Sun, 7 Jan 2024 01:26:29 +0000, Bart wrote: > And then what? LIBFFI is still hard to use. Using Python’s ctypes module, which is basically built on top of libffi, I have not found to be that hard at all. Looking at the sizes of those particular Python wrappers I mentioned: Cairo graphics <https://gitlab.com/ldo/qahirah> -- 8500 lines D-bus <https://gitlab.com/ldo/dbussy/> -- 11,000 lines inotify <https://gitlab.com/ldo/inotipy> -- under 600 lines
[toc] | [prev] | [next] | [standalone]
Page 28 of 34 — ← Prev page 1 … 26 27 [28] 29 30 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web