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 9 of 34 — ← Prev page 1 … 7 8 [9] 10 11 … 34 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-09 19:56 +0100 |
| Message-ID | <unk4tm$2408t$1@dont-email.me> |
| In reply to | #379948 |
On 09/01/2024 18:46, Bart wrote: > On 09/01/2024 14:56, David Brown wrote: >> On 09/01/2024 12:11, Bart wrote: > >>> Not at all. You are defending some crazy anomaly, that you find >>> nowhere else, for some insubstantial reason. >> >> I'm saying it doesn't matter. I have never heard it mentioned, >> anywhere, except by you. It is completely irrelevant. > > So you see this in code: > > (*F)(x); > > and don't assume that F must be a pointer to function; why not? I > thought you wanted that transparency? Yes, I assume F is a pointer to a function - because I assume, unless proven otherwise, that the author of the code is not a complete moron or an evil maniac doing his or her best to confuse people. (I haven't bothered responding to the rest of your post, because I can't see a realistic and accurate response without sounding nasty, and I don't want to do that. Suffice to say that C is inordinately successful as a language, and your language is not - perhaps there are good reasons for that.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-09 20:52 +0000 |
| Message-ID | <unkblm$2566s$1@dont-email.me> |
| In reply to | #379950 |
On 09/01/2024 18:56, David Brown wrote:
> On 09/01/2024 18:46, Bart wrote:
>> On 09/01/2024 14:56, David Brown wrote:
>>> On 09/01/2024 12:11, Bart wrote:
>>
>>>> Not at all. You are defending some crazy anomaly, that you find
>>>> nowhere else, for some insubstantial reason.
>>>
>>> I'm saying it doesn't matter. I have never heard it mentioned,
>>> anywhere, except by you. It is completely irrelevant.
>>
>> So you see this in code:
>>
>> (*F)(x);
>>
>> and don't assume that F must be a pointer to function; why not? I
>> thought you wanted that transparency?
>
> Yes, I assume F is a pointer to a function - because I assume, unless
> proven otherwise, that the author of the code is not a complete moron or
> an evil maniac doing his or her best to confuse people.
Maybe F used to be a pointer, but is now a normal function, and the code
was not updated. Or maybe a normal function named F is now shadowing the
more global function pointer F.
>
> (I haven't bothered responding to the rest of your post, because I can't
> see a realistic and accurate response without sounding nasty, and I
> don't want to do that. Suffice to say that C is inordinately successful
> as a language, and your language is not - perhaps there are good reasons
> for that.)
There's being successful, and there's being right.
/I/ can write:
println 0123
and get the expected output. C would give you 83.
Don't tell me: gcc has some option to warn of using octal literals. So
your 'successful' language relies on extensive extra tools (all the
stuff in that support truck) to keep it useable.
BTW here's an exchange from a few days ago:
DB:
>>> .. the insanity of evaluating to 0 when given a pointer/reference
to an "unbounded" array.
>>
BC:
>> ..it is low priority because it is never used that way.
>>
DB:
> That's the kind of potentially confusing short-cut you can make when
only you ever use the language.
I made the argument you gave - no one would do that - but when I do it,
it makes things confusing.
I did then try to fix that, but stopped because of interactions with
actual zero-length arrays (I would need to be fully immersed to make the
changes).
Then the next day I found that C doesn't even /have/ zero-length arrays:
you can't have an empty array; how about that? I thought C was zero-based!
As for things that are insane, how about:
int spam() {
spam: spam(spam, spam(), spam(spam(spam)), spam);
}
I can't write that in my language, as it won't accept complete
gobbledygook. Of course, it's not as 'successful' as C, so what do I know.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-09 13:15 -0800 |
| Message-ID | <8734v6p5s1.fsf@nosuchdomain.example.com> |
| In reply to | #379955 |
Bart <bc@freeuk.cm> writes:
[...]
> I did then try to fix that, but stopped because of interactions with
> actual zero-length arrays (I would need to be fully immersed to make
> the changes).
>
> Then the next day I found that C doesn't even /have/ zero-length
> arrays: you can't have an empty array; how about that? I thought C
> was zero-based!
[...]
Have you considered learning the language before trying to implement it?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-09 21:33 +0000 |
| Message-ID | <unke3h$25ia0$1@dont-email.me> |
| In reply to | #379957 |
On 09/01/2024 21:15, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
> [...]
>> I did then try to fix that, but stopped because of interactions with
>> actual zero-length arrays (I would need to be fully immersed to make
>> the changes).
>>
>> Then the next day I found that C doesn't even /have/ zero-length
>> arrays: you can't have an empty array; how about that? I thought C
>> was zero-based!
> [...]
>
> Have you considered learning the language before trying to implement it?
Which version of C do you suggest; the one where:
#include <stdio.h>
int main(void) {
int A[0];
int B[]={};
printf("%zu\n", sizeof(A));
printf("%zu\n", sizeof(B));
}
compiles fine with tcc, gcc and clang, and displays 0 for the sizes?
Or the one where those produce warnings? Or the one where it actually fails?
So, if C doesn't have zero-length arrays, why don't I get a fatal error?
Just like if I get if I try:
int A[-1];
Here they are much more unequivocal; all will give a hard error without
needing their arm twisting.
Perhaps the language should take this stuff more seriously, then maybe I
would.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-09 21:55 +0000 |
| Message-ID | <qhjnN.136894$Ama9.92332@fx12.iad> |
| In reply to | #379958 |
Bart <bc@freeuk.cm> writes:
>On 09/01/2024 21:15, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>> [...]
>>> I did then try to fix that, but stopped because of interactions with
>>> actual zero-length arrays (I would need to be fully immersed to make
>>> the changes).
>>>
>>> Then the next day I found that C doesn't even /have/ zero-length
>>> arrays: you can't have an empty array; how about that? I thought C
>>> was zero-based!
>> [...]
>>
>> Have you considered learning the language before trying to implement it?
>
>Which version of C do you suggest; the one where:
>
> #include <stdio.h>
>
> int main(void) {
> int A[0];
> int B[]={};
>
> printf("%zu\n", sizeof(A));
> printf("%zu\n", sizeof(B));
> }
>
>compiles fine with tcc, gcc and clang, and displays 0 for the sizes?
>
>Or the one where those produce warnings? Or the one where it actually fails?
All of them. You've been told over, and over, and over.
$ cc --pedantic-errors -o /tmp/a /tmp/t.c
/tmp/t.c: In function 'main':
/tmp/t.c:4:7: error: ISO C forbids zero-size array 'A' [-Wpedantic]
int A[0];
^
/tmp/t.c:5:11: error: ISO C forbids empty initializer braces [-Wpedantic]
int B[]={};
^
/tmp/t.c:5:7: error: zero or negative size array 'B'
int B[]={};
^
$
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-09 22:22 +0000 |
| Message-ID | <unkgvp$25vrm$1@dont-email.me> |
| In reply to | #379963 |
On 09/01/2024 21:55, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> Which version of C do you suggest; the one where:
>>
>> #include <stdio.h>
>>
>> int main(void) {
>> int A[0];
>> int B[]={};
>>
>> printf("%zu\n", sizeof(A));
>> printf("%zu\n", sizeof(B));
>> }
>>
>> compiles fine with tcc, gcc and clang, and displays 0 for the sizes?
>>
>> Or the one where those produce warnings? Or the one where it actually fails?
>
> All of them. You've been told over, and over, and over.
Been told what? That I should produce a compiler that, at anyone's whim,
can either pass, fail or warn about the same piece of code?
> $ cc --pedantic-errors -o /tmp/a /tmp/t.c
> /tmp/t.c: In function 'main':
> /tmp/t.c:4:7: error: ISO C forbids zero-size array 'A' [-Wpedantic]
> int A[0];
> ^
> /tmp/t.c:5:11: error: ISO C forbids empty initializer braces [-Wpedantic]
> int B[]={};
> ^
> /tmp/t.c:5:7: error: zero or negative size array 'B'
> int B[]={};
> ^
> $
So, DOES C HAVE ZERO-LENGTH ARRAYS OR NOT?
It's a really simple question!
Because this program easily passes:
int A[0];
This one doesn't, qne without needing to use -pedantic or -pedantic-errors:
int A[-1];
If the answer is No, why is gcc so reluctant to complain about it
compared with the -1 size?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-10 09:37 +0100 |
| Message-ID | <unll0n$2e1i8$1@dont-email.me> |
| In reply to | #379966 |
On 09/01/2024 23:22, Bart wrote:
> On 09/01/2024 21:55, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>
>>> Which version of C do you suggest; the one where:
>>>
>>> #include <stdio.h>
>>>
>>> int main(void) {
>>> int A[0];
>>> int B[]={};
>>>
>>> printf("%zu\n", sizeof(A));
>>> printf("%zu\n", sizeof(B));
>>> }
>>>
>>> compiles fine with tcc, gcc and clang, and displays 0 for the sizes?
>>>
>>> Or the one where those produce warnings? Or the one where it actually
>>> fails?
>>
>> All of them. You've been told over, and over, and over.
>
> Been told what? That I should produce a compiler that, at anyone's whim,
> can either pass, fail or warn about the same piece of code?
No, you have been told:
1. C is a language defined by the standards. Without further
qualification, "C" refers to the latest published ISO standard -
currently C17. But it's also fine to refer to specific standards, such
as C99. The standards define the language syntax, constraints, required
diagnostics (implementations are free to choose warnings or hard
errors), and standard library specifications. There are also many
pre-standard C versions, for which "K&R C" is /almost/ a standard.
2. Almost all C compilers implement some extensions by default. These
extensions are not C, but are compiler-specific language variants. Some
people find them useful, other people prefer to stick to standard C.
Some extensions are so widely implemented that they may be considered a
pseudo-standard, others are very compiler or target specific.
3. Almost all C compilers have default warnings and errors that do not
match the standards requirements for C. Often they do this in both
directions - failing to issue diagnostics on things that the standards
require, and also issuing errors (halting compilation) for things that
the standard allows. Almost all C compilers allow you to tune warnings
and errors.
4. Some C compilers aim to provide conforming modes, often for several
standard versions, even though they are non-conforming (see 2 and 3
above) by default. Others don't try to conform to any particular C
standard, and can only very loosely be called a C compiler.
5. A "C implementation" needs a compiler, a standard library, headers, a
linker, perhaps an assembler, and a way to run the program on the
target. These might be provided together, or combined from different
places. For example, Microsoft provides everything with their MSVC
tools. For gcc-based toolchains, GCC writes the compiler but does not
provide binaries. The assembler and linker often come from the binutils
project (which again does not provide binaries), but other assemblers
and linkers may be used. Various libraries may be used, depending on
the target, including glibc, newlib, musl, newlib-nano, redlib, avrlib,
and many others. Users can get the parts individually, or more often
they get packaged toolchains from Debian, Redhat, TDM, mingw-64, MS WSL,
NXP, TI, Microchip, or many others according to their needs.
Is any of that new to you? Can you honestly say you have not been told
all this, many, many times?
You /know/ how to make gcc and clang compile standard C. Yet you insist
on faking ignorance. You are either the most thick-witted programmer
around, or you are a dishonest troll who goes out of their way to spread
FUD. And we know you are not thick-witted.
>
>> $ cc --pedantic-errors -o /tmp/a /tmp/t.c
>> /tmp/t.c: In function 'main':
>> /tmp/t.c:4:7: error: ISO C forbids zero-size array 'A' [-Wpedantic]
>> int A[0];
>> ^
>> /tmp/t.c:5:11: error: ISO C forbids empty initializer braces [-Wpedantic]
>> int B[]={};
>> ^
>> /tmp/t.c:5:7: error: zero or negative size array 'B'
>> int B[]={};
>> ^
>> $
>
> So, DOES C HAVE ZERO-LENGTH ARRAYS OR NOT?
>
No.
> It's a really simple question!
>
With a really simple answer, known to anyone who has learned a
reasonable understanding of the C language - and certainly known to
anyone who has read the relevant part of the standard to see the answer
for themselves. (It is in 6.7.6.2p1 - the section with the cryptic and
barely incomprehensible title "Array declarators", in the chapter titled
"Declarations".)
> Because this program easily passes:
>
> int A[0];
>
> This one doesn't, qne without needing to use -pedantic or
> -pedantic-errors:
>
> int A[-1];
>
> If the answer is No, why is gcc so reluctant to complain about it
> compared with the -1 size?
>
Zero-length arrays are a gcc extension. You can read about them here,
under the mysterious and hard-to-find section of the gcc manual titled
"Arrays of Length Zero" :
<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>
There are a large number of features of C99 that started off as gcc
extensions in the 90's, before being standardised for C99. Some were
used pretty much directly, others where changed or adapted before
standardisation. Zero-length arrays were not incorporated in C99, but
their main use-case was taken with a slightly modified syntax as
flexible array struct members. gcc has an entirely reasonable policy of
not removing extensions that existing code may rely on, even if there
are newer standard ways to get a similar effect.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-10 12:12 +0000 |
| Message-ID | <unm1jm$2ft22$1@dont-email.me> |
| In reply to | #379984 |
On 10/01/2024 08:37, David Brown wrote:
> On 09/01/2024 23:22, Bart wrote:
> 1. C is a language defined by the standards. Without further
> qualification, "C" refers to the latest published ISO standard -
> currently C17. But it's also fine to refer to specific standards, such
> as C99. The standards define the language syntax, constraints, required
> diagnostics (implementations are free to choose warnings or hard
> errors), and standard library specifications. There are also many
> pre-standard C versions, for which "K&R C" is /almost/ a standard.
>
> 2. Almost all C compilers implement some extensions by default. These
> extensions are not C, but are compiler-specific language variants. Some
> people find them useful, other people prefer to stick to standard C.
> Some extensions are so widely implemented that they may be considered a
> pseudo-standard, others are very compiler or target specific.
>
> 3. Almost all C compilers have default warnings and errors that do not
> match the standards requirements for C. Often they do this in both
> directions - failing to issue diagnostics on things that the standards
> require, and also issuing errors (halting compilation) for things that
> the standard allows. Almost all C compilers allow you to tune warnings
> and errors.
>
> 4. Some C compilers aim to provide conforming modes, often for several
> standard versions, even though they are non-conforming (see 2 and 3
> above) by default. Others don't try to conform to any particular C
> standard, and can only very loosely be called a C compiler.
>
> 5. A "C implementation" needs a compiler, a standard library, headers, a
> linker, perhaps an assembler, and a way to run the program on the
> target. These might be provided together, or combined from different
> places.
My original implementation for Windows used these two files only:
bcc.exe (about 1MB)
msvcrt.dll
bcc.exe includes the compiler, headers and assembler (there was no linker).
My current one splits it up into 4 files:
mcc.exe (264KB)
aa.exe (Assembler, 94KB, still no linker)
msvcrt.dll
windows.h (optional)
A linker is only needed to statically combine my code with that from
other compilers.
> For example, Microsoft provides everything with their MSVC
> tools. For gcc-based toolchains, GCC writes the compiler but does not
> provide binaries. The assembler and linker often come from the binutils
> project (which again does not provide binaries), but other assemblers
> and linkers may be used. Various libraries may be used, depending on
> the target, including glibc, newlib, musl, newlib-nano, redlib, avrlib,
> and many others. Users can get the parts individually, or more often
> they get packaged toolchains from Debian, Redhat, TDM, mingw-64, MS WSL,
> NXP, TI, Microchip, or many others according to their needs.
Other smaller C Windows compilers (lccwin, pellesc, dmc are older ones,
then there is tcc) are self-contained without any of that complexity, or
the need to divy up the implementation into assorted parts that all live
in different places or that have to be individually sourced.
>
> You /know/ how to make gcc and clang compile standard C. Yet you insist
> on faking ignorance. You are either the most thick-witted programmer
> around, or you are a dishonest troll who goes out of their way to spread
> FUD. And we know you are not thick-witted.
Suppose you were given a C program to build. There are no instructions
(or there are instructions, but they are encoded inside some script in a
proprietory language that you don't understand and don't have a tool for).
How do you know what to tell gcc to compile it?
Suppose you took a program that you know perfectly well how to compile
with gcc, but you some reason you don't have it (maybe all instances of
gcc vanished overnight after some power blockout).
You have one or two lesser compilers with not many options; what do you
tell those how to compile that program?
(I'll make it easy and suggest neither program depends on gnu extensions.)
Both examples are basically my situation. I'm either building other
people' software, using a range of compilers (so if it works with A and
B with no special options, I'm not interested in pandering to gcc with a
huge laundry list of instructions)...
... or I'm generating C code of my own, which used to be compilable with
half a dozen C compilers with NO SPECIAL OPTIONS, but now I support 3,
and one or two of them might need a special option.
So, in my world, I really don't want to know about all that gcc palaver.
(You go to rent a car. In most cases all you need is a key to open the
door and turn on the ignition. Except the car made by gcc, which needs a
dozen different keys, and a long list of configuration options to be set
first: wheels:4; LHD or RHD: RHD, etc.
You see my frustration? Using the C language should be driving a car.)
You already know I have no idea about what version of C is involved,
only that it needs to pass with the compilers I list using the options
(or lack of options) that I stipulate at the top of the source file.
But you will be able to infer that I don't depend in gnu C extensions.
> Zero-length arrays are a gcc extension.
I wonder how many thousands of lines of code it took to implement such
an extension?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-10 14:17 +0100 |
| Message-ID | <unm5du$2ggel$1@dont-email.me> |
| In reply to | #379989 |
On 10/01/2024 13:12, bart wrote: > On 10/01/2024 08:37, David Brown wrote: >> On 09/01/2024 23:22, Bart wrote: > >> 1. C is a language defined by the standards. Without further >> qualification, "C" refers to the latest published ISO standard - >> currently C17. But it's also fine to refer to specific standards, >> such as C99. The standards define the language syntax, constraints, >> required diagnostics (implementations are free to choose warnings or >> hard errors), and standard library specifications. There are also >> many pre-standard C versions, for which "K&R C" is /almost/ a standard. >> >> 2. Almost all C compilers implement some extensions by default. These >> extensions are not C, but are compiler-specific language variants. >> Some people find them useful, other people prefer to stick to standard >> C. Some extensions are so widely implemented that they may be >> considered a pseudo-standard, others are very compiler or target >> specific. >> >> 3. Almost all C compilers have default warnings and errors that do not >> match the standards requirements for C. Often they do this in both >> directions - failing to issue diagnostics on things that the standards >> require, and also issuing errors (halting compilation) for things that >> the standard allows. Almost all C compilers allow you to tune >> warnings and errors. >> >> 4. Some C compilers aim to provide conforming modes, often for several >> standard versions, even though they are non-conforming (see 2 and 3 >> above) by default. Others don't try to conform to any particular C >> standard, and can only very loosely be called a C compiler. >> >> 5. A "C implementation" needs a compiler, a standard library, headers, >> a linker, perhaps an assembler, and a way to run the program on the >> target. These might be provided together, or combined from different >> places. > > My original implementation for Windows used these two files only: > No one cares. It does not matter how any particular C implementation does it, it only matters that there are many ways to package them. I gave examples purely as examples. The question is, do you understand what I wrote above, and is anything there new or surprising to you? > >> For example, Microsoft provides everything with their MSVC tools. >> For gcc-based toolchains, GCC writes the compiler but does not provide >> binaries. The assembler and linker often come from the binutils >> project (which again does not provide binaries), but other assemblers >> and linkers may be used. Various libraries may be used, depending on >> the target, including glibc, newlib, musl, newlib-nano, redlib, >> avrlib, and many others. Users can get the parts individually, or >> more often they get packaged toolchains from Debian, Redhat, TDM, >> mingw-64, MS WSL, NXP, TI, Microchip, or many others according to >> their needs. > No one cares. > >> >> You /know/ how to make gcc and clang compile standard C. Yet you >> insist on faking ignorance. You are either the most thick-witted >> programmer around, or you are a dishonest troll who goes out of their >> way to spread FUD. And we know you are not thick-witted. > > Suppose you were given a C program to build. There are no instructions > (or there are instructions, but they are encoded inside some script in a > proprietory language that you don't understand and don't have a tool for). > > How do you know what to tell gcc to compile it? I might make some guesses, because I know the typical flags needed for gcc (as do you, as you have been told them countless times). If these don't work and there are no clear instructions, I might ask the program developers for more information. I might google for it, or ask generally in appropriate forums (which comp.lang.c is not). Without the slightest doubt, I can say that if it were possible to build it using /your/ C compiler, and does not use extensions unsupported by gcc, then I could get it to build with gcc without much trouble. I think the same would apply to pretty much anyone who has some experience using gcc from the command line. > > Suppose you took a program that you know perfectly well how to compile > with gcc, but you some reason you don't have it (maybe all instances of > gcc vanished overnight after some power blockout). Now you sound as silly as that C90 fanatic who turns up here occasionally. <snip> >> Zero-length arrays are a gcc extension. > > I wonder how many thousands of lines of code it took to implement such > an extension? > I have no idea. It was a good idea at the time, because C90 did not have flexible array members. It is now pretty much unnecessary, though I am sure some people use "[0]" instead of "[]" in their flexible array struct members. And some might take advantage of gcc's slightly greater flexibility here than the C standards define.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-10 14:31 +0000 |
| Message-ID | <unm9o7$2h6ig$1@dont-email.me> |
| In reply to | #379990 |
On 10/01/2024 13:17, David Brown wrote:
> On 10/01/2024 13:12, bart wrote:
>>> For example, Microsoft provides everything with their MSVC tools.
>>> For gcc-based toolchains, GCC writes the compiler but does not
>>> provide binaries. The assembler and linker often come from the
>>> binutils project (which again does not provide binaries), but other
>>> assemblers and linkers may be used. Various libraries may be used,
>>> depending on the target, including glibc, newlib, musl, newlib-nano,
>>> redlib, avrlib, and many others. Users can get the parts
>>> individually, or more often they get packaged toolchains from Debian,
>>> Redhat, TDM, mingw-64, MS WSL, NXP, TI, Microchip, or many others
>>> according to their needs.
>>
>
> No one cares.
But you cared enough to list all those complicated ways that some have
implemented C. It sounded almost lovingly.
It's as though you're looking down disdainfully at all those seeking to
produce smaller simpler products: Here, THIS is how you produce a C
compiler! It has to be Big! And Slow! It has to be Complicated! It has
to have lots of Buttons!
You know, the most remarkable and impressive product for me is the Tiny
C compiler. It's Small. It's Fast. It's Simple.
For my generated C code, only 3 files of Tiny C, totalling 230KB, are
needed to turn it near-instantly into executable code. As a compiler
backend target, it's a solution that is 100 times smaller and 100 times
faster than LLVM.
Some people have different opinions about this stuff. C isn't your own
proprietory language that should only be processed with your stipulated
tool sets.
Anybody can implement their own ideas of how it should work. There are
reasons why those people put considerable efforts into those smaller,
self-contained and more user-friendly products.
Oh, I forgot, you don't care.
OK. Well I don't really care about what you're into either! I certainly
don't want to fuck about with -Wextra -Wpedantic -Wall -std=this -ofile
and all that nonsense, when a 10 seconds earlier I'd simpler done 'tcc
prog.c'.
For me a compiler should be as utilitarian and simple to use as a light
switch.
> Without the slightest doubt, I can say that if it were possible to build
> it using /your/ C compiler, and does not use extensions unsupported by
> gcc, then I could get it to build with gcc without much trouble.
You seem to be acknowledging the benefits of passing a code base through
a lesser compiler.
I
> think the same would apply to pretty much anyone who has some experience
> using gcc from the command line.
>
>>
>> Suppose you took a program that you know perfectly well how to compile
>> with gcc, but you some reason you don't have it (maybe all instances
>> of gcc vanished overnight after some power blockout).
>
> Now you sound as silly as that C90 fanatic who turns up here occasionally.
There are any number of actual scenarios where that can happen. That is,
you don't have access to your favourite compiler.
I actually can supply a C program, and the C compiler needed to build it
into an executable, on a floppy disk, in most cases. It can be as little
as 3 files (source, compiler, assembler); it will be instantly obvious
if there's one missing, and what the implications would be.
What is the minimum number of actual (ie. not ZIP) files needed to
bundle gcc in the same way? Give me a number. (I guess you don't know; I
thought you knew your tools inside out!)
>> I wonder how many thousands of lines of code it took to implement such
>> an extension?
>>
>
> I have no idea. It was a good idea at the time, because C90 did not
> have flexible array members. It is now pretty much unnecessary, though
> I am sure some people use "[0]" instead of "[]" in their flexible array
> struct members. And some might take advantage of gcc's slightly greater
> flexibility here than the C standards define.
I was thinking more of this:
void* table[] = {
// &a,
// &b,
// &c,
};
Temporarily comment out those entries (maybe they don't exist yet, or to
test how well program logic copes with an empty list).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-10 16:51 +0100 |
| Message-ID | <unmeee$2hvj3$1@dont-email.me> |
| In reply to | #379991 |
On 10/01/2024 15:31, bart wrote: > On 10/01/2024 13:17, David Brown wrote: >> On 10/01/2024 13:12, bart wrote: > > >>>> For example, Microsoft provides everything with their MSVC tools. >>>> For gcc-based toolchains, GCC writes the compiler but does not >>>> provide binaries. The assembler and linker often come from the >>>> binutils project (which again does not provide binaries), but other >>>> assemblers and linkers may be used. Various libraries may be used, >>>> depending on the target, including glibc, newlib, musl, newlib-nano, >>>> redlib, avrlib, and many others. Users can get the parts >>>> individually, or more often they get packaged toolchains from >>>> Debian, Redhat, TDM, mingw-64, MS WSL, NXP, TI, Microchip, or many >>>> others according to their needs. >>> >> >> No one cares. > > But you cared enough to list all those complicated ways that some have > implemented C. It sounded almost lovingly. I made no comment on what I liked or did not like about it - it was a factual list. I made it for /your/ benefit. I don't care about how different C toolchains are made, or by whom, or whether they are big or small. I care that the ones /I/ need are obtainable in a suitable manner for /my/ needs, running on /my/ choice of OS, and for /my/ choice of target. They must be available at an appropriate cost, and it must be possible to archive them indefinitely and use them without any awkward "license protect" systems. But it does not bother me if the package is 1 MB or 1 GB, 1 program or 1000 programs - those are not relevant concerns for professional programmers. I do, however, try my best to help people in groups like this. That includes writing posts to try to help and educate /you/. It gets increasingly frustrating, however. > You know, the most remarkable and impressive product for me is the Tiny > C compiler. It's Small. It's Fast. It's Simple. It is almost entirely useless, except for the very, very few people who /need/ a C compiler that is very small. In the days of 3.5" floppy disks for rescue disks, it was useful. In the days of 16 GB USB flash devices costing pennies, it is irrelevant. It is still remarkable, and still impressive - I have no disagreements there. It will always be an impressive achievement - that will not change with time. It might also be fun to play with. But it is still basically useless. It is no longer a particularly useful or needed tool. Lots of C compilers were once relevant, and now are not, except perhaps for a few very niche uses. > Anybody can implement their own ideas of how it should work. There are > reasons why those people put considerable efforts into those smaller, > self-contained and more user-friendly products. "User-friendly" /is/ something worth caring about. So is ease of installation. Small size, self-contained binaries - those are not of concern to users. It is absolutely a good thing for many people that a tool is easy to understand and use - but no one cares what goes on behind the scenes to make it work, as long as it works fast enough to be practical on sensible computers. (A half-arsed compiler that implements some unknown and undocumented subset of C, with random changes at the whim of the developer, cannot ever be "user-friendly" for anyone other than said developer.) To some extent, "user-friendly" will be at odds with flexibility and features, so there is a balance to be found. > > For me a compiler should be as utilitarian and simple to use as a light > switch. For me, a compiler should be something found in the real world and not a deluded fantasy. > >> Without the slightest doubt, I can say that if it were possible to >> build it using /your/ C compiler, and does not use extensions >> unsupported by gcc, then I could get it to build with gcc without much >> trouble. > > You seem to be acknowledging the benefits of passing a code base through > a lesser compiler. > You seem to be inventing things that I never wrote or implied.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-10 18:57 +0000 |
| Message-ID | <unmpbl$2joe1$1@dont-email.me> |
| In reply to | #379994 |
On 10/01/2024 15:51, David Brown wrote: > On 10/01/2024 15:31, bart wrote: > It is almost entirely useless, except for the very, very few people who > /need/ a C compiler that is very small. In the days of 3.5" floppy > disks for rescue disks, it was useful. In the days of 16 GB USB flash > devices costing pennies, it is irrelevant. 16 GB can hold a great deal of useful DATA: images, audio and video for example. It also tends to be consumed sequentially. But it is a mistake to think it makes it OK have programs, ie. CODE, that are 0.1GB, 1GB or 10GB in size. Code complexity doesn't scale linearly as data does. It means complicated, slow, cumbersome programs, that require extra power and memory resources. And buggy ones. > It is still remarkable, and still impressive - I have no disagreements > there. It will always be an impressive achievement - that will not > change with time. It might also be fun to play with. But it is still > basically useless. It is no longer a particularly useful or needed > tool. Lots of C compilers were once relevant, and now are not, except > perhaps for a few very niche uses. > > >> Anybody can implement their own ideas of how it should work. There are >> reasons why those people put considerable efforts into those smaller, >> self-contained and more user-friendly products. > > "User-friendly" /is/ something worth caring about. So is ease of > installation. Small size, self-contained binaries - those are not of > concern to users. It means I can email you both a source file, and the compiler or interpreter needed to build or run it (setting aside AV issues). Imagine supplying gcc or CPython as an email attachment! Somebody else may be implementing a language with C backend. Rather than requiring their users to install a C system which will dwarf there own product, or that is so slow that it would be like hitting a break wall as soon as they invoke it, a small, fast C compiler could be just bundled and invoked transparently as there is no disproportionate latency. > It is absolutely a good thing for many people that a > tool is easy to understand and use - but no one cares what goes on > behind the scenes to make it work, as long as it works fast enough to be > practical on sensible computers. (A half-arsed compiler that implements > some unknown and undocumented subset of C, with random changes at the > whim of the developer, cannot ever be "user-friendly" for anyone other > than said developer.) This is what I mean by user-friendly: c:\c>gcc hello C:\tdm\bin\ld.exe: cannot find hello: No such file or directory collect2.exe: error: ld returned 1 exit status c:\c>gcc hello.c c:\c>hello 'hello' is not recognized as an internal or external command, operable program or batch file. c:\c>gcc hello.c -hello gcc: error: unrecognized command-line option '-h' c:\c>gcc hello.c -ohello c:\c>hello Hello, World! 00007ff6923d13b4 The above tries to compile hello.c with gcc. The first attempt doesn't work. The second does, as no error is displayed. But what exactly has it compiled it to? As there is no file called 'hello.exe. It needs '-o'. The third attempt has a typo, the fourth finally works. The user friendly version is this: c:\c>mcc hello # same input as given to gcc Compiling hello.c to hello.exe c:\c>hello Hello, World! 0000000000401000 The compiler doesn't need the extension. It tells you exactly what it is doing, incuding where it will write the output. Please don't talk to me about user-friendly, you don't seem to have a clue.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-10 20:55 +0100 |
| Message-ID | <unmsnn$2k3ol$3@dont-email.me> |
| In reply to | #380000 |
On 10/01/2024 19:57, bart wrote: > On 10/01/2024 15:51, David Brown wrote: >> On 10/01/2024 15:31, bart wrote: > >> It is almost entirely useless, except for the very, very few people >> who /need/ a C compiler that is very small. In the days of 3.5" >> floppy disks for rescue disks, it was useful. In the days of 16 GB >> USB flash devices costing pennies, it is irrelevant. > > 16 GB can hold a great deal of useful DATA: images, audio and video for > example. It also tends to be consumed sequentially. What the *beep* are you talking about? Does your compiler consist of 1 MB of program and 16 GB of video about how much better it is than everything else? The prime use of tcc, when it had a use, was for rescue disks and other situations when you needed to boot from small mediums and have a running system of some sort without installing on a hard disk. That was originally a floppy, so tiny tools were vital. Then boot CDs became popular - size was no longer an issue unless you wanted a mini CD. By the time DVD's were common for the job, size of tools was irrelevant. I've just checked my main IT supplier - the /cheapest/ USB stick they have is 32 GB.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-10 20:49 +0000 |
| Message-ID | <unmvrv$2kpdi$1@dont-email.me> |
| In reply to | #380008 |
On 10/01/2024 19:55, David Brown wrote:
> On 10/01/2024 19:57, bart wrote:
>> On 10/01/2024 15:51, David Brown wrote:
>>> On 10/01/2024 15:31, bart wrote:
>>
>>> It is almost entirely useless, except for the very, very few people
>>> who /need/ a C compiler that is very small. In the days of 3.5"
>>> floppy disks for rescue disks, it was useful. In the days of 16 GB
>>> USB flash devices costing pennies, it is irrelevant.
>>
>> 16 GB can hold a great deal of useful DATA: images, audio and video
>> for example. It also tends to be consumed sequentially.
>
> What the *beep* are you talking about? Does your compiler consist of 1
> MB of program and 16 GB of video about how much better it is than
> everything else?
>
> The prime use of tcc, when it had a use, was for rescue disks and other
> situations when you needed to boot from small mediums and have a running
> system of some sort without installing on a hard disk. That was
> originally a floppy, so tiny tools were vital. Then boot CDs became
> popular - size was no longer an issue unless you wanted a mini CD. By
> the time DVD's were common for the job, size of tools was irrelevant.
>
> I've just checked my main IT supplier - the /cheapest/ USB stick they
> have is 32 GB.
>
I'm starting to wonder how dense you can be. But I know that's not the
the case; just unreceptive to certain concepts or unwilling to consider
them.
You are claiming that there is no point in limiting the size of code,
because after all you can buy 16GB or 32GB memory sticks.
So I'm not sure what your point is. Does the prevalence of very cheap
storage make it OK to have code that is 10, 100 or 1000 times bigger
than it need be?
Apparently so, according to you. Because of course there are no
consequences of that.
BTW these are some programs which are part of my gcc:
nasm.exe 1.4MB
ld.exe 1.5MB
as.exe 1.6MB
The first one, perhaps first two, will just fit onto one floppy, which I
think is 1.44MiB. The last is just over.
So three standalone programs that are still, in 2024, at floppy disk
scale. Why is that, given that you can buy 32,000MB storages devices for
'pennies'?
Note that I did not write these programs. I don't have a monopoly on
writing smallish, self-contained applications.
Will you also dismiss those apps for being too small to be of
consequence? Or will you admit that sometimes the scale of a task isn't
great enough to warrant a huge executable?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-11 11:26 +0100 |
| Message-ID | <unofnp$2v01b$1@dont-email.me> |
| In reply to | #380011 |
On 10/01/2024 21:49, bart wrote: > On 10/01/2024 19:55, David Brown wrote: >> On 10/01/2024 19:57, bart wrote: >>> On 10/01/2024 15:51, David Brown wrote: >>>> On 10/01/2024 15:31, bart wrote: >>> >>>> It is almost entirely useless, except for the very, very few people >>>> who /need/ a C compiler that is very small. In the days of 3.5" >>>> floppy disks for rescue disks, it was useful. In the days of 16 GB >>>> USB flash devices costing pennies, it is irrelevant. >>> >>> 16 GB can hold a great deal of useful DATA: images, audio and video >>> for example. It also tends to be consumed sequentially. >> >> What the *beep* are you talking about? Does your compiler consist of >> 1 MB of program and 16 GB of video about how much better it is than >> everything else? >> >> The prime use of tcc, when it had a use, was for rescue disks and >> other situations when you needed to boot from small mediums and have a >> running system of some sort without installing on a hard disk. That >> was originally a floppy, so tiny tools were vital. Then boot CDs >> became popular - size was no longer an issue unless you wanted a mini >> CD. By the time DVD's were common for the job, size of tools was >> irrelevant. >> >> I've just checked my main IT supplier - the /cheapest/ USB stick they >> have is 32 GB. >> > > I'm starting to wonder how dense you can be. But I know that's not the > the case; just unreceptive to certain concepts or unwilling to consider > them. > > You are claiming that there is no point in limiting the size of code, > because after all you can buy 16GB or 32GB memory sticks. I am claiming that the size of a compiler is rarely of any relevance. The point of tcc being small was for situations where you might need a C compiler, but have very little space - primarily for *nix rescue disks or bootup systems. This is no longer a relevant use-case. There are almost no circumstances where you would need a C implementation, where you could use a C implementation that took 1 MB of space on a disk, and where you could not equally well use a C implementation that took 1 GB of space on the disk. Can you describe even a single situation where the 1 MB toolchain would work and the 1 GB would not? I don't care about which you /prefer/, or how long it would take to download or install, or how long it takes to run, or the flags it has, or how easy it is to use, or whether you think the extra space or features are unnecessary. Describe to me the circumstances for which a 1 MB tcc toolchain would work but a 1 GB gcc toolchain would not. Imagine someone wrote a program called "tcc" that accepted the same command line flags and options as the tcc compiler, then called gcc with appropriate flags and options so that gcc matched exactly in terms of the code it accepted and rejected, and how it treated the code. Under what circumstances would that "fake" tcc be unusable while "real" tcc works fine? > > So I'm not sure what your point is. Does the prevalence of very cheap > storage make it OK to have code that is 10, 100 or 1000 times bigger > than it need be? On what basis do you claim gcc (or some other tool) is orders of magnitude bigger than it needs to be? Let's take a real example. I have an installation of a complete gcc-based toolchain for 32-bit ARM, hosted on 64-bit Linux. I have many such installations, but we'll pick one - release gcc-arm-none-eabi-10-2020-q4-major. (You can download it yourself for Windows hosting if you like.) The download was about 150 Mb, unpacked it is 725 MB on my disk. Of those 725 Mb, 68 Mb is documentation - because for /real/ tools, documentation is important. And for /real/ tools, user convenience is vastly more important than disk space, so the documentation is in several different formats, letting users choose what they prefer. In the "bin" directory, there is about 60 MB of programs - there is not just a compiler, but there are many programs that are useful to at least some toolchain users. As well as the main C compiler, there is an assembler, linker, C++ compiler, stand-alone C preprocessor, debugger, profiler, code coverage tools, object code analysis and dump tools, and many others. No single user will use all of them, but each tool will be helpful to someone. Then there are some 150 MB of libraries and sub-programs for the compiler - the actual C compiler is about 25 MB. (C++ and LTO are other 25 MB each.) That's vastly bigger than tcc - but gcc is a vastly more powerful compiler and does vastly more. Again, no one user uses all the features, but pretty much every feature is used by someone. Also in this directory is the "compiler support" libraries for the targets - software floating point, startup code, C++ runtime support, in multiple versions for some 20+ different 32-bit ARM architectures. That's another 50 MB. There's 20 MB of header files (by far the biggest bulk is from C++), and then about 430 MB of library files - again for countless versions and variants of ARM devices, for C and C++, for big full-featured libraries and small, space-saving libraries, for debug libraries, for different ABI versions, and so on. That breakdown should give you some idea of the space used - the space /needed/ - be real toolchains. You seem to imagine that the gcc developers are merely incompetent and write 1000 times too many lines of code. You fail to realise that you write your little tools for one person on one target, to work with source code written by one person for one kind of application, with no idea or concern about code optimisation, safety, quality control, testing, differing user experience and needs, debugging, user choices. Of course your little tools are tiny compared to real-world tools. (tcc /was/ written to be used by other people - but it was intentionally designed to be limited and inflexible so that it could be as small as possible.) Now, I'm sure a toolchain could be made with equal features to gcc and a quarter of the size. But doing so would be far more work - there is no point in finding some smart way to optimise the target libraries when disk space is free. As a user, I'd much rather the developers spent their time on something more useful than saving me a couple of pence worth of disk space. > > Apparently so, according to you. Because of course there are no > consequences of that. No, there are no /significant/ consequences. So it doesn't matter. > > BTW these are some programs which are part of my gcc: > > nasm.exe 1.4MB > ld.exe 1.5MB > as.exe 1.6MB > > The first one, perhaps first two, will just fit onto one floppy, which I > think is 1.44MiB. The last is just over. > > So three standalone programs that are still, in 2024, at floppy disk > scale. Why is that, given that you can buy 32,000MB storages devices for > 'pennies'? Do you imagine the developers took the size of a floppy into account when they made these programs? Is that what you are trying to suggest? These are small, in comparison to a C compiler, because they are simple, in comparison to a C compiler. > > Note that I did not write these programs. I don't have a monopoly on > writing smallish, self-contained applications. > > Will you also dismiss those apps for being too small to be of > consequence? Or will you admit that sometimes the scale of a task isn't > great enough to warrant a huge executable? > WTF are you on about? Sometimes you spout the most incredible rubbish. In what twisted fantasy world does "I don't care if a useful feature-filled program takes a lot of disk space" imply "Small programs are irrelevant" ?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-10 19:19 -0800 |
| Message-ID | <unnmo3$2roro$2@dont-email.me> |
| In reply to | #380008 |
On 1/10/2024 11:55 AM, David Brown wrote: > On 10/01/2024 19:57, bart wrote: >> On 10/01/2024 15:51, David Brown wrote: >>> On 10/01/2024 15:31, bart wrote: >> >>> It is almost entirely useless, except for the very, very few people >>> who /need/ a C compiler that is very small. In the days of 3.5" >>> floppy disks for rescue disks, it was useful. In the days of 16 GB >>> USB flash devices costing pennies, it is irrelevant. >> >> 16 GB can hold a great deal of useful DATA: images, audio and video >> for example. It also tends to be consumed sequentially. > > What the *beep* are you talking about? Does your compiler consist of 1 > MB of program and 16 GB of video about how much better it is than > everything else? > > The prime use of tcc, when it had a use, was for rescue disks and other > situations when you needed to boot from small mediums and have a running > system of some sort without installing on a hard disk. That was > originally a floppy, so tiny tools were vital. Then boot CDs became > popular - size was no longer an issue unless you wanted a mini CD. By > the time DVD's were common for the job, size of tools was irrelevant. Comic relief: That interesting game Phantasmagoria had seven CD's. ;^) > > I've just checked my main IT supplier - the /cheapest/ USB stick they > have is 32 GB. >
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2024-01-11 00:30 +0100 |
| Message-ID | <unn99q$1guu$1@news.gegeweb.eu> |
| In reply to | #380000 |
On 1/10/24 19:57, bart wrote: > The above tries to compile hello.c with gcc. The first attempt doesn't > work. The second does, as no error is displayed. But what exactly has it > compiled it to? As there is no file called 'hello.exe. o ____ _____ _____ __ __ o | _ \ |_ _| | ___| | \/ | o | |_) | | | | |_ | |\/| | o | _ < | | | _| | | | | o |_| \_\ |_| |_| |_| |_| o -- +---------------------------------------------------------------------+ | https://tube.interhacker.space/a/tth/video-channels | +---------------------------------------------------------------------+
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-11 01:14 +0000 |
| Message-ID | <unnfdb$2n5b9$1@dont-email.me> |
| In reply to | #380014 |
On 10/01/2024 23:30, tTh wrote: > On 1/10/24 19:57, bart wrote: > >> The above tries to compile hello.c with gcc. The first attempt doesn't >> work. The second does, as no error is displayed. But what exactly has >> it compiled it to? As there is no file called 'hello.exe. > > o ____ _____ _____ __ __ > o | _ \ |_ _| | ___| | \/ | > o | |_) | | | | |_ | |\/| | > o | _ < | | | _| | | | | > o |_| \_\ |_| |_| |_| |_| > o > I see. It doesn't matter how complex, unfriendly, inconvenient or error-prone using a piece of software is, it's all fine so long as you tell the user: R T F M? That makes up for designing it properly? Instead of getting rid of unnecessary hoops you have to jump through, you'd just write a thicker instruction manual and sell more training courses. (And force people to use 'make' - another dozen hoops.) Plus of course you can command more pay for mastering that contrived complexity. What /I/ do is strive to get rid of those hoops.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-10 19:25 -0800 |
| Message-ID | <unnn47$2roro$3@dont-email.me> |
| In reply to | #380015 |
On 1/10/2024 5:14 PM, bart wrote: > On 10/01/2024 23:30, tTh wrote: >> On 1/10/24 19:57, bart wrote: >> >>> The above tries to compile hello.c with gcc. The first attempt >>> doesn't work. The second does, as no error is displayed. But what >>> exactly has it compiled it to? As there is no file called 'hello.exe. >> >> o ____ _____ _____ __ __ >> o | _ \ |_ _| | ___| | \/ | >> o | |_) | | | | |_ | |\/| | >> o | _ < | | | _| | | | | >> o |_| \_\ |_| |_| |_| |_| >> o >> > > I see. It doesn't matter how complex, unfriendly, inconvenient or > error-prone using a piece of software is, it's all fine so long as you > tell the user: > > R T F M? > > That makes up for designing it properly? > > Instead of getting rid of unnecessary hoops you have to jump through, > you'd just write a thicker instruction manual and sell more training > courses. (And force people to use 'make' - another dozen hoops.) Did you ever buy any Invisiclue booklets? Infocom games? > > Plus of course you can command more pay for mastering that contrived > complexity. > > What /I/ do is strive to get rid of those hoops. > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-01-11 17:56 +0000 |
| Message-ID | <unpa3o$32vrk$1@dont-email.me> |
| In reply to | #380015 |
On 11/01/2024 01:14, bart wrote: > On 10/01/2024 23:30, tTh wrote: >> On 1/10/24 19:57, bart wrote: >> >>> The above tries to compile hello.c with gcc. The first attempt >>> doesn't work. The second does, as no error is displayed. But what >>> exactly has it compiled it to? As there is no file called 'hello.exe. >> >> o ____ _____ _____ __ __ >> o | _ \ |_ _| | ___| | \/ | >> o | |_) | | | | |_ | |\/| | >> o | _ < | | | _| | | | | >> o |_| \_\ |_| |_| |_| |_| >> o >> > > I see. It doesn't matter how complex, unfriendly, inconvenient or > error-prone using a piece of software is, it's all fine so long as you > tell the user: > > R T F M? > > That makes up for designing it properly? > > Instead of getting rid of unnecessary hoops you have to jump through, > you'd just write a thicker instruction manual and sell more training > courses. (And force people to use 'make' - another dozen hoops.) > > Plus of course you can command more pay for mastering that contrived > complexity. > > What /I/ do is strive to get rid of those hoops. Here's some hoops, for you ... $ ls hello.c No Makefile, you'll notice. $ make hello cc hello.c -o hello $ ./hello Hello World!
[toc] | [prev] | [next] | [standalone]
Page 9 of 34 — ← Prev page 1 … 7 8 [9] 10 11 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web