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 31 of 34 — ← Prev page 1 … 29 30 [31] 32 33 34 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-12-29 11:58 -0500 |
| Message-ID | <ummtra$1a0q5$13@i2pn2.org> |
| In reply to | #379670 |
On 12/29/23 8:31 AM, Bart wrote: > On 29/12/2023 02:35, Lawrence D'Oliveiro wrote: > > On Tue, 26 Dec 2023 16:59:40 +0100, Janis Papanagnou wrote: > > > >> But as got obvious *that* way there had been side-effects and I had to > >> put the tag at the beginning of all include files (which astonished me) > > > > It has always been thus > > <https://manpages.debian.org/7/feature_test_macros.en.html>: > > > > NOTE: In order to be effective, a feature test macro must be > defined > > before including any header files. > > > >> Last time I looked into the system header files, three decades ago, I > >> got repelled by all the #ifdef's, cascaded and nested, a spaghetti code > >> of dependencies; I'm astonished it works. > > > > The whole concept of include files and string-based macro processing is > > flawed. But that’s C for you ... > > It's not just C's fault. It's the insistence of having have just ONE > system header that has to work for as many platforms and versions as > possible. > > Then that is just added to over the years to include to result in the > patched-together mess that you see that is utterly unreadable. You can't > simplify it it take things out because something could break. It is > fragile. > > Why not have a dedicated header file that is the specific to a > particular version of a C compiler for a given platform? That it can be > streamlined for that purpose. > > If someone is maintaining compilers that need to work across a range of > targets, then they can have a process that synthesises the header needed > for a specific configuration. > > (I guess this is something that is harder on Linux because there, many > standard headers are not part of a specific C compiler, but are a > resource shared by all C compilers, or tools that need to process C > headers.) > > And using #if in the headers is one way to "have a process" that "synthesises the header needed for a specific configuration", without needing some special code in the compiler, and still makes the header available to the user for inspection. I suppose the alternative is a separate include hierarchy for EVERY combination of configurations, and needing to modify multiple headers to add/fix features.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2023-12-29 17:44 +0000 |
| Message-ID | <20231229093047.636@kylheku.com> |
| In reply to | #379670 |
On 2023-12-29, Bart <bc@freeuk.cm> wrote: > On 29/12/2023 02:35, Lawrence D'Oliveiro wrote: > > On Tue, 26 Dec 2023 16:59:40 +0100, Janis Papanagnou wrote: > > > >> But as got obvious *that* way there had been side-effects and I had to > >> put the tag at the beginning of all include files (which astonished me) > > > > It has always been thus > > <https://manpages.debian.org/7/feature_test_macros.en.html>: > > > > NOTE: In order to be effective, a feature test macro must be defined > > before including any header files. > > > >> Last time I looked into the system header files, three decades ago, I > >> got repelled by all the #ifdef's, cascaded and nested, a spaghetti code > >> of dependencies; I'm astonished it works. > > > > The whole concept of include files and string-based macro processing is > > flawed. But that’s C for you ... > > It's not just C's fault. It's the insistence of having have just ONE > system header that has to work for as many platforms and versions as > possible. Umm, no; system headers are largely system-specific. > > Then that is just added to over the years to include to result in the > patched-together mess that you see that is utterly unreadable. You can't > simplify it it take things out because something could break. It is fragile. The preprocessing selection in system headers is for the different expectations of programs which target different versions of the system interfaces. It is to prevent clashes. If an identifier like usleep is hidden, it means that the program can use it without triggering a redefinition or other error. When you compile with, say, -std=c99 (and no other feature selection) and include <stdio.h>, that header must not declare fdopen or fileno, which are POSIX extensions. That matters if your program happens to use these identifiers: which an ISO C program is entitled to do. > Why not have a dedicated header file that is the specific to a > particular version of a C compiler for a given platform? That it can be > streamlined for that purpose. That's predominantly the case, other than (obviously) for libraries that are intended to be widely portable. > > If someone is maintaining compilers that need to work across a range of > targets, then they can have a process that synthesises the header needed > for a specific configuration. In fact, I remember from long ago that GCC used to have a script, as part of its build, that would scan the platform's native headers and generate sanitized versions for GCC. Not sure if that is the case any more. > (I guess this is something that is harder on Linux because there, many > standard headers are not part of a specific C compiler, but are a > resource shared by all C compilers, or tools that need to process C > headers.) Headers on GNU/Linux systems tend to assume GCC. Clang would not be usable did it not have GCC compatibility. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-12-29 10:54 -0800 |
| Message-ID | <87jzowvnyk.fsf@nosuchdomain.example.com> |
| In reply to | #379677 |
Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2023-12-29, Bart <bc@freeuk.cm> wrote:
[...]
>> (I guess this is something that is harder on Linux because there, many
>> standard headers are not part of a specific C compiler, but are a
>> resource shared by all C compilers, or tools that need to process C
>> headers.)
>
> Headers on GNU/Linux systems tend to assume GCC. Clang would not be
> usable did it not have GCC compatibility.
On my Ubuntu 22.04 system, tcc manages to use the system headers, which
are mostly provided by glibc. In a quick glance at /usr/include/stdio.h,
I see some #ifdefs for symbols like __GNUC__ (which is predefined by gcc
and clang but not by tcc) and __USE_GNU (I haven't bothered to look into
how that's defined).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2023-12-29 20:19 +0000 |
| Message-ID | <20231229121856.939@kylheku.com> |
| In reply to | #379681 |
On 2023-12-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Kaz Kylheku <433-929-6894@kylheku.com> writes: >> On 2023-12-29, Bart <bc@freeuk.cm> wrote: > [...] >>> (I guess this is something that is harder on Linux because there, many >>> standard headers are not part of a specific C compiler, but are a >>> resource shared by all C compilers, or tools that need to process C >>> headers.) >> >> Headers on GNU/Linux systems tend to assume GCC. Clang would not be >> usable did it not have GCC compatibility. > > On my Ubuntu 22.04 system, tcc manages to use the system headers, which > are mostly provided by glibc. In a quick glance at /usr/include/stdio.h, > I see some #ifdefs for symbols like __GNUC__ (which is predefined by gcc > and clang but not by tcc) and __USE_GNU (I haven't bothered to look into > how that's defined). __GNUC__ would be a definite ever-present signal from the compiler. __USE_GNU is the internal feature selector corresponding to when you use the externally documented _GNU_SOURCE. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2023-12-30 06:51 +0000 |
| Message-ID | <pan$750c8$285261e$b7c42f65$7a0431b1@invalid.invalid> |
| In reply to | #379670 |
Bart wrote: > Why not have a dedicated header file that is the specific to a > particular version of a C compiler for a given platform? That it can be > streamlined for that purpose. In fact, this is similar to exactly what Plan 9 did: for include files that had arch-dependent content, it'd have a separate version of them for each arch, with an arch's versions of headers like these all stored in their own directory. -- Blue-Maned_Hawkâshortens to Hawkâ/blu.mÉin.dÊ°ak/âhe/him/ his/himself/Mr. blue-maned_hawk.srht.site Of course, further simplicifications would be possible by killing off all but one or two arches.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2023-12-30 16:16 -0600 |
| Message-ID | <umq4ra$1dt87$1@dont-email.me> |
| In reply to | #379689 |
On 12/30/2023 12:51 AM, Blue-Maned_Hawk wrote:
> Bart wrote:
>
>> Why not have a dedicated header file that is the specific to a
>> particular version of a C compiler for a given platform? That it can be
>> streamlined for that purpose.
>
> In fact, this is similar to exactly what Plan 9 did: for include files
> that had arch-dependent content, it'd have a separate version of them for
> each arch, with an arch's versions of headers like these all stored in
> their own directory.
>
Yeah, we don't actually need big monolithic C libraries, nor big
monolithic C compilers, ...
Many people's assumption, that one needs "one true C compiler" (with
people debating GCC cs Clang, mostly ignoring any other possibilities)
and then using the same C library, etc, everywhere, may potentially
actually be doing the world a disservice.
Though, it seems like a different kind of strategy could be possible:
Split compilers into frontends and backends (which may exist as
semi-independent projects).
Frontend deals with source languages, compiles down to a common IR (with
the IR taking the place of object files);
Backend compiles this to the actual machine code, and does any linking,
before emitting the actual binary.
Possibly, separate frontends and backends could exist, merely agreeing
on a common IR.
The frontend could be more target neutral, trying to reduce
target-specific features mostly to "general parameters" (realistically,
a C frontend will still need to know things like the sizes of various
types, various other major architectural features, etc...). But, mostly,
it will care about input languages.
Though, in my compiler I had added an extension for an "__ifarch()" feature:
__ifarch(feature) some_decl
Where, used like an attribute, the declaration is only enabled (in the
backend) if the corresponding feature is present (though the features
may be combined using logical expressions, so "!feature",
"feature1&&!feature2", ...).
But also for blocks of code:
__ifarch(feature)
{
// only emitted if feature is present.
...
}
But, unlike "#ifdef", all the code needs to be syntactically valid, etc.
Partly, this is because the front-end still needs to be able to compile it.
The backend will care about target machine, but should not need to care
(too much) about the language, though will likely need to care about
some things outside the scope of plain C (such as namespaces, objects,
and exceptions, ...), mostly to be able to deal effectively with "OO
languages" and similar (though, I have noted that some simplifications
are possible relative to something like C++, where it is possible in
premise to mimic C++ style multiple inheritance on top of a
single-inheritance object model by treating MI classes as aggregates, ...).
In my experience, the "generally least bad" option for an IR seems to be
for a stack-machine like model (similar to JVM or .NET).
While a backend will most likely operate in terms of a TAC or SSA like form:
RPN -> TAC or SSA is fairly easy.
TAC -> SSA is more involved;
Using SSA directly exposes piles of hair across the interface.
For similar reasons to not work with raw SSA, it also seems like "not a
good thing" to expose bare ASTs (an AST will expose a whole lot of
design choices and tradeoffs within the frontend; while also being
"comparably expensive" in terms of the memory needed to work with them).
Though, one can note that RPN does need around 40-60% more operations
than TAC or SSA, but in practice, this seems to not be too big of an
issue (most of these extra stack operations "magically disappear" if one
treats the stack more as a holding space for variable IDs, than as an
"actual location that stores stuff").
Note that the use of the stack will be fairly constrained in such an IR
to use this model (unlike Forth, it is not free-form relative to control
flow). However, given the existing VMs also impose similar constraints,
it seems likely they also work in this way.
Some major tradeoffs within a stack IR:
Explicit types in opcodes (like JVM) or implicit (like .NET);
Explicit is better for a naive interpreter;
Implicit makes more sense for a compiler or JIT.
Though, better here is to leave type-promotions to the frontend.
Whether to fuse variable stores, etc, into the ops.
LOAD x; LOAD #1; ADD; STORE y
Vs:
LOAD x; LOAD #1; ADD_ST y
...
Well, along with tradeoffs for how to package the bytecode within a
file, and how to best express the various metadata (such as "a few big
tables holding everything", like in JVM, or splitting stuff into a large
number of interconnected tables like in .NET, ...).
For my compiler, it was:
Stack based IR, implicit types, with variable store merged with various ops;
Packaging was a big linear blob of bytecode (with metadata itself
expressed in the bytecode), but better likely would have been to use a
more structured TLV-style format and/or a WAD-file variant;
Metadata was split into two major tables:
One held everything that was a global variable of function declaration
or similar;
The other table held anything that was more like a value or type
declaration (so, structs/unions/classes/etc, value lists for initialized
arrays, etc).
In my case, sort of like PostScript, there is an explicit MARK operator
for function calls, eg:
dst=foo(args...);
Becomes:
MARK; args...; CALL foo; STORE dst;
...
For C library, there can be per platform libraries, or possibly ones
with a partial split between "generic C library stuff" and "stuff that
needs to be platform specific" (based on OS, target architecture, ...).
But, this is likely its own topic...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2023-12-30 23:21 +0000 |
| Message-ID | <umq8lh$1eaq0$2@dont-email.me> |
| In reply to | #379691 |
On Sat, 30 Dec 2023 16:16:07 -0600, BGB wrote: > Many people's assumption, that one needs "one true C compiler" (with > people debating GCC cs Clang, mostly ignoring any other possibilities) > and then using the same C library, etc, everywhere, may potentially > actually be doing the world a disservice. Actually, we have quite a choice of C libraries, even on the same Linux platform. I once used one of them (I think it was musl) just to prove I could build a small executable† that would run in just 20kB of RAM on a modern 64-bit Linux machine. †It did nothing more than take an integer command-line argument and sleep for that number of seconds. That way the process would hang around long enough for me to confirm how much/little RAM it was using.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2023-12-30 19:14 -0600 |
| Message-ID | <umqfag$1f4km$1@dont-email.me> |
| In reply to | #379692 |
On 12/30/2023 5:21 PM, Lawrence D'Oliveiro wrote: > On Sat, 30 Dec 2023 16:16:07 -0600, BGB wrote: > >> Many people's assumption, that one needs "one true C compiler" (with >> people debating GCC cs Clang, mostly ignoring any other possibilities) >> and then using the same C library, etc, everywhere, may potentially >> actually be doing the world a disservice. > > Actually, we have quite a choice of C libraries, even on the same Linux > platform. I once used one of them (I think it was musl) just to prove I > could build a small executable† that would run in just 20kB of RAM on a > modern 64-bit Linux machine. > > †It did nothing more than take an integer command-line argument and sleep > for that number of seconds. That way the process would hang around long > enough for me to confirm how much/little RAM it was using. On Linux, I think yeah, glibc, newlib, and musl, are the main options. Seemingly, a majority of stuff assumes glibc though. With main popular compilers being GCC and LLVM/Clang. There also exist variants of, say: lcc, tcc, pcc, etc... They exist, but most people seem to ignore them... For my custom hobby OS + CPU ISA, I am using: BGBCC, full custom C compiler, though it is mostly based on code that has been beating around in my projects for the past 20 years or so (originally starting as a fork off an early version of an interpreter I had written for a JavaScript-like language). The main alternatives at the time were: Modify GCC to support my designs, which looked like a massive pain; LLVM, which even trying to recompile it one-off "totally owned" my PC at the time; LCC, which looked possible, but didn't offer much obvious advantage over the code I already had laying around; ... With the C library being a heavily modified version of PDPCLIB that had also grown a lot of OS style appendages (the OS kernel, C library, and shell, are all sort of a conjoined mess that probably needs some amount of redesign). Did eventually get around to make it so that at least, normal user-mode binaries will omit much of the kernel related code from the binary (though, does mean these binaries can no longer be launched "bare metal"). Had started trying to write a new C library at one point, but effort on this kinda fizzled. Internal architecture gets a little weird, with various parts of the runtime libraries and OS interfacing via structures resembling COM objects (with a C like API wrapping the internal COM style interfaces). Along with some funkiness like using COM style interfaces to call services running inside different tasks. Ironically, the system call mechanism could itself almost be a COM object, apart from the fact that it was instead implemented as a "magic function pointer" (which can be used to perform some system calls directly, and to fetch objects for some other OS API interfaces). Though, it is not exactly the same: There is no IDL tool; There is more variability in terms of method signatures and naming; Interfaces are generally identified as pairs of FOURCC or EIGHTCC values rather than GUIDs, but there is the idea that the EIGHTCC pair could easily be used for a GUID as well (though, likely limiting GUIDs to "private interfaces", with FOURCC/EIGHTCC making more sense for OS provided APIs and services). Part of this was in-turn because providing inter-task interfaces via a "GetProcAddress" style mechanism would have resulted in considerably higher overheads (an full object has roughly the same overhead, but can provide a bunch of different functions all at the same time). The handling for DLL's and the C library is kind of backwards compared with the strategy Windows uses: Windows: Each binary/DLL has a C library linked in, which calls back to shared DLLs for the OS API. My case: Main EXE has a statically-linked C library, which provides an interface that the DLLs can use; Each DLL has a stripped down C library, which uses (yet another) COM-style interface to call back into the C library provided by the main binary (which may then redirect calls across the system-call interface or similar). It was done this way mostly for "technical reasons" (partly because, among the available options, this did not preclude bare metal programs or the kernel from being able to use DLLs). Note that (unlike ELF on Linux), it is not currently possible to directly share global variables across DLL boundaries. Though, the effect this would have on the C library are reduced as stdin/stdout/errno/etc were already implemented as macros wrapping calls to getter functions. Eg: errno_t *__get_errno(); #define errno (*(__get_errno())) ... All still kind of a mess though... Similarly, my compiler can at least sort of mimic the POSIX style command-line interface (though was written originally with a more MSVC-like CLI); But, still falls short of being able to satisfy "./configure" and similar that it is a valid cross compiler. Then again, not like there is much hope of getting stuff ported when in general, nearly all of the Linux software seems to take a "you need the whole jungle to get a single banana" approach to software dependencies (and then much of the code tends to be riddled with GCC'isms). Often almost easier to port DOS era or older Unix-era code (it is still not usually going to work "out of the box" but at least tends to be more straightforward for how one is to go about porting it). Well, at least excluding some "obviously nasty" code... ...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2023-12-31 01:34 +0000 |
| Message-ID | <umqgf3$1f5qb$1@dont-email.me> |
| In reply to | #379693 |
On Sat, 30 Dec 2023 19:14:55 -0600, BGB wrote: > Note that (unlike ELF on Linux), it is not currently possible to > directly share global variables across DLL boundaries. Windows is broken in so many ways ... when you achieve something, it’s like getting a bear to dance: it’s not that it dances badly, but that it dances at all.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2023-12-31 02:18 +0000 |
| Message-ID | <umqj1h$1fg32$1@dont-email.me> |
| In reply to | #379694 |
On 31/12/2023 01:34, Lawrence D'Oliveiro wrote: > On Sat, 30 Dec 2023 19:14:55 -0600, BGB wrote: > >> Note that (unlike ELF on Linux), it is not currently possible to >> directly share global variables across DLL boundaries. > > Windows is broken in so many ways ... when you achieve something, it’s > like getting a bear to dance: it’s not that it dances badly, but that it > dances at all. I think that that limitation was specific to BGB's handling of DLLs; it was not made clear. If it is an actual issue on Windows, then someone would first have to explain what it means, and why it happens, as I can't see it. Each DLL exports certain symbols such as the addresses of functions and variables. So no reason you can't access a variable exported from any DLL, unless perhaps multiple instances of the same DLL have to share the same static data, but that sounds very unlikely, as little would work. >Windows is broken in so many ways Other examples? I find rather the opposite. For example I did like this remark of BGB's: >Then again, not like there is much hope of getting stuff ported when in general, nearly all of the Linux software seems to take a "you need the whole jungle to get a single banana" approach to software dependencies (and then much of the code tends to be riddled with GCC'isms) This somes my experience of software originating in Linux. This is why Windows had to acquire CYGWIN then MSYS then WSL. You can't build the simplest program without involving half of Linux.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2023-12-30 23:46 -0600 |
| Message-ID | <umqv72$1kutd$1@dont-email.me> |
| In reply to | #379697 |
On 12/30/2023 8:18 PM, Bart wrote:
> On 31/12/2023 01:34, Lawrence D'Oliveiro wrote:
>> On Sat, 30 Dec 2023 19:14:55 -0600, BGB wrote:
>>
>>> Note that (unlike ELF on Linux), it is not currently possible to
>>> directly share global variables across DLL boundaries.
>>
>> Windows is broken in so many ways ... when you achieve something, it’s
>> like getting a bear to dance: it’s not that it dances badly, but that it
>> dances at all.
> I think that that limitation was specific to BGB's handling of DLLs; it
> was not made clear.
>
Yes.
In my case (for my custom target) I am using a modified version of
PE/COFF (with some tweaks, *), but it has the issue that there is not
currently (any) mechanism for sharing variables across DLL boundaries
apart from getter/setter functions or similar.
*1: Major differences from Windows' PE/COFF:
Removing the MZ header
File typically starts directly at the 'PE' magic;
For my uses, the MZ stub/header was entirely useless.
The loaders will still handle it if encountered;
But, having MZ also disables some of the other format tweaks.
Adding LZ4 compression
'PEL4' magic: Everything past the first 1K is LZ4 compressed.
This is an optional extension, mostly to help with loader speed.
The loader is mostly IO bound, and LZ4 can make loading faster.
The resource section was replaced with a modified WAD2 variant.
Albeit, with different headers, and offsets encoded in RVA space.
The original format seemed needlessly complicated and awkward.
IOW: Based on the format used for textures in Quake and Half-Life.
I also went over to a different checksum algorithm and similar.
The original algorithm was very weak against some types of errors.
...
However, much of its structure still has more in common with PE/COFF
than some of the other COFF variants (such as ECOFF and XCOFF).
Note, original algorithm was something like (from memory):
u32 PE_Checksum(void *buf, int sz)
{
uint16_t *cs, *cse;
uint32_t sum;
cs=buf; cse=cs+(sz>>1); sum=0;
while(cs<cse)
{ sum+=*cs++; }
sum=((uint16_t)sum)+(sum>>16);
sum=((uint16_t)sum)+(sum>>16);
return(sum);
}
Had replaced it with:
uint32_t TKPE_CalculateImagePel4BChecksum(byte *buf, int size)
{
byte *cs, *cse;
uint32_t v, v0, v1, v2, v3;
uint64_t acc_lo, acc_hi;
uint32_t csum;
cs=buf; cse=cs+size;
acc_lo=1; acc_hi=0;
while(cs<cse)
{
v0=((uint32_t *)cs)[0]; v1=((uint32_t *)cs)[1];
v2=((uint32_t *)cs)[2]; v3=((uint32_t *)cs)[3];
acc_lo=acc_lo+v0; acc_hi=acc_hi+acc_lo;
acc_lo=acc_lo+v1; acc_hi=acc_hi+acc_lo;
acc_lo=acc_lo+v2; acc_hi=acc_hi+acc_lo;
acc_lo=acc_lo+v3; acc_hi=acc_hi+acc_lo;
cs+=16;
}
acc_lo=((uint32_t )acc_lo)+(acc_lo>>32);
acc_lo=((uint32_t )acc_lo)+(acc_lo>>32);
acc_hi=((uint32_t )acc_hi)+(acc_hi>>32);
acc_hi=((uint32_t )acc_hi)+(acc_hi>>32);
csum=(uint32_t )(acc_lo^acc_hi);
return(csum);
}
Where in this case, my ISA has enough registers that is is generally
faster to do the accumulation 4-wide than 1-wide.
The use of checksums in this case mostly to verify that the program has
been loaded intact and the binary is not corrupt.
> If it is an actual issue on Windows, then someone would first have to
> explain what it means, and why it happens, as I can't see it.
>
> Each DLL exports certain symbols such as the addresses of functions and
> variables. So no reason you can't access a variable exported from any
> DLL, unless perhaps multiple instances of the same DLL have to share the
> same static data, but that sounds very unlikely, as little would work.
>
Much past roughly Win9x or so, it has been possible to use
"__declspec(dllimport)" on global variables in Windows (in an earlier
era, it was not possible to use the __declspec's, but instead necessary
to manage DLL import/exports by writing out lists in ".DEF" files).
It isn't entirely transparent, but yes, on actual Windows, it is very
much possible to share global variables across DLL boundaries.
Just, this feature is not (yet) supported by my compiler. Personally, I
don't see this as a huge loss (even if it did work; I personally see it
as "poor coding practice").
But, otherwise, I am using the newer __declspec dllimport/dllexport
syntax; and technically using exclusively import/export by name (the use
of ordinal numbers is not supported either by my compiler or PE loader).
But, yeah, making shared global variables work is on the "eventual TODO"
list, just not an immediate priority.
Note that, like with the MS tools, unless a function is marked as
dllexport, its visibility is purely local to a given EXE or DLL.
This differs slightly from Cygwin, which seems to use an "export
everything" (and implicitly import everything) strategy, likely in an
attempt to mimic ELF behavior.
Though, there are some differences:
In ELF based systems, it is possible to leave symbols absent in the
SO's, with them resolved to a symbol exported from the main binary;
This strategy doesn't really work with DLLs (where the import dependency
tree needs to be acyclic).
> >Windows is broken in so many ways
>
> Other examples? I find rather the opposite. For example I did like this
> remark of BGB's:
>
> >Then again, not like there is much hope of getting stuff ported when
> in general, nearly all of the Linux software seems to take a "you need
> the whole jungle to get a single banana" approach to software
> dependencies (and then much of the code tends to be riddled with GCC'isms)
>
> This somes my experience of software originating in Linux. This is why
> Windows had to acquire CYGWIN then MSYS then WSL. You can't build the
> simplest program without involving half of Linux.
Yes, and it is really annoying sometimes.
For the most part, Linux software builds and works fairly well... if one
is using a relatively mainline and relatively up-to-date Linux distro...
But, if one is not trying to build in or for a typical Linux style / GNU
based userland; it is straight up pain...
Like, typically either the "./configure" script is going to go down in a
crap-storm of error messages (say, if the shell is not "bash", or some
commands it tries to use are absent or don't accept the same
command-line arguments, etc); or libraries are going to be missing; or
the build just ends up dying due to compiler errors (say, which headers
exist are different, or their contents are different, ...).
Within the code itself, it often doesn't take much looking to find one of:
Pointer arithmetic on "void *";
Various GCC specific "__attribute__((whatever))" modifiers;
Blobs of GAS specific inline ASM;
...
Whereas in more cross-platform code, one will usually find stuff like:
#ifdef __GNUC__
... GCC specific stuff goes here ...
#endif
#ifdef _MSC_VER
... MSVC specific stuff goes here ...
#endif
...
And, different ways of doing stuff, say:
Some stuff that works on MSVC will break on GCC;
Some stuff that performs well on GCC will perform like garbage on MSVC;
...
Sometimes it makes sense to write a bunch of wrapper code or macros for
various tasks which differ between compilers and targets.
Though, have noted that sometimes programs will work at one optimization
level, but break at another (so, "-O3" or more so "-Ofast" is "playing
with fire" with GCC, as it is with "/O2" in MSVC; with GCC one often
needing "-fno-strict-aliasing -fwrapv" and similar for some older code
to work correctly).
My compiler uses sort of an intermediate C dialect, but is more
conservative by default in some areas, such as treating things like TBAA
as "opt-in" features, rather than "opt-out", ...
Though, I did designate various cases as "no consistent or sensible
behavior exists", so "whatever happens, happens". Separating out cases
that are "technically undefined, but has a conventionally accepted
behavior" (such as using pointer casts for type punning, etc), vs "no
accepted behavior and any behavior that may result is effectively a dice
roll..." (a lot of cases involving out-of-bounds memory access, etc).
Some amount of the extensions have more MSVC-like syntax (albeit the ASM
syntax itself is more derived from GAS style ASM syntax than Intel style
syntax). Though, in particular, it is derived from "GAS SuperH" (which
falls into a similar category as M68K and PDP-11 ASM syntax):
R4 //this is a register
@R4 //memory with address in R4
(R4) //same as @R4
(R4,32) //displacement
32(R4) //same as (R4,32)
Generally, ASM code is passed through the RPN stage by passing it along
as ASCII text blobs (similar to string literals). Where, the backend
will know how to deal with it. Though, this is generally after the
preprocessor and similar has had its way with it (and some minor aspects
of the ASM notation were modified to play along better with the C
preprocesor):
#1234 //doesn't play well with C preprocessor.
1234 //preprocessor leaves it alone
Some programs I had ported, such as ROTT, were full of out-of-bounds
memory access. Though, some aspects of the game did "subtly but
fundamentally change" when a lot of the out-of-bounds access was fixed,
and some of it was in a gray area of "broken but just happened to work
if memory objects are laid out in a certain way" or some "next-level
arcane magic" (where people were intentionally writing code around how
the compiler and memory allocator and similar will end up organizing
stuff in memory).
But, in general, stuff was less buggy when most of the OOB memory
accesses were fixed.
Still never did built up the courage to try poking around with trying to
port "Duke Nukem 3D", the code looks like a trash fire that doesn't seem
particularly worth the effort.
My usual first step is trying to get things ported and working on MSVC
on X64 (since this is "fairly similar" in terms of C dialect and behavior).
...
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2023-12-31 15:26 +0000 |
| Message-ID | <ums16d$1p232$1@dont-email.me> |
| In reply to | #379698 |
On 31/12/2023 05:46, BGB wrote:
> On 12/30/2023 8:18 PM, Bart wrote:
>> On 31/12/2023 01:34, Lawrence D'Oliveiro wrote:
>>> On Sat, 30 Dec 2023 19:14:55 -0600, BGB wrote:
>>>
>>>> Note that (unlike ELF on Linux), it is not currently possible to
>>>> directly share global variables across DLL boundaries.
>>>
>>> Windows is broken in so many ways ... when you achieve something, it’s
>>> like getting a bear to dance: it’s not that it dances badly, but that it
>>> dances at all.
>> I think that that limitation was specific to BGB's handling of DLLs;
>> it was not made clear.
>>
>
> Yes.
>
> In my case (for my custom target) I am using a modified version of
> PE/COFF (with some tweaks, *), but it has the issue that there is not
> currently (any) mechanism for sharing variables across DLL boundaries
> apart from getter/setter functions or similar.
I find PE/COFF format a nightmare. I did eventually get my tools to
generate first OBJ then EXE files. But when it came to DLL, there was
something wrong in the files I generated that I couldn't fix.
So for a couple of years, I created my own shared library format,
utterly different from PE+, and about 10 times simpler.
The shared library files were called ML, and I extended it to standalone
executables called MX files.
However ML libraries could only be used from my languages, and MX files
needed a small conventional EXE loader to get started.
Eventually I fixed the problems with DLL. (Partly it was that my
generated code wasn't fully position-independent and only ran in
low-memory below 2GB, but there was also a bug in the base-reloc tables.)
Now, sadly, I will probably drop my ML/MX files, even though my MLs have
advantages over DLLs. (Eg. they have the same environment as the host
apps, so that they can share things like pointers to allocated memory
and file handles. With DLL, a pointer malloc-ed in the host cannot be
freed within the DLL and vice versa.)
>> Each DLL exports certain symbols such as the addresses of functions
>> and variables. So no reason you can't access a variable exported from
>> any DLL, unless perhaps multiple instances of the same DLL have to
>> share the same static data, but that sounds very unlikely, as little
>> would work.
>>
>
> Much past roughly Win9x or so, it has been possible to use
> "__declspec(dllimport)" on global variables in Windows (in an earlier
> era, it was not possible to use the __declspec's, but instead necessary
> to manage DLL import/exports by writing out lists in ".DEF" files).
>
> It isn't entirely transparent, but yes, on actual Windows, it is very
> much possible to share global variables across DLL boundaries.
>
>
> Just, this feature is not (yet) supported by my compiler. Personally, I
> don't see this as a huge loss (even if it did work; I personally see it
> as "poor coding practice").
This is a language issue. Or, in C, it is compiler related.
I've never been quite sure how you tell a C compiler to export a certain
symbol when creating a DLL. Sometimes it just works; I think it just
exports everything that is not static (it may depend on a compiler
option too).
And some compilers may need this __declspec business, but I've never
bothered with it.
Mine just exports all not-static names. So this program:
int abc;
static int def;
void F(void) {}
static void G(void) {}
if compiled as: 'mcc -dll prog', produces a file prog.dll which, if I
dump it, shows this export table:
Export Directory
0 00000000 0 Fun F
1 00000000 0 Var abc
(There's something in it that distinguishes functions from variables,
but I can't remember the details.)
In any case, in C it can be hit and miss. In my own language, it is more
controlled: I used an 'export' prefix to export symbols from a program.
(It also conventiently creates interface files to be able to use the DLL
library from a program. The equivalent of prog.h for my example
containing the API needed to use it. Rolling that out to C is not
practical however as my 'export' applies also to things like types and
enums.)
>> This [somes] my experience of software originating in Linux. This is why
>> Windows had to acquire CYGWIN then MSYS then WSL. You can't build the
>> simplest program without involving half of Linux.
>
> Yes, and it is really annoying sometimes.
>
>
> For the most part, Linux software builds and works fairly well... if one
> is using a relatively mainline and relatively up-to-date Linux distro...
>
>
> But, if one is not trying to build in or for a typical Linux style / GNU
> based userland; it is straight up pain...
>
> Like, typically either the "./configure" script is going to go down in a
> crap-storm of error messages (say, if the shell is not "bash", or some
> commands it tries to use are absent or don't accept the same
> command-line arguments, etc); or libraries are going to be missing; or
> the build just ends up dying due to compiler errors (say, which headers
> exist are different, or their contents are different, ...).
./configure is an abomination anyway; I've seen 30,000-line scripts
which take forever to run, and test things like whether 'printf' is
supported.
But the biggest problem with them is when someone expects a Windows user
to use that same build process. Of course, ./configure is a Bash script
using Linux utilities.
It's like someone providing a .BAT file and expecting Linux users to do
something with it.
>
> Within the code itself, it often doesn't take much looking to find one of:
> Pointer arithmetic on "void *";
> Various GCC specific "__attribute__((whatever))" modifiers;
> Blobs of GAS specific inline ASM;
> ...
>
>
> Whereas in more cross-platform code, one will usually find stuff like:
> #ifdef __GNUC__
> ... GCC specific stuff goes here ...
> #endif
> #ifdef _MSC_VER
> ... MSVC specific stuff goes here ...
> #endif
> ...
Those conditional blocks never list my compiler, funnily enough. (#ifdef
__MCC__ will do it.)
> My compiler uses sort of an intermediate C dialect, but is more
> conservative by default in some areas, such as treating things like TBAA
> as "opt-in" features, rather than "opt-out", ...
>
> Though, I did designate various cases as "no consistent or sensible
> behavior exists", so "whatever happens, happens". Separating out cases
> that are "technically undefined, but has a conventionally accepted
> behavior" (such as using pointer casts for type punning, etc), vs "no
> accepted behavior and any behavior that may result is effectively a dice
> roll..." (a lot of cases involving out-of-bounds memory access, etc).
>
> Some amount of the extensions have more MSVC-like syntax (albeit the ASM
> syntax itself is more derived from GAS style ASM syntax than Intel style
> syntax). Though, in particular, it is derived from "GAS SuperH" (which
> falls into a similar category as M68K and PDP-11 ASM syntax):
> R4 //this is a register
> @R4 //memory with address in R4
> (R4) //same as @R4
> (R4,32) //displacement
> 32(R4) //same as (R4,32)
My C compiler is from 2017. Eventually I decided it was too
non-conforming and buggy to be a serious tool. It became a private one
(for example one special feature is being able to turn library APIs
defined as C headers, into bindings for either of my own languages,
although that can only do 90% of the work).
Last autumn I upgraded it with a new backend. But I also got rid of all
experimental features I'd played with.
It may be a poor compiler but CLI-wise it's much better than gcc which
continues to be a pain to use (still generating a.exe), and has odd bugs
in its CLI.
So, mine is still satisfying to have. I just call it a C-subset or
C-dialect compiler to get over the non-conformance. But for building my
own C code, it's my first choice.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2023-12-31 17:26 +0000 |
| Message-ID | <20231231092345.849@kylheku.com> |
| In reply to | #379701 |
On 2023-12-31, Bart <bc@freeuk.cm> wrote: > and file handles. With DLL, a pointer malloc-ed in the host cannot be > freed within the DLL and vice versa.) What??? All DLLs are in the same address space. malloc and free are sister functions that typically live in the same DLL, and don't care what calls them. Maybe you're referring to one DLL's free not being able to handle pointers produced by another DLL's malloc. (That's not a problem caused by the DLL mechanism itself and would not go away if those were somehow statically linked together.) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2023-12-31 19:23 +0000 |
| Message-ID | <umsf3a$1qttt$1@dont-email.me> |
| In reply to | #379703 |
On 31/12/2023 17:26, Kaz Kylheku wrote: > On 2023-12-31, Bart <bc@freeuk.cm> wrote: >> and file handles. With DLL, a pointer malloc-ed in the host cannot be >> freed within the DLL and vice versa.) > > What??? All DLLs are in the same address space. malloc and free are > sister functions that typically live in the same DLL, and don't > care what calls them. > > Maybe you're referring to one DLL's free not being able to handle > pointers produced by another DLL's malloc. I'm referring to the possibilty that, if host and DLL both import say msvcrt.dll, that each may have its own instance of msvcrt.dll, with its own static data. That would also be the case with two DLLs. But I can't reproduce the kind of error that would cause. So I was either mistaken, or it's been fixed in the last decade, or maybe my original test failed for other reasons, eg. because of statically linked libraries not shared ones, or mixed compilers (and do libraries) were used.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2023-12-31 14:46 -0500 |
| Message-ID | <umsgf8$1r2mh$1@dont-email.me> |
| In reply to | #379709 |
On 12/31/23 2:23 PM, Bart wrote: > On 31/12/2023 17:26, Kaz Kylheku wrote: >> On 2023-12-31, Bart <bc@freeuk.cm> wrote: >>> and file handles. With DLL, a pointer malloc-ed in the host cannot be >>> freed within the DLL and vice versa.) >> >> What??? All DLLs are in the same address space. malloc and free are >> sister functions that typically live in the same DLL, and don't >> care what calls them. >> >> Maybe you're referring to one DLL's free not being able to handle >> pointers produced by another DLL's malloc. > > I'm referring to the possibilty that, if host and DLL both import say > msvcrt.dll, that each may have its own instance of msvcrt.dll, with its > own static data. That would also be the case with two DLLs. > > But I can't reproduce the kind of error that would cause. > > So I was either mistaken, or it's been fixed in the last decade, or > maybe my original test failed for other reasons, eg. because of > statically linked libraries not shared ones, or mixed compilers (and do > libraries) were used. > > Sounds like either something used a static library or forced the system to link in two different copies of msvcrt.dll (perhaps by incorrectly including their own in an off-path directory) This wasn't that uncommon of a problem until people got burned enough by not following "the rules" that they started to do it right.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2023-12-31 15:49 -0600 |
| Message-ID | <umsnkk$1rvfm$1@dont-email.me> |
| In reply to | #379701 |
On 12/31/2023 9:26 AM, Bart wrote:
> On 31/12/2023 05:46, BGB wrote:
>> On 12/30/2023 8:18 PM, Bart wrote:
>>> On 31/12/2023 01:34, Lawrence D'Oliveiro wrote:
>>>> On Sat, 30 Dec 2023 19:14:55 -0600, BGB wrote:
>>>>
>>>>> Note that (unlike ELF on Linux), it is not currently possible to
>>>>> directly share global variables across DLL boundaries.
>>>>
>>>> Windows is broken in so many ways ... when you achieve something, it’s
>>>> like getting a bear to dance: it’s not that it dances badly, but
>>>> that it
>>>> dances at all.
>>> I think that that limitation was specific to BGB's handling of DLLs;
>>> it was not made clear.
>>>
>>
>> Yes.
>>
>> In my case (for my custom target) I am using a modified version of
>> PE/COFF (with some tweaks, *), but it has the issue that there is not
>> currently (any) mechanism for sharing variables across DLL boundaries
>> apart from getter/setter functions or similar.
>
> I find PE/COFF format a nightmare. I did eventually get my tools to
> generate first OBJ then EXE files. But when it came to DLL, there was
> something wrong in the files I generated that I couldn't fix.
>
> So for a couple of years, I created my own shared library format,
> utterly different from PE+, and about 10 times simpler.
>
> The shared library files were called ML, and I extended it to standalone
> executables called MX files.
>
> However ML libraries could only be used from my languages, and MX files
> needed a small conventional EXE loader to get started.
>
> Eventually I fixed the problems with DLL. (Partly it was that my
> generated code wasn't fully position-independent and only ran in
> low-memory below 2GB, but there was also a bug in the base-reloc tables.)
>
> Now, sadly, I will probably drop my ML/MX files, even though my MLs have
> advantages over DLLs. (Eg. they have the same environment as the host
> apps, so that they can share things like pointers to allocated memory
> and file handles. With DLL, a pointer malloc-ed in the host cannot be
> freed within the DLL and vice versa.)
>
OK.
I had considered a fully custom format at one point, original idea would
have been something vaguely resembling a AR or TAR file, say:
Program Header;
Segment Header;
LZ compressed segment;
Segment Header;
LZ compressed segment;
...
Where say, each segment may have one or more sections, specify a loader
address, and may include additional commands for what to do with it
(such as interpreting it as base relocs rather than being part of the
final image).
Technically, this would have also been along vaguely similar lines to
the Mach-O format.
But ended up opting with a modified PE/COFF as it already had most of
what I wanted (and I was already reasonably familiar with the format).
My case differed slightly in that I didn't need to care about whether
Windows or existing tools could understand the binaries, and so "PEL4"
is sort of its own format in a way as well.
Technically, it still fit what I wanted to do better than what ELF would
have been, though I had ended up tweaking some stuff to allow it to
support loading multiple binaries into the same address space:
All binaries include reloc tables;
The read-only and read/write sections are split up into two different
segments (using the Global Pointer data-directory entry to effectively
define the read/write section, with the Global Pointer pointed to the
start of this segment on program start-up).
I had looked into a few possible compression schemes, and LZ4 gave the
best properties for binaries.
I have a different (byte-oriented) compression scheme that tends to give
better compression for general purpose data compression, but LZ4 seemed
to give better results with executable code in this case.
>
>>> Each DLL exports certain symbols such as the addresses of functions
>>> and variables. So no reason you can't access a variable exported from
>>> any DLL, unless perhaps multiple instances of the same DLL have to
>>> share the same static data, but that sounds very unlikely, as little
>>> would work.
>>>
>>
>> Much past roughly Win9x or so, it has been possible to use
>> "__declspec(dllimport)" on global variables in Windows (in an earlier
>> era, it was not possible to use the __declspec's, but instead
>> necessary to manage DLL import/exports by writing out lists in ".DEF"
>> files).
>>
>> It isn't entirely transparent, but yes, on actual Windows, it is very
>> much possible to share global variables across DLL boundaries.
>>
>>
>> Just, this feature is not (yet) supported by my compiler. Personally,
>> I don't see this as a huge loss (even if it did work; I personally see
>> it as "poor coding practice").
>
> This is a language issue. Or, in C, it is compiler related.
>
> I've never been quite sure how you tell a C compiler to export a certain
> symbol when creating a DLL. Sometimes it just works; I think it just
> exports everything that is not static (it may depend on a compiler
> option too).
>
> And some compilers may need this __declspec business, but I've never
> bothered with it.
>
Yeah. GCC seems to be "export everything".
MSVC needs either __declspec or ".DEF" files.
I am not sure when exactly __declspec started being used for this,
seemingly sometime between "Visual C++ 4.0" and "Visual Studio 2003".
This isn't really documented online to really narrow it down much further.
In my case, I went with using a similar approach to MSVC, namely
explicit export.
Where the normal "extern" storage class is shared between translation
units, but does not cross DLL boundaries.
> Mine just exports all not-static names. So this program:
>
> int abc;
> static int def;
>
> void F(void) {}
> static void G(void) {}
>
> if compiled as: 'mcc -dll prog', produces a file prog.dll which, if I
> dump it, shows this export table:
>
> Export Directory
>
> 0 00000000 0 Fun F
> 1 00000000 0 Var abc
>
> (There's something in it that distinguishes functions from variables,
> but I can't remember the details.)
>
> In any case, in C it can be hit and miss. In my own language, it is more
> controlled: I used an 'export' prefix to export symbols from a program.
>
> (It also conventiently creates interface files to be able to use the DLL
> library from a program. The equivalent of prog.h for my example
> containing the API needed to use it. Rolling that out to C is not
> practical however as my 'export' applies also to things like types and
> enums.)
>
In my case, there are two major ways of invoking the compiler, say:
bgbcc /Fefoo.dll foo.c
Or:
bgbcc -o foo.dll foo.c
Where the compiler uses the file extension, and if it is DLL, it assumes
you want a DLL:
EXE: EXE file, "PBO ABI", fully relocatable.
DLL: DLL file, "PBO ABI", fully relocatable.
SYS: Bare-metal EXE, ABI more like traditional Win32 EXEs.
BIN: ROM image, no EXE headers, no relocs, ...
RIL: RIL Bytecode
OBJ: RIL Bytecode
O: Also RIL Bytecode
S: ASM output.
If no output file is given, it looks at whether it is trying to mimic
GCC style command-line behavior:
No: Assume "foo.exe" as default output.
Yes: Assume "a.exe" as default output.
Where, say, for the GCC-like mode:
-o <name> Output file.
-c Compile only
-E Preprocess only
-S ASM only.
-I<path> Add include path
-L<path> Add library path
-S<path> Add source path (excludes '-S' by itself)
-l<name> Add library
-D<name>[=<value>] #define something
-W<opt> Warning option
-m<tgt> Specify target machine
-f<opt> Specify target option/flag
-O<opt> Specify optimizer option.
-Z<opt> Specify debug option.
-g<opt> Also specify debug option.
...
For libraries, it checks the library path, where for "-l<name>" it will
look for:
lib<name>.<arch>.ril
lib<name>.ril
Assuming static linking in this case (the handling for DLLs is a little
different).
Note that, sort of like with MSVC, any debug data is dumped into
external files, and is not held within the EXE itself. Thus far, it is
fairly limited, mostly as a big ASCII text file with with a vaguely
similar structure to "nm" output.
Note for -E and -S, if no output file is specified, output is dumped to
stdout; and a bare '-' option indicates to read the input from stdin.
This was also partly to mimic GCC behavior.
Technically, to mimic GCC, for Linux and similar, it also symlinks other
tool names back to the BGBCC binary:
bjx2-pel-cc
bjx2-pel-gcc
bjx2-pel-ld
bjx2-pel-as
bjx2-pel-ar
...
Where, if it is called with a name in this form, it assumes that it
needs to try to emulate the respective command-line interface and
behavior (but, this part is still fairly incomplete).
Technically, this 'ar' is very nonstandard and currently can't entirely
emulate the standard behaviors.
But, apart from things like 'ar -c libname.a objfile*', the 'ar' tool
doesn't see much use (so its inability to be used to incrementally
update contents or similar is mostly N/A; could in theory add proper
support for '.a' files if it became an issue).
In this case, the main compiler binary functions like a sort of hydra
that takes over the roles of the entirety of "binutils".
>>> This [somes] my experience of software originating in Linux. This is
>>> why Windows had to acquire CYGWIN then MSYS then WSL. You can't build
>>> the simplest program without involving half of Linux.
>>
>> Yes, and it is really annoying sometimes.
>>
>>
>> For the most part, Linux software builds and works fairly well... if
>> one is using a relatively mainline and relatively up-to-date Linux
>> distro...
>>
>>
>> But, if one is not trying to build in or for a typical Linux style /
>> GNU based userland; it is straight up pain...
>>
>> Like, typically either the "./configure" script is going to go down in
>> a crap-storm of error messages (say, if the shell is not "bash", or
>> some commands it tries to use are absent or don't accept the same
>> command-line arguments, etc); or libraries are going to be missing; or
>> the build just ends up dying due to compiler errors (say, which
>> headers exist are different, or their contents are different, ...).
>
> ./configure is an abomination anyway; I've seen 30,000-line scripts
> which take forever to run, and test things like whether 'printf' is
> supported.
>
Yeah, and it is seemingly a bit of an uphill battle to try to make it
work in any environment that is not "GNU userland with GCC".
In the case of Clang, it seems to actively lie about its identity to try
to make configure and similar willing to accept it.
> But the biggest problem with them is when someone expects a Windows user
> to use that same build process. Of course, ./configure is a Bash script
> using Linux utilities.
>
> It's like someone providing a .BAT file and expecting Linux users to do
> something with it.
>
Yes.
For simple programs, one-liner ".bat" or ".sh" files are fairly effective.
And, then, "Makefile.tgt" or similar for more involved cases.
A lot of the more complex build systems are often either unnecessary, or
indicate a more fundamental problem with the program and its dependency
management (along with other annoyances, like indirectly making
"perl"/"python"/"nodejs"/etc effectively prerequisites to get the
program built).
>>
>> Within the code itself, it often doesn't take much looking to find one
>> of:
>> Pointer arithmetic on "void *";
>> Various GCC specific "__attribute__((whatever))" modifiers;
>> Blobs of GAS specific inline ASM;
>> ...
>>
>>
>> Whereas in more cross-platform code, one will usually find stuff like:
>> #ifdef __GNUC__
>> ... GCC specific stuff goes here ...
>> #endif
>> #ifdef _MSC_VER
>> ... MSVC specific stuff goes here ...
>> #endif
>> ...
>
> Those conditional blocks never list my compiler, funnily enough. (#ifdef
> __MCC__ will do it.)
>
>
I didn't list my own either, which is using __BGBCC__, ...
But, in practice, I can often partly overlap the __BGBCC__ and _MSC_VER
blocks, as a lot of the dialect-specific functionality is closer to MSVC
than GCC (but does support some GCC extensions as well).
There were some differences, like I ended up aligning with GCC and
making it so that "sizeof(long)==sizeof(void *)" rather than
"sizeof(long)==4" for 64-bit targets.
>> My compiler uses sort of an intermediate C dialect, but is more
>> conservative by default in some areas, such as treating things like
>> TBAA as "opt-in" features, rather than "opt-out", ...
>>
>> Though, I did designate various cases as "no consistent or sensible
>> behavior exists", so "whatever happens, happens". Separating out cases
>> that are "technically undefined, but has a conventionally accepted
>> behavior" (such as using pointer casts for type punning, etc), vs "no
>> accepted behavior and any behavior that may result is effectively a
>> dice roll..." (a lot of cases involving out-of-bounds memory access,
>> etc).
>>
>> Some amount of the extensions have more MSVC-like syntax (albeit the
>> ASM syntax itself is more derived from GAS style ASM syntax than Intel
>> style syntax). Though, in particular, it is derived from "GAS SuperH"
>> (which falls into a similar category as M68K and PDP-11 ASM syntax):
>> R4 //this is a register
>> @R4 //memory with address in R4
>> (R4) //same as @R4
>> (R4,32) //displacement
>> 32(R4) //same as (R4,32)
>
> My C compiler is from 2017. Eventually I decided it was too
> non-conforming and buggy to be a serious tool. It became a private one
> (for example one special feature is being able to turn library APIs
> defined as C headers, into bindings for either of my own languages,
> although that can only do 90% of the work).
>
> Last autumn I upgraded it with a new backend. But I also got rid of all
> experimental features I'd played with.
>
> It may be a poor compiler but CLI-wise it's much better than gcc which
> continues to be a pain to use (still generating a.exe), and has odd bugs
> in its CLI.
>
> So, mine is still satisfying to have. I just call it a C-subset or
> C-dialect compiler to get over the non-conformance. But for building my
> own C code, it's my first choice.
>
Summarized history:
~ 2001: (During high-school) Wrote a Scheme interpreter.
~ 2003: Started writing the first BGBScript interpreter.
This was around the end of high-school for me.
This interpreter used XML DOM for the ASTs
And AST walking for the interpreter.
It was dead slow...
The language design somewhat resembled JavaScript / ES3.
~ 2006: Rewrote BGBScript interpreter.
Reused much of the core of the Scheme interpreter as a base.
Started gluing on features from ActionScript.
Went over to a bytecode interpreter.
Started experimenting with JIT.
~ 2007:
First BGBCC was written, as a fork off the 2003 BGBScript.
Idea was to try to allow using C as a scripting language.
But, C was not a good scripting language...
BGBCC was repurposed as an FFI generator for BGBScript.
Still used XML-DOM based ASTs, with a Stack-Machine IR.
~ 2008-2013:
Wrote a 3D engine that was originally Doom3 like
Was using some Half-Life based file-formats (for maps/models/etc).
Was using dynamic Phong lighting and stencil shadows (like Doom3).
But, then shifted to copying Minecraft (with a Doom3 style renderer)
Its performance and memory usage was "not good"...
~ 2014: Made BGBScript2 VM
This was a redesign of BGBScript made to more resemble Java and C#.
Simplified some stuff, and made it primarily static typed.
Used stack-machine bytecode
Translated into 3AC traces for interpretation.
This strategy was a lot faster than direct interpretation.
Architecturally, it was similar to the Java JVM.
~ 2015/2016: Made a 2nd Minecraft like 3D engine
Was written in a mixture of C and BS2.
Core engine was C, most game code was BS2.
Was intended to be simpler/faster/lighter than its predecessor.
~ 2016: Started taking an interest in ISA design stuff.
BGBCC was revived, and was made to target SuperH / SH-4.
Ended up going with the WinCE PE/COFF variant for binaries.
Was also using GCC built for SH-4 / PE-COFF as well.
This mutated into my "BJX1" ISA, which was a modified SH-4.
Though, BJX1 turned into a horrid mess.
~ 2018:
The ISA design was rebooted into BJX2.
Basically, a new encoding scheme that was "less horrible".
The new ISA could mostly reuse the old ASM with minor tweaks.
The compiler backend was partly reworked for the new ISA encoding.
But, most of the compiler backend was copy/pasted from BJX1.
~ 2019-present:
The BJX2 effort had continued and expanded somewhat.
The ISA design has mutated a fair bit since it started.
My compiler's backend has, however, turned into a horrible mess.
Not much reason to target BGBCC to mainstream ISAs:
MSVC, GCC, CLang, etc, do well enough...
Some past small scale experiments trying to generate native code on ARM
performed horribly. It seems like, unless I could fix some of the issues
that still plague code generation for my own ISA, there is basically no
hope of being able to compete with GCC on ARM (which seemed to be not
particularly forgiving of crappy code generation, at least on the A53
and A55).
In some ways, BGBCC is a little bit of a throwback vs my BS2VM
(BGBScript2 VM design).
BGBCC:
Originally XML based ASTs.
Organized in linked-lists;
Using strings for node/attribute names;
...
Now, object-based ASTs faking the original XML-based ASTs.
No more string pointers for tag/attribute names.
The Bytecode was mostly unstructured.
Loading the bytecode is effectively a purely linear process.
You run the stack model, and the ops build all the 3AC and metadata.
BS2VM:
Object-based ASTs (conceptually JSON-like);
The bytecode uses a TLV based container format for bytecode.
Stuff is organized into sections and tables.
The metadata has an actual structure.
At present, in both cases, the ASTs use a similar structure internally:
Key-value pairs, with 16-bit keys and 64-bit values.
BGBCC uses type-tagged keys, BS2VM used a different tagging scheme.
Each node holds up to a fixed number of key/value pairs.
If this limit is exceeded, the nodes break-up B-Tree style.
Currently, this limit is 8, with one balancing for memory use.
At one point I did make a 3rd Minecraft-like 3D engine, but mostly
because the prior engine was still too heavyweight to run on an FPGA
board (and I wanted "something" that could run).
Say, my 2nd 3D engine needed around 256MB of RAM to work.
But, the FPGA board I was using has 128MB of RAM, and realistically
going much over 48-64MB of memory use is "seriously pushing it".
So, there was a bunch of effort trying to manage to make a small
"basically functional" Minecraft like 3D engine be able to fit into
around 40MB or so of RAM.
Was mostly successful, at least assuming one doesn't go out far enough
that it is generating new chunks (which somewhat increases its RAM
requirements).
Had a major difference from the second engine in how it managed world
drawing:
Second engine:
Figure out potentially visible chunks (16x16x16 blocks);
Build a vertex array for every potentially visible chunk;
Draw all the visible chunks.
Third engine:
Do spherical raycasts from the camera position;
Build a list of block faces that a ray had hit;
Draw all of the block faces into a vertex array;
Draw the vertex array.
Both engines ended up still using 16x16x16 block chunks, however:
2nd engine had 16x16x16 chunk regions (256x256x256 blocks);
3rd engine had 8x8x8 chunk regions (128x128x128 blocks).
Both used a similar scheme for chunks:
Single block-type, chunk block no data;
2-16 block-types, 4 bits per block;
17-256 block types, 8 bits per block;
257+:
Raw 32-bit block entries (2nd engine)
Unsupported (3rd engine).
With a block layout sorta like, say:
( 7: 0): Block Type
(11: 8): Block Attribute
(15:12): Sky Light (15 if direct view of the sky)
(19:16): Block Light Intensity
(23:20): Block Light Color
(31:24): Depends on engine (eg, block flags).
Where, most of the chunks have fewer than 16 unique blocks (sky being
purely air at a constant sky-light=15; underground mostly solid stone at
sky-light=0, ...). Where, say, when rebuilding the vertex array, the
sky-light level is multiplied with the light-level of the sky (based on
a day/night cycle) with the block-light intensity and color being added
on, to give the final face vertex color.
Though, one big tradeoff is that the computational cost of the
third-engine's strategy scales very poorly with draw distance.
And, unlike Wolfenstein3D or ROTT, the number of rays needed to fully
cover the screen with a ray sweep is impractical for 3D:
Wolf3D/ROTT: 320 ray sweeps, in 2D;
Minecraft like:
2000 if we disregard block-faces smaller than 4 pixels (at 320x200).
Though, one can reduce the ray-sweep density by applying a random jitter
to the rays and discarding any faces that haven't been hit recently.
I had used a full spherical sweep rather than a frustum sweep, as with
an asynchronous "run the ray sweep at 4 times per second or so", a
frustum sweep will result in big holes in the world whenever one turns
the camera. With a spherical sweep, everything is already there (so
looking around doesn't result in big ugly holes being visible), but does
lessen the amount of rays one can cast in the forward direction, along
with increasing the number of visible block-faces (since the block-faces
are still being processed even if they are outside the area being looked
at).
Partly to limit both costs, and required ray density, the rays will
simply stop after a certain distance (if it doesn't hit anything).
Note that if one sets a limit of, say, 16000 block faces, then this also
sets an upper limit on how much memory they need for the vertex arrays
(which is also somewhat less than the memory required to build full
vertex arrays for every chunk within the current draw distance).
Though, for a slow periodic update and small draw distance, it is
possible to outrun the visible part of the terrain (as the raycast and
vertex arrays lag behind the current position of the camera); along with
temporary holes opening up whenever previously occluded areas come into
view. These would be less of an issue with a faster raycast update
though (say, 10 or 15Hz), but, on a 50MHz CPU, this is asking a lot.
Didn't really make any interesting game out of this, it was more of a
technical experiment than anything else.
...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2023-12-31 23:46 +0000 |
| Message-ID | <umsufv$1snq9$2@dont-email.me> |
| In reply to | #379697 |
On Sun, 31 Dec 2023 02:18:25 +0000, Bart wrote: > This somes my experience of software originating in Linux. This is why > Windows had to acquire CYGWIN then MSYS then WSL. You can't build the > simplest program without involving half of Linux. On Linux, we have package managers that only pull in the needed dependencies. Windows just seems actively hostile to that kind of infrastructure management. If you meant “you can’t build the simplest program *on Windows* without involving half of Linux” ... well, that’s just a reflection on the deficiencies of Windows. On Linux, you already have the *whole* of Linux to start with.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-01 01:33 +0000 |
| Message-ID | <umt4pk$1tg5p$1@dont-email.me> |
| In reply to | #379720 |
On 31/12/2023 23:46, Lawrence D'Oliveiro wrote: > On Sun, 31 Dec 2023 02:18:25 +0000, Bart wrote: > >> This somes my experience of software originating in Linux. This is why >> Windows had to acquire CYGWIN then MSYS then WSL. You can't build the >> simplest program without involving half of Linux. > > On Linux, we have package managers that only pull in the needed > dependencies. Windows just seems actively hostile to that kind of > infrastructure management. If you meant “you can’t build the simplest > program *on Windows* without involving half of Linux” ... well, that’s > just a reflection on the deficiencies of Windows. On Linux, you already > have the *whole* of Linux to start with. And developers feel it necessary to USE everything that it provides! I've never managed to build the GMP library on Windows for example (it only comes as source code), because it requires that 30,000-line bash script which in turn needs sed and m4 and all the rest. Why? It's a numeric library. Why should it be dependent on OS? Or maybe Linux developers NEED all that hand-holding and have no idea how to build using a bare compiler. Remember that end-users building such projects are only doing a one-time build to get a working binary. I have sometimes made my own non-C projects available on Linux. I did that by transpiling to a single C source file. All you then need to build it is a C compiler. It would be almost as easy as building hello.c, except I suspect some don't even know that, since they are used to 'make'. > On Linux, we have package managers that only pull in the needed > dependencies. Windows just seems actively hostile to that kind of Yeah, I've seen them in action. Sometimes they work, sometimes not. On a Raspberry Pi, one 'apt-get install' went on for 90 minutes, then it crashed. Fortunately by then I'd forgotten what it was that I'd been trying to do. It seems peculiar to me that you take what I see as a drawback - excessive, gratuitous dependencies which also make the build process more complex and slower - and somehow turn that into an advantage. So any platform that doesn't include all that pointless crap must be at fault, rather than the developer who is inflicting those needless dependencies.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-01 02:00 +0000 |
| Message-ID | <umt6b8$1tk9o$1@dont-email.me> |
| In reply to | #379725 |
On Mon, 1 Jan 2024 01:33:38 +0000, Bart wrote: > On 31/12/2023 23:46, Lawrence D'Oliveiro wrote: >> >> If you meant “you can’t build the simplest >> program *on Windows* without involving half of Linux” ... well, that’s >> just a reflection on the deficiencies of Windows. On Linux, you already >> have the *whole* of Linux to start with. > > And developers feel it necessary to USE everything that it provides! It’s called “code reuse”. A well-designed package-management system just makes it so much easier to do. > I've never managed to build the GMP library on Windows for example (it > only comes as source code), because it requires that 30,000-line bash > script which in turn needs sed and m4 and all the rest. > > Why? It's a numeric library. Why should it be dependent on OS? Those are just standard file-manipulation tools that any decent OS should provide. > Or maybe Linux developers NEED all that hand-holding and have no idea > how to build using a bare compiler. If only you could do that on Windows ... but no. Look at all the C runtime stuff needed just to build a simple “Hello World” program ... because Windows automatically assumes that every program must have a GUI. > Remember that end-users building > such projects are only doing a one-time build to get a working binary. They find it easier to do “apt-get install”, or a GUI wrapper around same, like Synaptic.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-01 11:56 +0000 |
| Message-ID | <umu98h$26t0e$1@dont-email.me> |
| In reply to | #379726 |
On 01/01/2024 02:00, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 01:33:38 +0000, Bart wrote:
>
>> On 31/12/2023 23:46, Lawrence D'Oliveiro wrote:
>>>
>>> If you meant “you can’t build the simplest
>>> program *on Windows* without involving half of Linux” ... well, that’s
>>> just a reflection on the deficiencies of Windows. On Linux, you already
>>> have the *whole* of Linux to start with.
>>
>> And developers feel it necessary to USE everything that it provides!
>
> It’s called “code reuse”. A well-designed package-management system just
> makes it so much easier to do.
>
>> I've never managed to build the GMP library on Windows for example (it
>> only comes as source code), because it requires that 30,000-line bash
>> script which in turn needs sed and m4 and all the rest.
>>
>> Why? It's a numeric library. Why should it be dependent on OS?
>
> Those are just standard file-manipulation tools that any decent OS should
> provide.
What's that got to do with building able to build programs easily?
I have an interpreter app 'qc' which is 37 modules and 39Kloc. It's not
in C, and I usually build it on Windows like this:
c:\qx>mm qc
It takes 0.1 seconds. I don't support Linux directly, but I can port it
by transpiling to C first, which takes 90ms:
c:\qc>mc -c -linux qc
Now I can build it under WSL:
root@xxx:/mnt/c/qx# gcc qc.c -oqc -fno-builtin -lm -ldl
And run it, but it needs the '-nosys' option as its std libraries make
use of WinAPI:
root@xxx:/mnt/c/qx# ./qc -nosys hello
Hello, World! 1-Jan-2024 11:43:54
Here is the demo program it runs:
root@xxx:/mnt/c/qx# cat hello.q
println "Hello, World!", $date, $time
And these are the specs for those files:
c:\qx>dir qc.c qc
01/01/2024 11:40 1,392,581 qc.c
01/01/2024 11:42 846,488 qc
Quite a substantial program that can be built effortlessly on either
Windows or Linux. Using Tiny C, it apparently compiles it in 75ms.
Try the same exercise with any equivalentally-sized program originating
on Linux. That is end, end up with only a C file (even multiple C files)
that I can build with a bare compiler.
That seems to be beyond most Linux developers.
>
>> Or maybe Linux developers NEED all that hand-holding and have no idea
>> how to build using a bare compiler.
>
> If only you could do that on Windows ... but no. Look at all the C runtime
> stuff needed just to build a simple “Hello World” program ... because
> Windows automatically assumes that every program must have a GUI.
It sounds like you've either never used Windows or had one bad
experience, as this is incorrect.
If I do this on Windows:
mcc hello.c
it produces a file hello.exe which is 2.5KB. (Tcc manages it in 2.0KB!)
So what's the fuss?
>
>> Remember that end-users building
>> such projects are only doing a one-time build to get a working binary.
>
> They find it easier to do “apt-get install”, or a GUI wrapper around same,
> like Synaptic.
Windows applications have for long been a ready-to-run binary.
[toc] | [prev] | [next] | [standalone]
Page 31 of 34 — ← Prev page 1 … 29 30 [31] 32 33 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web