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 8 of 34 — ← Prev page 1 … 6 7 [8] 9 10 … 34 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-05 18:17 -0800 |
| Message-ID | <87o7dzryrf.fsf@nosuchdomain.example.com> |
| In reply to | #379871 |
Bart <bc@freeuk.cm> writes:
> On 05/01/2024 23:02, Ben Bacarisse wrote:
>> Bart <bc@freeuk.cm> writes:
>>> In C, sizeof() is usually compile-time, except when used on VLAs,
> and here,
>>> as usual for VLAs, it is a lot more complicated than you'd think:
>>>
>>> --------
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int main(void) {
>>> int n=rand()+1;
>>> typedef char (**T)[n];
>>> n=-777;
>>>
>>> T x;
>>>
>>> printf("%zu\n", sizeof(**x));
>>> }
>>> --------
>>>
>>> This actually displays 42 (really!). 'x' is a pointer (to a pointer to
>>> array). There is no actual array allocated.
>>
>> More to the point, x is uninitialised and thus evaluating sizeof **x is
>> undefined behaviour. gcc has some flags that could have helped you to
>> find that out.
>
> I actually don't know if it's evaluating it or not. Why on earth
> should it? If I change the program to print the original 'n', it is 42
> too. So it doesn't need to evaluate **x to get that dimension.
The C standard currently says:
The sizeof operator yields the size (in bytes) of its operand, which
may be an expression or the parenthesized name of a type. The size
is determined from the type of the operand. The result is an
integer. If the type of the operand is a variable length array type,
the operand is evaluated; otherwise, the operand is not evaluated
and the result is an integer constant.
The idea that the operand is "evaluated" is problematic. For example,
if the argument is a parenthesized type name, it's not clear what it
means to "evaluate" it. And there are cases (mostly contrived) where
the rule results in side effects that aren't actually necessary to
determine the size.
If I write:
int n = rand() % 10 + 1;
int vla[n];
printf("%zu\n", sizeof vla);
then the standard says that the expression `vla` is "evaluated". Since
it's of array type, that would logically involve retrieving the values
of each of its elements (there's no array-to-pointer conversion in this
context), which would have undefined behavior because they're
uninitialized. It's fairly clear that wasn't the intent; the only thing
that needs to be evaluated is the implicit metadata that gives the size
of the array.
Jens Gustedt has written a proposal to address this, probably in C26.
See <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3187.htm>.
In practice, applying sizeof to a VLA type, or to a named object of VLA
type, doesn't create any conceptual problems, and those are by far the
most common cases.
When a variable length array type is created, its length is determined
when execution reaches the definition, and the compiler generates code
to implicitly store that information somewhere for later use. If the
length expression happens to be the name of an object, any later changes
to the value of the object do not affect the VLA type or its size or
length; I suggest you stop being surprised by that fact. Applying sizeof
to a VLA type or object retrieves the stored size.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-06 10:09 +0100 |
| Message-ID | <unb5d3$hum9$2@dont-email.me> |
| In reply to | #379866 |
On 05/01/2024 23:19, Bart wrote: > On 05/01/2024 14:05, David Brown wrote: >> On 05/01/2024 02:53, Bart wrote: > >>> It doesn't need to take a heavy-handed approach like C++ or Python. >>> >> >> One option for a useful array length operator/function/macro is a >> simple and limited feature that works for arrays of known size and >> gives a hard (compile-time) error when the size is not known. The one >> you have in your own language covers most of that, except for the >> insanity of evaluating to 0 when given a pointer/reference to an >> "unbounded" array. > > It gives zero because that is actually the compile-time type of the > array. But it is low priority because it is never used that way. > That's the kind of potentially confusing short-cut you can make when only you ever use the language. It is also fine for when people make their own array_length macros for use in their own code. When you know all the details of the operator/macro/function, and you are the only one using it, it's okay if the specification is weird and unhelpful for some cases. It's a different matter entirely if you are making something that other people will use. > > In C, sizeof() is usually compile-time, except when used on VLAs, and > here, as usual for VLAs, it is a lot more complicated than you'd think: > No it is not. I don't think "garbage in, garbage out" is a complicated concept. You can write pathological shit in any language and get meaningless results out - it has no bearing on anything in real code. (It can be fun to play around with, but it does not mean there is a problem with the language feature.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-06 10:27 +0000 |
| Message-ID | <unb9uk$igst$1@dont-email.me> |
| In reply to | #379878 |
On 06/01/2024 09:09, David Brown wrote: > On 05/01/2024 23:19, Bart wrote: >> On 05/01/2024 14:05, David Brown wrote: >>> On 05/01/2024 02:53, Bart wrote: >> >>>> It doesn't need to take a heavy-handed approach like C++ or Python. >>>> >>> >>> One option for a useful array length operator/function/macro is a >>> simple and limited feature that works for arrays of known size and >>> gives a hard (compile-time) error when the size is not known. The >>> one you have in your own language covers most of that, except for the >>> insanity of evaluating to 0 when given a pointer/reference to an >>> "unbounded" array. >> >> It gives zero because that is actually the compile-time type of the >> array. But it is low priority because it is never used that way. >> > > That's the kind of potentially confusing short-cut you can make when > only you ever use the language. It is also fine for when people make > their own array_length macros for use in their own code. When you know > all the details of the operator/macro/function, and you are the only one > using it, it's okay if the specification is weird and unhelpful for some > cases. It's a different matter entirely if you are making something > that other people will use. > >> >> In C, sizeof() is usually compile-time, except when used on VLAs, and >> here, as usual for VLAs, it is a lot more complicated than you'd think: >> > > No it is not. I don't think "garbage in, garbage out" is a complicated > concept. You can write pathological shit in any language and get > meaningless results out - it has no bearing on anything in real code. > (It can be fun to play around with, but it does not mean there is a > problem with the language feature.) And yet, in my example, lccwin32 gave the wrong result, and in one case crashed. (I no longer have other smaller C compilers to try out.) It suggests the problem is not trivial. The concept is not that easy to get your head around either, the idea that the variable aspects of a VLA are associated with its type, not its value or instance. In my example, there were no instances of any actual arrays, not even if I declared an instance of one of the pointers involved, yet space had to be allocated for its size. And I kept the type simple. I remember also trying out VLAs within a struct, and there I got a wider variance of results. You can keep saying that VLAs are trivial to understand and implement; I won't believe you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-06 15:23 +0100 |
| Message-ID | <unbnpa$koa8$1@dont-email.me> |
| In reply to | #379879 |
On 06/01/2024 11:27, Bart wrote: > On 06/01/2024 09:09, David Brown wrote: >> On 05/01/2024 23:19, Bart wrote: >>> On 05/01/2024 14:05, David Brown wrote: >>>> On 05/01/2024 02:53, Bart wrote: >>> >>>>> It doesn't need to take a heavy-handed approach like C++ or Python. >>>>> >>>> >>>> One option for a useful array length operator/function/macro is a >>>> simple and limited feature that works for arrays of known size and >>>> gives a hard (compile-time) error when the size is not known. The >>>> one you have in your own language covers most of that, except for >>>> the insanity of evaluating to 0 when given a pointer/reference to an >>>> "unbounded" array. >>> >>> It gives zero because that is actually the compile-time type of the >>> array. But it is low priority because it is never used that way. >>> >> >> That's the kind of potentially confusing short-cut you can make when >> only you ever use the language. It is also fine for when people make >> their own array_length macros for use in their own code. When you >> know all the details of the operator/macro/function, and you are the >> only one using it, it's okay if the specification is weird and >> unhelpful for some cases. It's a different matter entirely if you are >> making something that other people will use. >> >>> >>> In C, sizeof() is usually compile-time, except when used on VLAs, and >>> here, as usual for VLAs, it is a lot more complicated than you'd think: >>> >> >> No it is not. I don't think "garbage in, garbage out" is a >> complicated concept. You can write pathological shit in any language >> and get meaningless results out - it has no bearing on anything in >> real code. (It can be fun to play around with, but it does not mean >> there is a problem with the language feature.) > > > And yet, in my example, lccwin32 gave the wrong result, and in one case > crashed. (I no longer have other smaller C compilers to try out.) > > It suggests the problem is not trivial. So what you are telling us is that a relatively simple and little-used compiler has bugs in dealing with pathological cases of code intentionally designed to be difficult and be far from any kind of realistic code? Are we supposed to be surprised? I'm sure the lccwin32 author will be interested in the test case, because such extreme corner-case testing is useful for finding bugs in software - but it is only of interest to him and not to anyone actually writing C code. (And in this case, since your code has UB, there is no such thing as a correct result - and therefore no possibility of a wrong result.) > > The concept is not that easy to get your head around either, the idea > that the variable aspects of a VLA are associated with its type, not its > value or instance. If you find VLA's difficult, don't use them. Even if you were interested in making your tools compliant, they are optional from C11 onwards. Since you are the only person who uses your tools, and you won't write C code with VLAs, you have nothing to lose by ignoring them entirely. > > In my example, there were no instances of any actual arrays, not even if > I declared an instance of one of the pointers involved, yet space had to > be allocated for its size. And I kept the type simple. > > I remember also trying out VLAs within a struct, and there I got a wider > variance of results. > > You can keep saying that VLAs are trivial to understand and implement; I > won't believe you. > OK. Don't believe me.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-06 13:40 -0800 |
| Message-ID | <87jzomrvh8.fsf@nosuchdomain.example.com> |
| In reply to | #379879 |
Bart <bc@freeuk.cm> writes:
[...]
> The concept is not that easy to get your head around either, the idea
> that the variable aspects of a VLA are associated with its type, not
> its value or instance.
Oh? I don't find it difficult at all. It's the kind of thing you learn
once, and then you know it. Now you know it, but you're still
complaining for some reason.
There are some complications regarding applying sizeof to a VLA type or
expression. I've cited a proposal to clean that up in a future
standard. The complications rarely affect non-contrived code.
> In my example, there were no instances of any actual arrays, not even
> if I declared an instance of one of the pointers involved, yet space
> had to be allocated for its size. And I kept the type simple.
Sure, space is allocated for the type's size. That space is implicit,
and is logically associated with the type. That seems straightforward
to me. (In fact the standard doesn't say how the size is stored, but
creating and initializing an implicit object associated with the type is
the obvious approach.)
> I remember also trying out VLAs within a struct, and there I got a
> wider variance of results.
The language does not allow VLAs within a struct; see N1570 6.7.2.1p9.
Some compilers support them as an extension. As usual, you do your
testing with a variety of *non-conforming* compilers and reach
conclusions about how inconsistent the language itself appears to be.
Most C compilers have options to tell them to attempt to conform to a
specified edition of the standard (e.g., `gcc -std=c17 -pedantic` or
`gcc -std=c17 -pedantic-errors`). I strongly suggest using those
options if you're trying to learn something about the language itself.
It will save you (and us) a lot of time.
And please don't pretend that I've said that it's a good thing that most
C compilers are non-conforming by default, and that it's (slightly)
difficult to get them to attempt to conform. I'm describing how they
work, not expressing an opinion.
> You can keep saying that VLAs are trivial to understand and implement;
> I won't believe you.
I don't recall anyone saying they're trivial. Apparently you have
trouble understanding them. Feel free to ask questions. They're not as
difficult as you want to believe them to be.
--
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-07 00:09 +0000 |
| Message-ID | <uncq37$pvae$1@dont-email.me> |
| In reply to | #379887 |
On 06/01/2024 21:40, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
> [...]
>> The concept is not that easy to get your head around either, the idea
>> that the variable aspects of a VLA are associated with its type, not
>> its value or instance.
>
> Oh? I don't find it difficult at all. It's the kind of thing you learn
> once, and then you know it. Now you know it, but you're still
> complaining for some reason.
Maybe you've never had to implement it. It is certainly not intuitive:
int n=rand();
typedef int T[n]; // here the size is stored with the type
int A[n]; // here you'd expect it with each variable
int B[n];
T C[n]; // and here in both
You might also expect the data of those variables to go on the stack.
But here:
T** P;
it presumably goes on the heap, when you get around to allocating it.
Despite all the complexity associated with VLAs (for example managing 17
active VLA allocations on the stack, and assorted VLA typedefs that are
now executable code) as you goto in and out of nested block scopes),
when you pass a VLA 'A' for example to a function, you still have to
supply the size or length separately.
With the far simpler slice mechanism that I mentioned several posts
back, that includes the length.
The reason I brought up VLAs at all was because the language skipped a
simple-to-implement and potentially more useful feature, for a much
harder one.
If I was to independently add a VLA-like feature to C, I would base it
on slices. And I would allow them only at the top level of data
structures, not nested, nor within conventional arrays, nor as a pointer
target (if the memory management is to be automatic).
They would also use heap storage not stack. And there would no dynamic
elements within typedefs; the actual size is an attribute of the
variable instance. Typedefs stay a purely compile-time artefact.
That would cover 99% of the ways that VLAs are typically used, of which
I believe a big chunk are inadvertent.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-07 00:16 +0000 |
| Message-ID | <uncqg5$pust$2@dont-email.me> |
| In reply to | #379890 |
On Sun, 7 Jan 2024 00:09:11 +0000, Bart wrote:
> typedef int T[n]; // here the size is stored with the type
>
> int A[n]; // here you'd expect it with each variable int
> B[n];
> T C[n]; // and here in both
The array size is in the wrong place. Java at least puts it in a more
natural place:
int[n] A;
... etc ...
though unfortunately it forgets to include typedefs.
Type specifications in C are all backwards, anyway. They should have
adopted the Pascal syntax for that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-06 16:40 -0800 |
| Message-ID | <87cyuern6k.fsf@nosuchdomain.example.com> |
| In reply to | #379891 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 7 Jan 2024 00:09:11 +0000, Bart wrote:
>
>> typedef int T[n]; // here the size is stored with the type
>>
>> int A[n]; // here you'd expect it with each variable int
>> B[n];
>> T C[n]; // and here in both
>
> The array size is in the wrong place. Java at least puts it in a more
> natural place:
>
> int[n] A;
> ... etc ...
>
> though unfortunately it forgets to include typedefs.
>
> Type specifications in C are all backwards, anyway. They should have
> adopted the Pascal syntax for that.
C uses a "declaration follows usage" rule (though not with 100%
consistency).
For example, a declaration like:
int *foo[42];
ultimately means "declare foo as array 42 of int" (that's what the
"cdecl" program tells you), but you can think of it as declaration that
the expression `*foo[42]` is of type int. It follows from that that
`foo[42]` is of type int*, and that `foo` is of type int *[42], or
pointer to array 42 of int.
Recall that I mentioned that it's not 100% consistent. foo[42] doesn't
exist (valid indices are 0 to 41), but the point is that it would have
type int* if it existed.
See question 1.21 of the comp.lang.c FAQ, <https://www.c-faq.com/>.
I personally agree with you that C would have been easier with a
different declaration syntax, closer to the way you'd describe it in
English, but it will never be changed in any language named "C", so
there's not much point in worrying about 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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-07 00:58 +0000 |
| Message-ID | <unct09$q65q$4@dont-email.me> |
| In reply to | #379893 |
On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote:
> C uses a "declaration follows usage" rule (though not with 100%
> consistency).
And putting the function result before the argument types turns out to
cause trouble when carried over to C++, when you try to express
dependencies between them. So they had to add a Pascal-style alternative
syntax, with the function result declared after the arguments.
Even pointer dereferencing should have been done with a postfix, not a
prefix operator. Consider why you need “->”: it’s purely syntactic sugar
to make things like
(*a).b
less awkward as
a->b
Whereas in Pascal, for example, there is no need for any alternative
syntax to
a^.b
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-07 03:30 +0000 |
| Message-ID | <20240106192622.558@kylheku.com> |
| In reply to | #379895 |
On 2024-01-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote: > >> C uses a "declaration follows usage" rule (though not with 100% >> consistency). > > And putting the function result before the argument types turns out to > cause trouble when carried over to C++, when you try to express > dependencies between them. So they had to add a Pascal-style alternative > syntax, with the function result declared after the arguments. In this millennium, you can have dependencies that flow opposite to the lexical order of tokens. C++ itself has no problem having inline function in a class declaration mutually call each other, without any forward declarations. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-07 15:48 +0100 |
| Message-ID | <unedki$13tlb$1@dont-email.me> |
| In reply to | #379895 |
On 07/01/2024 01:58, Lawrence D'Oliveiro wrote: > On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote: > >> C uses a "declaration follows usage" rule (though not with 100% >> consistency). > > And putting the function result before the argument types turns out to > cause trouble when carried over to C++, when you try to express > dependencies between them. So they had to add a Pascal-style alternative > syntax, with the function result declared after the arguments. > > Even pointer dereferencing should have been done with a postfix, not a > prefix operator. Consider why you need “->”: it’s purely syntactic sugar > to make things like > > (*a).b > > less awkward as > > a->b > > Whereas in Pascal, for example, there is no need for any alternative > syntax to > > a^.b There are two kinds of programming languages. There are ones that that exist long enough and are popular enough for people to see that the original design was not perfect and could have been done differently, and languages that die away to irrelevance before long. No one thinks the C way of doing things, or its syntax, is perfect - but a lot of people think it is good enough that they can live with it. A language has to either stick with the sub-optimal choices it made long ago, as C has done, or it can try to make changes and suffers from having to support new and old ideas, as C++ has done. Each technique has its advantages and disadvantages.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-07 15:34 +0000 |
| Message-ID | <unegb1$148mk$2@dont-email.me> |
| In reply to | #379910 |
On 07/01/2024 14:48, David Brown wrote:
> On 07/01/2024 01:58, Lawrence D'Oliveiro wrote:
>> On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote:
>>
>>> C uses a "declaration follows usage" rule (though not with 100%
>>> consistency).
>>
>> And putting the function result before the argument types turns out to
>> cause trouble when carried over to C++, when you try to express
>> dependencies between them. So they had to add a Pascal-style alternative
>> syntax, with the function result declared after the arguments.
>>
>> Even pointer dereferencing should have been done with a postfix, not a
>> prefix operator. Consider why you need “->”: it’s purely syntactic sugar
>> to make things like
>>
>> (*a).b
>>
>> less awkward as
>>
>> a->b
>>
>> Whereas in Pascal, for example, there is no need for any alternative
>> syntax to
>>
>> a^.b
>
> There are two kinds of programming languages. There are ones that that
> exist long enough and are popular enough for people to see that the
> original design was not perfect and could have been done differently,
> and languages that die away to irrelevance before long. No one thinks
> the C way of doing things, or its syntax, is perfect - but a lot of
> people think it is good enough that they can live with it.
>
> A language has to either stick with the sub-optimal choices it made long
> ago, as C has done, or it can try to make changes and suffers from
> having to support new and old ideas, as C++ has done. Each technique
> has its advantages and disadvantages.
I used to have that a^.b syntax (deref pointer then index).
But for a few years I've relaxed that so that the deref is done
automatically:
a^.b becomes a.b
a^[b] becomes a[b]
a^(b) becomes a(b)
AFAICS, C can could also relax the (*a).b or a->b synax so that you just
do a.b. You could do that today, and nothing changes. (Of course it
would need a compiler update).
The others don't affect C so much: pointers to arrays, that would
require (*a)[i], are rarely used. Everybody uses a[i] anyway with 'a'
being a pointer to the first element.
And it already allows, via some mysterious rules, for (*a)(b) to be
written as a(b).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-08 13:50 +0100 |
| Message-ID | <ungr21$1hleq$1@dont-email.me> |
| In reply to | #379912 |
On 07/01/2024 16:34, Bart wrote: > On 07/01/2024 14:48, David Brown wrote: >> On 07/01/2024 01:58, Lawrence D'Oliveiro wrote: >>> On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote: >>> >>>> C uses a "declaration follows usage" rule (though not with 100% >>>> consistency). >>> >>> And putting the function result before the argument types turns out to >>> cause trouble when carried over to C++, when you try to express >>> dependencies between them. So they had to add a Pascal-style alternative >>> syntax, with the function result declared after the arguments. >>> >>> Even pointer dereferencing should have been done with a postfix, not a >>> prefix operator. Consider why you need “->”: it’s purely syntactic sugar >>> to make things like >>> >>> (*a).b >>> >>> less awkward as >>> >>> a->b >>> >>> Whereas in Pascal, for example, there is no need for any alternative >>> syntax to >>> >>> a^.b >> >> There are two kinds of programming languages. There are ones that >> that exist long enough and are popular enough for people to see that >> the original design was not perfect and could have been done >> differently, and languages that die away to irrelevance before long. >> No one thinks the C way of doing things, or its syntax, is perfect - >> but a lot of people think it is good enough that they can live with it. >> >> A language has to either stick with the sub-optimal choices it made >> long ago, as C has done, or it can try to make changes and suffers >> from having to support new and old ideas, as C++ has done. Each >> technique has its advantages and disadvantages. > > I used to have that a^.b syntax (deref pointer then index). > > But for a few years I've relaxed that so that the deref is done > automatically: > > a^.b becomes a.b > a^[b] becomes a[b] > a^(b) becomes a(b) > > AFAICS, C can could also relax the (*a).b or a->b synax so that you just > do a.b. You could do that today, and nothing changes. (Of course it > would need a compiler update). You could, in the sense that (AFAICS) there would be no situation where in code today "a.b" and "a->b" were both syntactically and semantically correct but meant different things. Then you could have a compiler treat the syntax or constraint error "a.b" as intending to mean "a->b". I don't think it would be a good idea - I think it just adds confusion because you easily lose track of what are structs and what are pointers to structs. I'd rather it be an error when you get these wrong in the code. I remember from programming in Delphi (and Borland Object Pascal) it could often be hard to figure out what was a pointer to an object, and what was a "real" object, since dereferencing was automatic in some circumstances. My personal preference is either to say that everything is always a reference (like Python), or everything is always a value (like C) and do the dereferencing explicitly. Other people make think such automatic dereferencing is a good idea, but I personally don't. > > The others don't affect C so much: pointers to arrays, that would > require (*a)[i], are rarely used. Everybody uses a[i] anyway with 'a' > being a pointer to the first element. > > And it already allows, via some mysterious rules, for (*a)(b) to be > written as a(b). > Think of it rather as C allows you to write function calls like "foo(x)", and that considering function names as being function pointers is a natural view that is easy to implement in compilers and keeps the C to assembly conversion as lean as possible - it means "foo" is the address of the function, rather than being the function itself. Being able to write "foo(x)" as "(*foo)(x)" is just a byproduct of this - it would need extra rules added to C to disallow it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-08 15:53 +0000 |
| Message-ID | <unh5p4$1j81h$1@dont-email.me> |
| In reply to | #379923 |
On 08/01/2024 12:50, David Brown wrote:
> On 07/01/2024 16:34, Bart wrote:
>> I used to have that a^.b syntax (deref pointer then index).
>>
>> But for a few years I've relaxed that so that the deref is done
>> automatically:
>>
>> a^.b becomes a.b
>> a^[b] becomes a[b]
>> a^(b) becomes a(b)
>>
>> AFAICS, C can could also relax the (*a).b or a->b synax so that you
>> just do a.b. You could do that today, and nothing changes. (Of course
>> it would need a compiler update).
>
> You could, in the sense that (AFAICS) there would be no situation where
> in code today "a.b" and "a->b" were both syntactically and semantically
> correct but meant different things. Then you could have a compiler
> treat the syntax or constraint error "a.b" as intending to mean "a->b".
>
> I don't think it would be a good idea - I think it just adds confusion
> because you easily lose track of what are structs and what are pointers
> to structs.
Yet this is exactly what happens with those other examples: you don't
know if the X in X[i] has type T[] or T*. (The use of (*X)[i] when X is
of type T(*)[] is rare.)
And you don't know if the F in F(x) is an actual function, or a pointer
to a function.
The "->" alternate is anyway a little strange:
(*P).m can be written as P->m
(**Q).m can only be reduced to (*Q)->m
So it only works on the last lot of indirection. There is also no
euivalent of just (*P), "->" needs to specify a member name as it
combines two operations.
> I'd rather it be an error when you get these wrong in the
> code.
I had the same misgivings: there is a loss of transparency, but after I
started using the auto-deref, the benefits outweighed that:
Code was remarkably free of clutter. (And in my case, I had sections of
code that could often be ported as-is to/from my other language that
didn't need those derefs.)
> My personal preference is either to say that everything
> is always a reference (like Python), or everything is always a value
> (like C) and do the dereferencing explicitly. Other people make think
> such automatic dereferencing is a good idea, but I personally don't.
This can occur with reference parameters too: I believe you get the same
thing in C++.
>>
>> The others don't affect C so much: pointers to arrays, that would
>> require (*a)[i], are rarely used. Everybody uses a[i] anyway with 'a'
>> being a pointer to the first element.
>>
>> And it already allows, via some mysterious rules, for (*a)(b) to be
>> written as a(b).
>>
>
> Think of it rather as C allows you to write function calls like
> "foo(x)", and that considering function names as being function pointers
> is a natural view that is easy to implement in compilers and keeps the C
> to assembly conversion as lean as possible - it means "foo" is the
> address of the function, rather than being the function itself. Being
> able to write "foo(x)" as "(*foo)(x)" is just a byproduct of this - it
> would need extra rules added to C to disallow it.
It's worse than that. Given an actual function:
void F(void){}
all of these calls are valid:
(&F)();
F();
(*F)();
(**F)();
(***F)();
(****F)(); // etc
across the half-dozen compilers I tried. Except for my 'mcc' which only
allows up to (*F), and not (**F)() or beyond. I just thought it was silly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-08 20:50 +0100 |
| Message-ID | <unhjme$1ld24$1@dont-email.me> |
| In reply to | #379926 |
On 08/01/2024 16:53, Bart wrote:
> On 08/01/2024 12:50, David Brown wrote:
>> On 07/01/2024 16:34, Bart wrote:
>
>>> I used to have that a^.b syntax (deref pointer then index).
>>>
>>> But for a few years I've relaxed that so that the deref is done
>>> automatically:
>>>
>>> a^.b becomes a.b
>>> a^[b] becomes a[b]
>>> a^(b) becomes a(b)
>>>
>>> AFAICS, C can could also relax the (*a).b or a->b synax so that you
>>> just do a.b. You could do that today, and nothing changes. (Of course
>>> it would need a compiler update).
>>
>> You could, in the sense that (AFAICS) there would be no situation
>> where in code today "a.b" and "a->b" were both syntactically and
>> semantically correct but meant different things. Then you could have
>> a compiler treat the syntax or constraint error "a.b" as intending to
>> mean "a->b".
>>
>> I don't think it would be a good idea - I think it just adds confusion
>> because you easily lose track of what are structs and what are
>> pointers to structs.
>
> Yet this is exactly what happens with those other examples: you don't
> know if the X in X[i] has type T[] or T*. (The use of (*X)[i] when X is
> of type T(*)[] is rare.)
>
> And you don't know if the F in F(x) is an actual function, or a pointer
> to a function.
>
> The "->" alternate is anyway a little strange:
>
> (*P).m can be written as P->m
> (**Q).m can only be reduced to (*Q)->m
>
> So it only works on the last lot of indirection. There is also no
> euivalent of just (*P), "->" needs to specify a member name as it
> combines two operations.
Yes, the short-cut only works for the (by far) most common case.
>
>> I'd rather it be an error when you get these wrong in the code.
>
> I had the same misgivings: there is a loss of transparency, but after I
> started using the auto-deref, the benefits outweighed that:
>
> Code was remarkably free of clutter. (And in my case, I had sections of
> code that could often be ported as-is to/from my other language that
> didn't need those derefs.)
>
I didn't like automatic dereferencing (but I could live with it -
overall I found Delphi a very productive tool). But that's a
preference, and it is no surprise that other people have different
preferences.
>> My personal preference is either to say that everything is always a
>> reference (like Python), or everything is always a value (like C) and
>> do the dereferencing explicitly. Other people make think such
>> automatic dereferencing is a good idea, but I personally don't.
>
> This can occur with reference parameters too: I believe you get the same
> thing in C++.
Not quite - that's an easy and common misunderstanding. (It is even
more understandable for you, since your language uses "ref" to mean what
is called a "pointer" in C and C++.) References in C++ are not
"auto-dereferenced pointers" - they are alternative names for objects.
It is better to think of references as being ways to identify objects,
and pointers as being indirect references. C++ references are /not/
pointers.
>
>
>>>
>>> The others don't affect C so much: pointers to arrays, that would
>>> require (*a)[i], are rarely used. Everybody uses a[i] anyway with 'a'
>>> being a pointer to the first element.
>>>
>>> And it already allows, via some mysterious rules, for (*a)(b) to be
>>> written as a(b).
>>>
>>
>> Think of it rather as C allows you to write function calls like
>> "foo(x)", and that considering function names as being function
>> pointers is a natural view that is easy to implement in compilers and
>> keeps the C to assembly conversion as lean as possible - it means
>> "foo" is the address of the function, rather than being the function
>> itself. Being able to write "foo(x)" as "(*foo)(x)" is just a
>> byproduct of this - it would need extra rules added to C to disallow it.
>
> It's worse than that.
No, it's not worse - it's just a side-effect of the convenience of
notation. Disallowing some of the forms you show below would require
extra rules, adding complication to the standards, while allowing them
is harmless (since people would not use them in code).
> Given an actual function:
>
> void F(void){}
>
> all of these calls are valid:
>
> (&F)();
> F();
> (*F)();
> (**F)();
> (***F)();
> (****F)(); // etc
>
> across the half-dozen compilers I tried. Except for my 'mcc' which only
> allows up to (*F), and not (**F)() or beyond. I just thought it was silly.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-09 01:05 +0000 |
| Message-ID | <uni64g$1nrsb$1@dont-email.me> |
| In reply to | #379936 |
On 08/01/2024 19:50, David Brown wrote:
> On 08/01/2024 16:53, Bart wrote:
>> This can occur with reference parameters too: I believe you get the
>> same thing in C++.
>
> Not quite - that's an easy and common misunderstanding. (It is even
> more understandable for you, since your language uses "ref" to mean what
> is called a "pointer" in C and C++.) References in C++ are not
> "auto-dereferenced pointers" - they are alternative names for objects.
> It is better to think of references as being ways to identify objects,
> and pointers as being indirect references. C++ references are /not/
> pointers.
They look like auto-dereferenced pointers to me:
---------------------------
#include <stdio.h>
void F1(int a) {a = a + 1;}
void F2(int* a) {*a = *a + 1;}
void F3(int &a) {a = a + 1;}
int main(void) {
int a=100, b=200, c=300;
F1(a);
F2(&b);
F3(c);
printf("a = %d, b = %d, c = %d\n", a, b, c);
}
---------------------------
This is C code except for F3 and the call to it. It was compiled as C++.
The output expected is '100 201 301'. F1 can't modify its caller's data.
F2 can do so via explicit pointers. F3 does it via references.
But notice the body of F3 is identical to F1's; and so is the passed
argument (doesn't need &).
You get the same behaviour as using pointers, but without explicit
address-of ops on arguments, and deref ops on parameters.
But also, there is that same hidden deref so that you can't tell exactly
what's going on unles you see that & in the argument list.
My languages use the same & in the argument list to indicate by-reference.
>> It's worse than that.
>
> No, it's not worse - it's just a side-effect of the convenience of
> notation. Disallowing some of the forms you show below would require
> extra rules, adding complication to the standards,
My MCC compiler seems to manage it (I'm not sure how), and my main
compiler does even better: you can't even do the equivalent of (*F)(),
because F is not a pointer to anything and can't be dereferenced.
(Yes, F by itself is still equal to &F, but not F().)
Whatever extra rules or logic are involved, they are insignificant
compared to those for VLAs, or for mixed sign arithmetic, for the
minimum groupings of {} around init data, or the algorithm for searching
for includes files, ...
> while allowing them
> is harmless (since people would not use them in code).
I suggested using .len on my unbounded arrays were harmless because they
wouldn't be used; you disagreed...
It just looks sloppy to me that you can effectively dereference
something an unlimited number of times; where is the type system in this?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-09 08:30 +0100 |
| Message-ID | <unislv$1u3j0$1@dont-email.me> |
| In reply to | #379939 |
On 09/01/2024 02:05, Bart wrote:
> On 08/01/2024 19:50, David Brown wrote:
>> On 08/01/2024 16:53, Bart wrote:
>
>>> This can occur with reference parameters too: I believe you get the
>>> same thing in C++.
>>
>> Not quite - that's an easy and common misunderstanding. (It is even
>> more understandable for you, since your language uses "ref" to mean
>> what is called a "pointer" in C and C++.) References in C++ are not
>> "auto-dereferenced pointers" - they are alternative names for objects.
>> It is better to think of references as being ways to identify objects,
>> and pointers as being indirect references. C++ references are /not/
>> pointers.
>
> They look like auto-dereferenced pointers to me:
>
I know they look like that at first glance, but they are not
auto-dereferenced pointers. It can sometimes be useful to understand
that when you move references around (such as for function parameters),
they are implemented as though they were a special kind of pointer -
that tells you how efficient they are. But conceptually, for their use
and understanding, I don't think it is helpful.
>
>>> It's worse than that.
>>
>> No, it's not worse - it's just a side-effect of the convenience of
>> notation. Disallowing some of the forms you show below would require
>> extra rules, adding complication to the standards,
>
> My MCC compiler seems to manage it (I'm not sure how), and my main
> compiler does even better: you can't even do the equivalent of (*F)(),
> because F is not a pointer to anything and can't be dereferenced.
How is that in any way "better"? You have gone out of your way to make
your compiler non-conforming for the sake of stopping something no one
would ever write? It all sounds a bit pointless (but harmless) to me.
>
> (Yes, F by itself is still equal to &F, but not F().)
>
> Whatever extra rules or logic are involved, they are insignificant
> compared to those for VLAs, or for mixed sign arithmetic, for the
> minimum groupings of {} around init data, or the algorithm for searching
> for includes files, ...
Whataboutism is a strong sign that the person arguing has lost track of
their point.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-09 11:11 +0000 |
| Message-ID | <unj9l0$1vr6j$1@dont-email.me> |
| In reply to | #379944 |
On 09/01/2024 07:30, David Brown wrote:
> On 09/01/2024 02:05, Bart wrote:
>> On 08/01/2024 19:50, David Brown wrote:
>>> On 08/01/2024 16:53, Bart wrote:
>>
>>>> This can occur with reference parameters too: I believe you get the
>>>> same thing in C++.
>>>
>>> Not quite - that's an easy and common misunderstanding. (It is even
>>> more understandable for you, since your language uses "ref" to mean
>>> what is called a "pointer" in C and C++.) References in C++ are not
>>> "auto-dereferenced pointers" - they are alternative names for
>>> objects. It is better to think of references as being ways to
>>> identify objects, and pointers as being indirect references. C++
>>> references are /not/ pointers.
>>
>> They look like auto-dereferenced pointers to me:
>>
>
> I know they look like that at first glance, but they are not
> auto-dereferenced pointers. It can sometimes be useful to understand
> that when you move references around (such as for function parameters),
> they are implemented as though they were a special kind of pointer -
> that tells you how efficient they are. But conceptually, for their use
> and understanding, I don't think it is helpful.
>
>>
>>>> It's worse than that.
>>>
>>> No, it's not worse - it's just a side-effect of the convenience of
>>> notation. Disallowing some of the forms you show below would require
>>> extra rules, adding complication to the standards,
>>
>> My MCC compiler seems to manage it (I'm not sure how), and my main
>> compiler does even better: you can't even do the equivalent of (*F)(),
>> because F is not a pointer to anything and can't be dereferenced.
>
> How is that in any way "better"? You have gone out of your way to make
> your compiler non-conforming for the sake of stopping something no one
> would ever write? It all sounds a bit pointless (but harmless) to me.
>
>>
>> (Yes, F by itself is still equal to &F, but not F().)
>>
>> Whatever extra rules or logic are involved, they are insignificant
>> compared to those for VLAs, or for mixed sign arithmetic, for the
>> minimum groupings of {} around init data, or the algorithm for
>> searching for includes files, ...
>
> Whataboutism is a strong sign that the person arguing has lost track of
> their point.
Not at all. You are defending some crazy anomaly, that you find nowhere
else, for some insubstantial reason.
It works like that because the language was poorly designed in the first
place and nobody thought it worthwhile fixing it.
So it's just another quirk.
I quite like the idea that if you want to do *X, then it better have a
type like T*. Then the result of *X, ie. dereferencing X, will be T.
Now C does something odd: if T happens to be a function type, it
immediately turns that result back into *T.
I used to have some rules (not in C but expressed as C) where, if F is
an actual function and has function type:
Type Action
&F func* Evaluate function reference
F func Same as F()
F(...) func Call the function (yielding func ret type)
*F --- Error, not a pointer
I changed that to be more C-like: I always need () to call the function
even if there are no arguments, while F and &F are equivalent.
This required an extra bit of logic. As far as explaining it goes:
&F func* Evaluate function reference
F func* Evaluate function reference
F(...) func Call the function
*F --- Error, not a pointer
It's not that hard, it just introduced one small anomaly where F and F&
are the same.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-09 15:56 +0100 |
| Message-ID | <unjmqs$21nsj$1@dont-email.me> |
| In reply to | #379946 |
On 09/01/2024 12:11, Bart wrote:
> On 09/01/2024 07:30, David Brown wrote:
>> On 09/01/2024 02:05, Bart wrote:
>>> On 08/01/2024 19:50, David Brown wrote:
>>>> On 08/01/2024 16:53, Bart wrote:
>>>
>>>>> This can occur with reference parameters too: I believe you get the
>>>>> same thing in C++.
>>>>
>>>> Not quite - that's an easy and common misunderstanding. (It is even
>>>> more understandable for you, since your language uses "ref" to mean
>>>> what is called a "pointer" in C and C++.) References in C++ are not
>>>> "auto-dereferenced pointers" - they are alternative names for
>>>> objects. It is better to think of references as being ways to
>>>> identify objects, and pointers as being indirect references. C++
>>>> references are /not/ pointers.
>>>
>>> They look like auto-dereferenced pointers to me:
>>>
>>
>> I know they look like that at first glance, but they are not
>> auto-dereferenced pointers. It can sometimes be useful to understand
>> that when you move references around (such as for function
>> parameters), they are implemented as though they were a special kind
>> of pointer - that tells you how efficient they are. But conceptually,
>> for their use and understanding, I don't think it is helpful.
>>
>>>
>>>>> It's worse than that.
>>>>
>>>> No, it's not worse - it's just a side-effect of the convenience of
>>>> notation. Disallowing some of the forms you show below would
>>>> require extra rules, adding complication to the standards,
>>>
>>> My MCC compiler seems to manage it (I'm not sure how), and my main
>>> compiler does even better: you can't even do the equivalent of
>>> (*F)(), because F is not a pointer to anything and can't be
>>> dereferenced.
>>
>> How is that in any way "better"? You have gone out of your way to
>> make your compiler non-conforming for the sake of stopping something
>> no one would ever write? It all sounds a bit pointless (but harmless)
>> to me.
>>
>>>
>>> (Yes, F by itself is still equal to &F, but not F().)
>>>
>>> Whatever extra rules or logic are involved, they are insignificant
>>> compared to those for VLAs, or for mixed sign arithmetic, for the
>>> minimum groupings of {} around init data, or the algorithm for
>>> searching for includes files, ...
>>
>> Whataboutism is a strong sign that the person arguing has lost track
>> of their point.
>
> 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.
>
> It works like that because the language was poorly designed in the first
> place and nobody thought it worthwhile fixing it.
It works like that because the language was /well/ designed, for its
purpose at the time, with the requirements and limitations of the time.
Remember, as you always seem to forget, C was not designed with the sole
purpose of making /your/ life as easy as possible, or suiting /your/
particular preferences. The "(***foo)" anomaly is a side-effect of the
way functions work in C. Leaving it in costs nothing, removing it would
be an effort and an inconvenience.
Do you /really/ think that, if this were important, no one would have
suggested disallowing it? Do you /really/ think that, if this were
leading to poor code, misunderstandings or mistakes, that compiler
writers would not be able to add warnings about it? Do you /really/
think you are so vastly superior to everyone else in the C world that
you alone see the problem?
Sometimes you are like that old joke of the guy driving the wrong way
down the motorway, complaining that everyone else is wrong.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-09 17:46 +0000 |
| Message-ID | <unk0q8$23dum$1@dont-email.me> |
| In reply to | #379947 |
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?
>>
>> It works like that because the language was poorly designed in the
>> first place and nobody thought it worthwhile fixing it.
>
> It works like that because the language was /well/ designed, for its
> purpose at the time, with the requirements and limitations of the time.
Poppycock.
What limitations were there? These were people who were well funded to
do exactly this work, and had decent equipment like DEC minicomputers to
work with.
My language a decade later was done in my spare time on an 8-bit
machine. There was no funding for that, and I wasn't an academic.
But it didn't the same plethora of quirks as C. Most languages don't.
> Remember, as you always seem to forget, C was not designed with the sole
> purpose of making /your/ life as easy as possible, or suiting /your/
> particular preferences. The "(***foo)" anomaly is a side-effect of the
> way functions work in C. Leaving it in costs nothing, removing it would
> be an effort and an inconvenience.
Really? I didn't have much trouble.
> Do you /really/ think that, if this were important, no one would have
> suggested disallowing it? Do you /really/ think that, if this were
> leading to poor code, misunderstandings or mistakes, that compiler
> writers would not be able to add warnings about it? Do you /really/
> think you are so vastly superior to everyone else in the C world that
> you alone see the problem?
>
> Sometimes you are like that old joke of the guy driving the wrong way
> down the motorway, complaining that everyone else is wrong.
Would you design a language like that today?
I could list dozens of howlers within the language.
I've long thought that C was an elaborate joke that escaped from the
lab. Possibly it is, and no one has yet owned up to it.
But people actually take it seriously and even defend all this stuff.
YOU would be the guy driving along the motorway in a Model T Ford,
backed up by a 40-foot truck containing all the advanced equipment
needed to work around all its shortcomings.
Behind them would be a further fleet of trucks containing the
environment that you insist on being available.
Oh, sorry, I forgot that in 2023 it acquired new door handles. Yeah,
that makes a difference.
[toc] | [prev] | [next] | [standalone]
Page 8 of 34 — ← Prev page 1 … 6 7 [8] 9 10 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web