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 27 of 34 — ← Prev page 1 … 25 26 [27] 28 29 … 34 Next page →
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-09 21:51 +0000 |
| Message-ID | <20240109133844.806@kylheku.com> |
| In reply to | #379954 |
On 2024-01-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Kaz Kylheku <433-929-6894@kylheku.com> writes: >> On 2024-01-09, Bart <bc@freeuk.cm> wrote: >>> Now C does something odd: if T happens to be a function type, it >>> immediately turns that result back into *T. >> >> That's one way to have distinct concepts of function type and pointer to >> that type, while preserving most the assembly language semantics of >> working with functions as addresses. > > On my x86_64 system with gcc, these lines of C: > func(); > funcptr(); > result in these call instructions: > call func > call *%rdx That's a silly quirk of AT&T syntax; not reflected in the Intel one: See here: https://en.wikipedia.org/wiki/Indirect_branch#Example_assembler_syntax It looks as if what *%rdx is doing is fetching an address from the location pointed at by rdx, and then jumping to that address. Most of the other examples in that Wikipedia page have any superfluous operator syntax on the operand suggesting extra indirection. -- 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 | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-09 01:50 +0000 |
| Message-ID | <20240108173650.821@kylheku.com> |
| In reply to | #379936 |
On 2024-01-08, David Brown <david.brown@hesbynett.no> wrote: > 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. There is no way to distinguish a C++ reference from an "auto-dereferenced pointer", though. Importantly, an "auto-dereferenced *constant* pointer". References behave like aliases only in a lexical scope. In a lexical scope, pointer variables can also disappear, particularly ones that are initialized and never modified. int a = 0, *const pa = &a; #define b (*pa) b now behaves like another name for a. The compiler can replace every *pa with b. References in other situations are necessarily real objects that hold a pointer-like address. int &ref = *new int; // ... delete &ref; The ref entity is definitely not just an alias name. The name "ref" doesn't even exist at run time. "ref" is the compile-time name of a reference, and that reference is an entity that is somehow bound to the object from operator new. That binding of ref to the allocated object requires a pointer-like entity. What comes out of new is a pointer, and what must go into delete is a pointer. What carries it in between those is carrying a pointer, and we can get one out of it using the address-of operator. -- 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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-08 22:28 -0800 |
| Message-ID | <86il43m35l.fsf@linuxsc.com> |
| In reply to | #379940 |
Kaz Kylheku <433-929-6894@kylheku.com> writes: > There is no way to distinguish a C++ reference from an > "auto-dereferenced pointer", though. [...] Right. The C++ standard would have us believe a fiction that a reference is not just an auto-dereferenced pointer. It's an excellent example of the fantasy world in which the C++ standard operates.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-09 07:38 +0000 |
| Message-ID | <unit6c$1u62v$1@dont-email.me> |
| In reply to | #379923 |
On Mon, 8 Jan 2024 13:50:08 +0100, David Brown wrote:
> 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.
Ada tries to pretend there is no difference. There is mostly no ambiguity,
except potentially in something like
a := b;
where “a” and “b” are both pointers to some common type. In this case, the
meaning is not to dereference the pointers; to force a dereference, you
write
a.all := b.all;
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-07 02:12 +0100 |
| Message-ID | <unctp4$qclb$1@dont-email.me> |
| In reply to | #379891 |
On 07.01.2024 01:16, Lawrence D'Oliveiro wrote:
> 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.
You mean that the poster has a misconception about the declaration
mapping to the actual formal semantics? (That might at least explain
why he's confused by the C way.)
> Java at least puts it in a more natural place:
>
> int[n] A;
> ... etc ...
Or Algol(68) that I upthread mentioned for its formal sophistication
[n] int A;
>
> though unfortunately it forgets to include typedefs.
where Algol has 'mode' declarations for types
mode intarr = [n] int A;
>
> Type specifications in C are all backwards, anyway. They should have
> adopted the Pascal syntax for that.
Or any other [more] coherent language already existing at that time.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-07 01:45 +0000 |
| Message-ID | <uncvn6$qjr4$1@dont-email.me> |
| In reply to | #379897 |
On 07/01/2024 01:12, Janis Papanagnou wrote:
> On 07.01.2024 01:16, Lawrence D'Oliveiro wrote:
>> 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.
>
> You mean that the poster has a misconception about the declaration
> mapping to the actual formal semantics? (That might at least explain
> why he's confused by the C way.)
There was nothing wrong with the C code. (The quote has garbled the
'int' belong to B.)
LD'O is saying the C syntax puts it in the wrong place.
>> Java at least puts it in a more natural place:
>>
>> int[n] A;
>> ... etc ...
>
> Or Algol(68) that I upthread mentioned for its formal sophistication
>
> [n] int A;
>
>>
>> though unfortunately it forgets to include typedefs.
>
> where Algol has 'mode' declarations for types
>
> mode intarr = [n] int A;
Interesting. My syntax uses:
[n]int A
type intarr = [n]int A
But then it came from Algol 68 in the first place. However, that
language also got some things wrong. Eg. your example might be written
as '[n]INT a;' due to 'stropping'.
Notice my version uses a single case, and there are no semicolons. The
Algol68 rules for semicolons, which separate statements not terminate,
are a complete PITA.
You spend half your time special-casing the last statement in a block,
as that's the one without the semicolon - until you insert, delete,
move, comment or uncomment lines, then you have to fix it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-07 01:47 +0000 |
| Message-ID | <uncvra$qjr4$2@dont-email.me> |
| In reply to | #379900 |
On 07/01/2024 01:45, Bart wrote:
> On 07/01/2024 01:12, Janis Papanagnou wrote:
>> On 07.01.2024 01:16, Lawrence D'Oliveiro wrote:
>>> 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.
>>
>> You mean that the poster has a misconception about the declaration
>> mapping to the actual formal semantics? (That might at least explain
>> why he's confused by the C way.)
>
> There was nothing wrong with the C code. (The quote has garbled the
> 'int' belong to B.)
>
> LD'O is saying the C syntax puts it in the wrong place.
>
>>> Java at least puts it in a more natural place:
>>>
>>> int[n] A;
>>> ... etc ...
>>
>> Or Algol(68) that I upthread mentioned for its formal sophistication
>>
>> [n] int A;
>>
>>>
>>> though unfortunately it forgets to include typedefs.
>>
>> where Algol has 'mode' declarations for types
>>
>> mode intarr = [n] int A;
>
> Interesting. My syntax uses:
>
> [n]int A
> type intarr = [n]int A
I was blindly copying your example. There is no 'A' in the type
definition, it is just:
type intarr = [n]int
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-07 02:16 +0000 |
| Message-ID | <und1hj$qmhu$4@dont-email.me> |
| In reply to | #379897 |
On Sun, 7 Jan 2024 02:12:03 +0100, Janis Papanagnou wrote:
> Or Algol(68) that I upthread mentioned for its formal sophistication
>
> [n] int A;
And for added fun, the distinction between
[m, n] INT
and
[m][n] INT
(using capitalization to indicate bold)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-06 17:15 -0800 |
| Message-ID | <878r52rljn.fsf@nosuchdomain.example.com> |
| In reply to | #379890 |
Bart <bc@freeuk.cm> writes:
> 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:
No, I haven't. I worked on compilers in the distant past (for Ada,
which doesn't distinguish on the language level between array with
constant and non-constant bounds), but I haven't implemented VLAs for C.
We were talking about the fact that, as you say, "variable aspects of a
VLA are associated with its type, not its value or instance". Are you
saying that makes implementing it unreasonably difficult?
> int n=rand();
>
> typedef int T[n]; // here the size is stored with the type
Yes, of course it is. And keep in mind that typedef doesn't create a
new type. A compiler will create, at compile time, some internal node
(or whatever data structure it uses) representing the anonymous type
`int[n]`, and will associate an implicitly created automatic object with
it to hold its length or size. It will then create a node representing
the typedef T, referring to the anonymous array type.
> int A[n]; // here you'd expect it with each variable
Why would you expect that?
I'd expect a compiler to create an internal node representing an
anonymous type int[n], and another representing an object A of that
type. The size information is associated with the type.
Since there's just one object of that type, *maybe* a compiler could
associate the size information with the variable, but I don't see the
point of doing so.
> int B[n];
Same thing again. The int[n] for A and the int[n] for B are distinct
but compatible types. (If the value of n changed between the two
declarations, the types would be distinct and incompatible.)
> T C[n]; // and here in both
n is evaluated again and stored somewhere.
> You might also expect the data of those variables to go on the
> stack.
Of course. Everything so far is defined at block scope (VLAs at file
scope are not allowed) and so has automatic static duration.
Informally, its allocated on the stack.
> But here:
>
> T** P;
>
> it presumably goes on the heap, when you get around to allocating it.
If you allocate using malloc(), of course it goes on the heap. There's
no implicit heap allocation. P itself is on the stack. Whatever P
points to is allocated where *you* choose to allocate it.
Is any of this surprising?
> 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.
Sure.
> With the far simpler slice mechanism that I mentioned several posts
> back, that includes the length.
Good for you. C doesn't have slices. Should it have them? Maybe, I
don't know. As I've discussed here recently, adding features to C is
genuinely difficult.
And if you have std::vector you don't need VLAs or slices. If you use a
language other than C, you can avoid C's limitations.
But remind me, this is comp.lang.what?
--
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 02:25 +0000 |
| Message-ID | <und22o$qs4c$1@dont-email.me> |
| In reply to | #379898 |
On 07/01/2024 01:15, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
>> 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:
>
> No, I haven't. I worked on compilers in the distant past (for Ada,
> which doesn't distinguish on the language level between array with
> constant and non-constant bounds), but I haven't implemented VLAs for C.
>
> We were talking about the fact that, as you say, "variable aspects of a
> VLA are associated with its type, not its value or instance". Are you
> saying that makes implementing it unreasonably difficult?
It makes it bizarre. It would make a typedef involving a VLA type
something to be executed at runtime; it is executable code.
>
>> int n=rand();
>>
>> typedef int T[n]; // here the size is stored with the type
>
> Yes, of course it is. And keep in mind that typedef doesn't create a
> new type. A compiler will create, at compile time, some internal node
> (or whatever data structure it uses) representing the anonymous type
> `int[n]`, and will associate an implicitly created automatic object with
> it to hold its length or size. It will then create a node representing
> the typedef T, referring to the anonymous array type.
>
>> int A[n]; // here you'd expect it with each variable
>
> Why would you expect that?
Why would expect it to be part of some anonymous, associated type?
If you had a counted string type, would you expect its length to be part
of the data belonging to the object, and or part of a separate type object?
You might call it metadata, but being a type doesn't come to mind. What
would be the point of that; what could you do with that type?
Suppose you had a counted string variable S, currently set to "ABC" so
that its length (which you say is naturally part its type) is 3.
Assume you could somehow do this:
typeof(S) T
would you expect T to also have a length 3? What would the string contain?
It doesn't make sense. But you say that's how VLAs work:
int A[rand()];
typeof(A) B;
B has the same length as A, whatever that is.
> And if you have std::vector you don't need VLAs or slices. If you use a
> language other than C, you can avoid C's limitations.
Can a std::vector also be a view? If not then you still need slices.
However when I looked at std::vector, it was basically a pointer,
length, and capacity. My slices were pointer and length. Capacity was
something I'd thought about.
Automatic memory management however would complicate matters greatly.
This language (whether C or my own) is lower level and generally explicit.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-06 19:28 -0800 |
| Message-ID | <874jfpstyc.fsf@nosuchdomain.example.com> |
| In reply to | #379904 |
Bart <bc@freeuk.cm> writes:
> On 07/01/2024 01:15, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>>> 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:
>> No, I haven't. I worked on compilers in the distant past (for Ada,
>> which doesn't distinguish on the language level between array with
>> constant and non-constant bounds), but I haven't implemented VLAs for C.
>> We were talking about the fact that, as you say, "variable aspects
>> of a
>> VLA are associated with its type, not its value or instance". Are you
>> saying that makes implementing it unreasonably difficult?
>
> It makes it bizarre. It would make a typedef involving a VLA type
> something to be executed at runtime; it is executable code.
Sure. A VLA type specifier like `int[n]` or `int[rand()%10+1]` involves
evaluating the (non-constant) expression that specifies the length. Of
course that requires executable code, whether it's part of a typedef or
part of an object definition. I don't understand why you find that
bizarre.
>>> int n=rand();
>>>
>>> typedef int T[n]; // here the size is stored with the type
>> Yes, of course it is. And keep in mind that typedef doesn't create
>> a
>> new type. A compiler will create, at compile time, some internal node
>> (or whatever data structure it uses) representing the anonymous type
>> `int[n]`, and will associate an implicitly created automatic object with
>> it to hold its length or size. It will then create a node representing
>> the typedef T, referring to the anonymous array type.
>>
>>> int A[n]; // here you'd expect it with each variable
>> Why would you expect that?
>
> Why would expect it to be part of some anonymous, associated type?
>
> If you had a counted string type, would you expect its length to be
> part of the data belonging to the object, and or part of a separate
> type object?
If a language considers "array of 10 ints" and "array of 20 ints" to be
the same type, I suppose I'd expect the length information to be
associated with an object. The type would just be "array of int".
If they're different types, as they are in C, I'd expect that
information to be associated with the type. If I have 123 objects of
type "array of 10 ints", there's no reason for the compiler to store the
value 10 123 times in its internal symbol table.
And if I have:
int n = 10;
typedef int vla[10];
vla twod_array[123];
then there's no need to store the value 10 separately for each of the
123 elements of `twod_array`.
> You might call it metadata, but being a type doesn't come to
> mind. What would be the point of that; what could you do with that
> type?
You could define objects of the type, you could apply sizeof to it, you
could define a type that points to it, or that's an array of it. You
know, all the stuff you can normally do with a type.
> Suppose you had a counted string variable S, currently set to "ABC" so
> that its length (which you say is naturally part its type) is 3.
What exactly do you mean by a "counted string variable"? If you mean
you have a variable whose current value is "ABC", and you can update it
so its value becomes "ABCDEF", then of course the count has to be
associated with the object. But a VLA object's size is fixed at run
time when it's created.
> Assume you could somehow do this:
>
> typeof(S) T
>
> would you expect T to also have a length 3? What would the string contain?
Without knowing what the type is *in C terms*, I can't answer that.
> It doesn't make sense. But you say that's how VLAs work:
>
> int A[rand()];
>
> typeof(A) B;
>
> B has the same length as A, whatever that is.
Well, C doesn't have typeof, but you can certainly do something similar.
(I'm changing the length expression because rand() can return 0, which
would cause undefined behavior.)
typedef int rvla[rand() % 10 + 1];
rvla A;
rvla B;
A and B are of the same type and therefore have the same length. The
obvious way to implement that would be to store the length in an
anonymous object associated with the type. You're saying you'd expect
the size be associated with A and with B, not with the type.
Given:
int row_count = 1000;
int col_count = 2000;
int vla_2d[row_count][col_count];
you have 1000 rows of 2000 elements each. Would you expect to create
1000 implicit objects, one for each row, each holding the value 2000?
Since the standard specifies the behavior of VLAs, not how they're
implemented, a conforming compiler could do that, but why would you
expect it?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-07 15:26 +0000 |
| Message-ID | <unefqu$148mk$1@dont-email.me> |
| In reply to | #379905 |
On 07/01/2024 03:28, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
>> You might call it metadata, but being a type doesn't come to
>> mind. What would be the point of that; what could you do with that
>> type?
>
> You could define objects of the type,
Only if accessible. You say typeof isn't available.
> you could apply sizeof to it,
Same here, but sizeof can also apply to the expression.
> you
> could define a type that points to it, or that's an array of it. You
> know, all the stuff you can normally do with a type
My example stored 'with the variable' has an anonymous type. If might be
something that only exists within the compiler, a generic 'VLA' type
since the size is not known until runtime.
It would be extraordinary for C to actually have tangible type objects
at runtime since for me, types in C are a compile-time concept.
But we're talking about a number.
You claim that conceptually, that number is considered part of the type.
>> Suppose you had a counted string variable S, currently set to "ABC" so
>> that its length (which you say is naturally part its type) is 3.
>
> What exactly do you mean by a "counted string variable"? If you mean
> you have a variable whose current value is "ABC", and you can update it
> so its value becomes "ABCDEF", > then of course the count has to be associated with the object.
It could be fixed or variable. But it's interesting that you consider
the two to be different.
Why can't you then consider a VLA that is capable of changing its size,
but happens to keep the same one over its lifetime. Why should that then
change that size from variable-associated to type-associated?
> typedef int rvla[rand() % 10 + 1];
> rvla A;
> rvla B;
>
> A and B are of the same type and therefore have the same length.
I'm sorry, it's still bizarre to me. I consider a length to be part of a
type when it's compile-time fixed value, /and is also defined with the
type/, for example:
type float vector[4];
But never when the size is variable, whether that means determined at
runtime and never changes, or determined at runtime but can grow. What
might be recorded is the fact that the size is a variable quantity that
needs further input.
> The
> obvious way to implement that would be to store the length in an
> anonymous object associated with the type. You're saying you'd expect
> the size be associated with A and with B, not with the type.
>
> Given:
>
> int row_count = 1000;
> int col_count = 2000;
> int vla_2d[row_count][col_count];
>
> you have 1000 rows of 2000 elements each. Would you expect to create
> 1000 implicit objects, one for each row, each holding the value 2000?
I don't know. I haven't implemented VLAs, and I don't have an equivalent
feature at this level of language.
At the next level up, if row_count and col_count are really not known
until runtime (your example would be better off as enums), then yes,
there would be 1000 rows, and each row is a 2000-element array
containing its length.
(Since in that language, each row can be a different length, or even a
different type entirely.)
What I would look at would be a special multi-dimensional type (say like
a 2D slice), which stores 2 or more dimensions, and which would allow
all the data to be allocated in a contiguous block.
I don't support that right now. But don't feel so smug, because when I
tried your example, it crashed.
Since that data structure needs 8MB of stack. Here you could anticipate
that; but often you can't. That's one big problem with VLAs.
After scaling down the task to 100x200, then gcc and tcc gave me a size
of 80,000. lccwin gave me 320,000.
Meanwhile my dynamic language can effortlessly create that 1000 x 2000 x
int32 data structure, even though it uses 8048048 bytes in all instead
of C's 8000000 plus whatever overheads the VLA needs, assuming a big
enough stack, or a smart enough implementation that will switch to heap
as needed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-07 15:51 -0800 |
| Message-ID | <87sf38r9bu.fsf@nosuchdomain.example.com> |
| In reply to | #379911 |
Bart <bc@freeuk.cm> writes:
> On 07/01/2024 03:28, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>>> You might call it metadata, but being a type doesn't come to
>>> mind. What would be the point of that; what could you do with that
>>> type?
>> You could define objects of the type,
>
> Only if accessible. You say typeof isn't available.
The C standard says typeof isn't available. It has nothing to do with
me.
>> you could apply sizeof to it,
>
> Same here, but sizeof can also apply to the expression.
Yes. So what? You asked what you could do with the type. Perhaps
there was some other point to your question that I missed.
>> you
>> could define a type that points to it, or that's an array of it. You
>> know, all the stuff you can normally do with a type
>
> My example stored 'with the variable' has an anonymous type. If might
> be something that only exists within the compiler, a generic 'VLA'
> type since the size is not known until runtime.
>
> It would be extraordinary for C to actually have tangible type objects
> at runtime since for me, types in C are a compile-time concept.
Nobody said anything about "tangible type objects".
Yes, types in C are a compile-time concept. But VLA types have
information associated with them that is available only during
execution.
> But we're talking about a number.
>
> You claim that conceptually, that number is considered part of the type.
Yes, that's clear from how VLAs are specified by the standard.
>>> Suppose you had a counted string variable S, currently set to "ABC" so
>>> that its length (which you say is naturally part its type) is 3.
>> What exactly do you mean by a "counted string variable"? If you mean
>> you have a variable whose current value is "ABC", and you can update
>> it so its value becomes "ABCDEF",
> then of course the count has to be associated with the object.
>
> It could be fixed or variable. But it's interesting that you consider
> the two to be different.
You've lost me. Again, please explain what you mean by "counted string
variable".
> Why can't you then consider a VLA that is capable of changing its
> size, but happens to keep the same one over its lifetime.
I honestly don't know what that means.
When you say "a VLA", are you talking about an object or a type?
I can certainly consider a VLA-like object that's "capable of changing
its size" (C++'s std::vector is something like that), but C has no such
feature, so there's no point in discussing it here.
> Why should
> that then change that size from variable-associated to
> type-associated?
Again, the length of a VLA type is logically associated with the type.
An implementation could associate it, at run time, with each individual
object, but that would be inefficient in many cases, such as when there
are multiple objects of the same VLA type. I can see no benefit at all
in associating the length with each object rather than with the type.
And that association isn't even visible to the programmer. `sizeof vla`
and `sizeof (vla_type)` just work; I don't need to care how.
>> typedef int rvla[rand() % 10 + 1];
>> rvla A;
>> rvla B;
>> A and B are of the same type and therefore have the same length.
>
> I'm sorry, it's still bizarre to me. I consider a length to be part of
> a type when it's compile-time fixed value, /and is also defined with
> the type/, for example:
>
> type float vector[4];
>
> But never when the size is variable, whether that means determined at
> runtime and never changes, or determined at runtime but can grow. What
> might be recorded is the fact that the size is a variable quantity
> that needs further input.
Why?
C *does not have* VLAs whose type is "determined at runtime but can
grow". Logically associating the length of a VLA type with the type
*works*.
Here's a small non-executable example:
#include <stddef.h>
size_t foo_size;
size_t bar_size;
void func(void) {
int n = 42;
typedef int vla[n];
vla foo;
vla bar;
foo_size = sizeof foo;
bar_size = sizeof bar;
}
When I compile it with "gcc -S", I get assembly code that appears to
store the value 42 just once:
movl $42, -52(%rbp)
and retrieves that value from the same place to copy it to foo_size and
bar_size. (I'm not an expert in x86_64 assembly language, but I'm
fairly sure that's what's going on.) Please take a look at the
generated assembly code yourself, using any C compilers you like. Do
any of them store the sizes of foo and bar separately? Why do you think
it would be better to do so?
Remember that since foo and bar are of the same type, it is not possible
for them to have different lengths, so compilers don't need to allow
for that possibility.
>> The
>> obvious way to implement that would be to store the length in an
>> anonymous object associated with the type. You're saying you'd expect
>> the size be associated with A and with B, not with the type.
>> Given:
>> int row_count = 1000;
>> int col_count = 2000;
>> int vla_2d[row_count][col_count];
>> you have 1000 rows of 2000 elements each. Would you expect to
>> create
>> 1000 implicit objects, one for each row, each holding the value 2000?
>
> I don't know. I haven't implemented VLAs, and I don't have an
> equivalent feature at this level of language.
So you don't really understand C's VLAs. That's fine, but then why do
you insist on a specific implementation technique, one that in practice
doesn't make sense?
If some non-C language supports dynamic array objects whose size can change
during their lifetime, then of course the size would be associated with
the object, not with the type. C has no such feature.
> At the next level up, if row_count and col_count are really not known
> until runtime (your example would be better off as enums), then yes,
> there would be 1000 rows, and each row is a 2000-element array
> containing its length.
If row_count and col_count were enums, they would be constants, and
vla_2d would not be a VLA. The whole point is that we're talking about
VLAs.
So you think each of the 1000 rows needs to store its own length of 2000
separately? All 1000 rows are of the same type, and are guaranteed to
have the same length. All the elements of *any* C array are of the same
type and have the same size.
> (Since in that language, each row can be a different length, or even a
> different type entirely.)
What language?
Did you think I was talking about some hypothetical C-like language?
I'm talking about C, and only C; my only assumption is that the
implementation supports VLAs, which are an optional feature in C11 and
later. My example is pure C code.
> What I would look at would be a special multi-dimensional type (say
> like a 2D slice), which stores 2 or more dimensions, and which would
> allow all the data to be allocated in a contiguous block.
>
> I don't support that right now. But don't feel so smug, because when I
> tried your example, it crashed.
>
> Since that data structure needs 8MB of stack. Here you could
> anticipate that; but often you can't. That's one big problem with
> VLAs.
Ok, that's a valid point. Many C implementations place relatively small
limits on stack size (in C terms, the space allocated for objects with
automatic storage duration). I didn't think of that when I wrote my
3-line example. (8,000,000 bytes happens to be barely within the stack
size limit on my system.)
(You can also allocate VLAs on the heap, which typically has less
stringent restrictions, but let's not get into that.)
Yes, VLAs can result in stack overflows. So can ordinary fixed-length
arrays. If you define a VLA that you know can't be longer than N
elements, then that's no more dangerous that defining an ordinary array
with a length of exactly N.
> After scaling down the task to 100x200, then gcc and tcc gave me a
> size of 80,000. lccwin gave me 320,000.
OK, here's a complete program with the VLA scaled down. (200 int
objects shouldn't exceed the stack size limit on any reasonable
implementation.)
#include <stdio.h>
int main(void) {
int row_count = 10;
int col_count = 20;
int vla_2d[row_count][col_count];
printf("sizeof vla_2d[0][0] = %zu\n", sizeof vla_2d[0][0]);
printf("sizeof vla_2d[0] = %zu\n", sizeof vla_2d[0]);
printf("sizeof vla_2d = %zu\n", sizeof vla_2d);
printf("rows : %zu\n",
sizeof vla_2d / sizeof vla_2d[0]);
printf("elements per row : %zu\n",
sizeof vla_2d[0] / sizeof vla_2d[0][0]);
printf("Total elements : %zu\n",
sizeof vla_2d / sizeof vla_2d[0][0]);
}
The output on my system with gcc, clang, and tcc is:
sizeof vla_2d[0][0] = 4
sizeof vla_2d[0] = 80
sizeof vla_2d = 800
rows : 10
elements per row : 20
Total elements : 200
The first three lines can vary depending on sizeof (int).
The last three should be the same for all implementations.
lccwin gives me:
sizeof vla_2d[0][0] = 4
sizeof vla_2d[0] = 16
sizeof vla_2d = 3200
rows : 200
elements per row : 4
Total elements : 800
This is clearly a bug in lccwin. Feel free to report it to jacob navia
and/or post to comp.compilers.lcc. I don't think he'd be interested in
hearing about it from me.
> Meanwhile my dynamic language [...]
is irrelevant. If you want to discuss it, I suggest starting a thread
in comp.lang.misc. I might even participate. (Your point in bringing
up your own languages seems to be that other languages do some things
better than C does. Of course that's true, and nobody here has said
otherwise.)
--
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-08 01:32 +0000 |
| Message-ID | <unfjb3$195hu$1@dont-email.me> |
| In reply to | #379918 |
On 07/01/2024 23:51, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
> Here's a small non-executable example:
>
> #include <stddef.h>
>
> size_t foo_size;
> size_t bar_size;
>
> void func(void) {
> int n = 42;
> typedef int vla[n];
> vla foo;
> vla bar;
This isn't how VLAs are typically used. I think there are three kinds of
people when it comes to VLAs:
(1) Those who don't know about them and only inadvertently create
them because the dimension is a variable not a compiler-time
expression
(2) Those who know about VLAs, but who will supply the dimensions to
the variable declaration
(3) A minority who know that VLA dimensions can also be used in
typedefs.
In the case of (2), what happens is that some storage is reserved for a
size. A clever compiler can use one lot of storage if it realises
multiple variables use that same size.
But whatever it is, you saying that bit of storage is to do with the
type; I'm saying it's to do with the instance of that type. In the end
it probably doesn't matter.
It does however still bother me that a mere typedef, not actually used
for anything, could take up runtime resources.
>> At the next level up, if row_count and col_count are really not known
>> until runtime (your example would be better off as enums), then yes,
>> there would be 1000 rows, and each row is a 2000-element array
>> containing its length.
>
> If row_count and col_count were enums, they would be constants, and
> vla_2d would not be a VLA. The whole point is that we're talking about
> VLAs.
This is actually an important point. Many examples of VLAs I've seen are
exactly like your example, due to point (1) above.
> Yes, VLAs can result in stack overflows. So can ordinary fixed-length
> arrays.
VLAs can do so much more easily:
void F(int n) { int A[n];}
What are the likely values of n? Without VLAs you have to knowingly use
large fixed values of n, and/or rely on deep recursion, to get overflow.
> If you define a VLA that you know can't be longer than N
> elements, then that's no more dangerous that defining an ordinary array
> with a length of exactly N.
The compiler likely doesn't know. Some compilers (like gcc on Windows)
use a call like __checkstk() to allocate local storage which it either
knows will exceed 4KB, or it might do (like a VLA, even if n turns out
to be only 3).
> This is clearly a bug in lccwin. Feel free to report it to jacob navia
> and/or post to comp.compilers.lcc. I don't think he'd be interested in
> hearing about it from me.
This is important too. If someone that experienced with implementing C
has some trouble, then I've got no chance.
(BTW why did VLAs become optional from C11?)
>> Meanwhile my dynamic language [...]
>
> is irrelevant. If you want to discuss it, I suggest starting a thread
> in comp.lang.misc. I might even participate. (Your point in bringing
> up your own languages seems to be that other languages do some things
> better than C does.
Actually I was pointing out a deficiency in both my languages in lack of
support for multi-dimensional arrays of runtime dimensions, so that the
data cannot be allocated in a single block.
C apparently allows this in VLAs, and in passing such arrays to
functions where the dimensions are provided via parameters.
I consider this complex and out of place at this level of language.
(Especially given there more basic features that are missing.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-07 20:35 -0800 |
| Message-ID | <87jzokqw76.fsf@nosuchdomain.example.com> |
| In reply to | #379920 |
Bart <bc@freeuk.cm> writes:
> On 07/01/2024 23:51, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>
>> Here's a small non-executable example:
>> #include <stddef.h>
>> size_t foo_size;
>> size_t bar_size;
>> void func(void) {
>> int n = 42;
>> typedef int vla[n];
>> vla foo;
>> vla bar;
>
> This isn't how VLAs are typically used. I think there are three kinds
> of people when it comes to VLAs:
>
> (1) Those who don't know about them and only inadvertently create
> them because the dimension is a variable not a compiler-time
> expression
>
> (2) Those who know about VLAs, but who will supply the dimensions to
> the variable declaration
>
> (3) A minority who know that VLA dimensions can also be used in
> typedefs.
I haven't seen enough VLA-using code "in the wild" to know what kind of
usage is typical. (The fact that they were made optional in C11 might
suggest that there wasn't much demand for the feature, or at least that
the committee thought so.)
I do suspect, without evidence, that something like:
const int len = 100;
int arr[len];
is fairly common (len is not a constant expression but some programmers
might think it is).
But I'm mainly concerned with what usages are supported by the language.
> In the case of (2), what happens is that some storage is reserved for
> a size. A clever compiler can use one lot of storage if it realises
> multiple variables use that same size.
Especially if multiple variables are of the same type.
> But whatever it is, you saying that bit of storage is to do with the
> type; I'm saying it's to do with the instance of that type. In the end
> it probably doesn't matter.
>
> It does however still bother me that a mere typedef, not actually used
> for anything, could take up runtime resources.
It's not the typedef that takes up runtime resources. It's the array
type to which the typedef refers.
Consider this:
printf("%zu\n", sizeof (int[rand() % 10 } 1]);
That's a perfectly valid usage. The result of the length expression has
to be stored somewhere, and there is no object it can be associated
with.
Any time you define a VLA type, the length has to be determined and
stored. Since the compiler has to generate code to do that anyway, why
on Earth do you think it would be useful to *also* associate the length
with individual objects?
Earlier in this thread, you seemed to have the misconception that the
length of a VLA object could change during the object's lifetime. If
that were the case, then the length would have be associated with the
object -- but it isn't.
>>> At the next level up, if row_count and col_count are really not known
>>> until runtime (your example would be better off as enums), then yes,
>>> there would be 1000 rows, and each row is a 2000-element array
>>> containing its length.
>> If row_count and col_count were enums, they would be constants, and
>> vla_2d would not be a VLA. The whole point is that we're talking about
>> VLAs.
>
> This is actually an important point. Many examples of VLAs I've seen
> are exactly like your example, due to point (1) above.
>
>> Yes, VLAs can result in stack overflows. So can ordinary fixed-length
>> arrays.
>
> VLAs can do so much more easily:
>
> void F(int n) { int A[n];}
>
> What are the likely values of n? Without VLAs you have to knowingly
> use large fixed values of n, and/or rely on deep recursion, to get
> overflow.
So don't do that.
An int parameter can have a value up to INT_MAX. If you don't want a
stack overflow, then *write your code* so that n can't be too big.
malloc() can take any value up to SIZE_MAX. Don't write code that
can actually attempt to allocate that that much memory.
>> If you define a VLA that you know can't be longer than N
>> elements, then that's no more dangerous that defining an ordinary array
>> with a length of exactly N.
>
> The compiler likely doesn't know. Some compilers (like gcc on Windows)
> use a call like __checkstk() to allocate local storage which it either
> knows will exceed 4KB, or it might do (like a VLA, even if n turns out
> to be only 3).
It's the programmer's resposibility to avoid allocating too much memory,
either in fixed-length array, a VLA, or a call to malloc(). Which also
means having an idea of what "too much" is, which can vary depending on
the system and on whether you're using the stack or the heap, or static
storage. Yes, programming is hard.
>> This is clearly a bug in lccwin. Feel free to report it to jacob navia
>> and/or post to comp.compilers.lcc. I don't think he'd be interested in
>> hearing about it from me.
>
> This is important too. If someone that experienced with implementing C
> has some trouble, then I've got no chance.
No chance of what? Were you planning to implement C VLAs? You don't
seem to understand them well enough to use them, let alone to implement
them.
I seriously urge you to contact jacob navia, the author and maintainer
of lcc-win, and let him know about this bug. A web search for "lcc-win"
will lead you to a web page that has his email address. I'd contact him
myself, but that hasn't worked well in the past for reasons I won't go
into here.
> (BTW why did VLAs become optional from C11?)
I honestly don't know. I personally disagreed with the decision.
Perhaps making them optional for freestanding implementations would have
made more sense.
[...]
--
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-08 13:28 +0000 |
| Message-ID | <ungt9t$1i1kk$1@dont-email.me> |
| In reply to | #379921 |
On 08/01/2024 04:35, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
>> It does however still bother me that a mere typedef, not actually used
>> for anything, could take up runtime resources.
>
> It's not the typedef that takes up runtime resources. It's the array
> type to which the typedef refers.
>
> Consider this:
> printf("%zu\n", sizeof (int[rand() % 10 } 1]);
(Tested as:) printf("%zu\n", sizeof (int[rand() % 10 + 1]));
> That's a perfectly valid usage.
I don't consider it a reasonable one.
At least I've learnt some things from this thread:
* Within an elaborate type-chain of pointers and arrays, VLA
dimensions need to be managed by the impementation at each point
along the chain.
* But actual VLA data allocations are only managed at the top level.
That's if an actual object is created at all. VLA data further
along (eg. as a pointer target) is still managed by the programmer.
So, to switch to LTR declarations for a second as C's syntax is still
beyond me, here:
[x][y]**[z]int A # array x of array x of ptr to ptr to array z ..
If x,y,z were all variable dimensions, then the [x][y] is allocated
for you, but not the [z]. However all x,y,z sizes are stored.
* I'm never going to implement VLAs as defined by C, as I don't
agree with how they work, even if I fully understood them. Your
example demonstrates that well.
Actually I can't even emulate your example with my higher level
scripting language. It's just not a good fit for such a lower level one.
> Earlier in this thread, you seemed to have the misconception that the
> length of a VLA object could change during the object's lifetime.
No; you made a remark that if it could change, then you'd agree the
dimension could switch from being stored from the type, to the instance.
I suggested, why not pretend the dimension could change (even it you had
no intention of that), then storing dimensions with the variable could
work just as well.
> So don't do that.
Was it you who keeps saying that or is someone else?
It is akin to saying: 'So don't have any bugs'. VLAs /do/ make it more
likely to have stack overflows.
> An int parameter can have a value up to INT_MAX. If you don't want a
> stack overflow, then *write your code* so that n can't be too big.
>
> malloc() can take any value up to SIZE_MAX.
* Typical heap space might be 1000 times bigger than stack space
* Asking for too much heap doesn't cause a crash; it returns a failure
code
* You can check whether the allocation was successful then decide what
to do next, including making a graceful exit
> Don't write code that
> can actually attempt to allocate that that much memory.
This is interesting:
unsigned long long int n=SIZE_MAX;
int A[n];
printf("%zu\n",sizeof(A));
printf("%zu\n",SIZE_MAX);
This outputs (with gcc):
18446744073709551612
18446744073709551615
It goes wrong if you try to write to A beyond whatever the stack size is.
> No chance of what? Were you planning to implement C VLAs? You don't
> seem to understand them well enough to use them, let alone to implement
> them.
EXACTLY. And I'm a fairly experienced compiler writer of this level of
language. How many C users do you think understand all the ins and outs?
> I seriously urge you to contact jacob navia, the author and maintainer
> of lcc-win, and let him know about this bug.
I doubt it is still under active development. I'm also sure he would
have heard about any problems by now.
It's not even clear if it is actually wrong in your example other than
using more memory than expected. Look at the output of the gcc example
above: what's with the missing 3 bytes?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-08 10:25 -0800 |
| Message-ID | <875y03r8c4.fsf@nosuchdomain.example.com> |
| In reply to | #379924 |
Bart <bc@freeuk.cm> writes:
> On 08/01/2024 04:35, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>
>>> It does however still bother me that a mere typedef, not actually used
>>> for anything, could take up runtime resources.
>> It's not the typedef that takes up runtime resources. It's the
>> array
>> type to which the typedef refers.
>> Consider this:
>> printf("%zu\n", sizeof (int[rand() % 10 } 1]);
>
> (Tested as:) printf("%zu\n", sizeof (int[rand() % 10 + 1]));
Yes, sorry about the typo.
>> That's a perfectly valid usage.
>
> I don't consider it a reasonable one.
And yet a conforming compiler must cover reasonable and unreasonable
usages.
The example was obviously contrived; there are few good reasons to
create an array with a random length. But it would be perfectly
reasonable to define a typedef for a VLA type with some length
determined at run time.
If you're implementing VLAs in a C compiler, you can either associate
the length with the type, or you can associate it with each object *and*
add a bunch of special cases.
In the 2-dimensional VLA example I posted earlier, you want to store the
length with *each* row of the array. How would that memory be
allocated? (It can't be within the array, which must be contiguous.)
> At least I've learnt some things from this thread:
>
> * Within an elaborate type-chain of pointers and arrays, VLA
> dimensions need to be managed by the impementation at each point
> along the chain.
The length of each VLA type must be managed with that type.
> * But actual VLA data allocations are only managed at the top level.
> That's if an actual object is created at all. VLA data further
> along (eg. as a pointer target) is still managed by the programmer.
>
> So, to switch to LTR declarations for a second as C's syntax is still
> beyond me, here:
>
> [x][y]**[z]int A # array x of array x of ptr to ptr to array z ..
>
> If x,y,z were all variable dimensions, then the [x][y] is allocated
> for you, but not the [z]. However all x,y,z sizes are stored.
>
> * I'm never going to implement VLAs as defined by C, as I don't
> agree with how they work, even if I fully understood them. Your
> example demonstrates that well.
>
> Actually I can't even emulate your example with my higher level
> scripting language. It's just not a good fit for such a lower level
> one.
>
>
>> Earlier in this thread, you seemed to have the misconception that the
>> length of a VLA object could change during the object's lifetime.
>
> No; you made a remark that if it could change, then you'd agree the
> dimension could switch from being stored from the type, to the
> instance.
That remark was in response to something you had said.
> I suggested, why not pretend the dimension could change (even it you
> had no intention of that), then storing dimensions with the variable
> could work just as well.
No, it really doesn't.
>> So don't do that.
>
> Was it you who keeps saying that or is someone else?
>
> It is akin to saying: 'So don't have any bugs'. VLAs /do/ make it more
> likely to have stack overflows.
>
>
>> An int parameter can have a value up to INT_MAX. If you don't want a
>> stack overflow, then *write your code* so that n can't be too big.
>> malloc() can take any value up to SIZE_MAX.
>
> * Typical heap space might be 1000 times bigger than stack space
>
> * Asking for too much heap doesn't cause a crash; it returns a failure
> code
>
> * You can check whether the allocation was successful then decide what
> to do next, including making a graceful exit
Unfortunately, that's not always true. The standard requires malloc()
to return a null pointer if it can't allocate the memory, but on Linux
it typically returns a non-null pointer to a block of virtual memory
that triggers the OOM killer (Google it if you're curious) when you try
to access it.
>> Don't write code that
>> can actually attempt to allocate that that much memory.
>
> This is interesting:
>
> unsigned long long int n=SIZE_MAX;
> int A[n];
>
> printf("%zu\n",sizeof(A));
> printf("%zu\n",SIZE_MAX);
>
> This outputs (with gcc):
>
> 18446744073709551612
> 18446744073709551615
>
> It goes wrong if you try to write to A beyond whatever the stack size is.
>
>> No chance of what? Were you planning to implement C VLAs? You don't
>> seem to understand them well enough to use them, let alone to implement
>> them.
>
> EXACTLY. And I'm a fairly experienced compiler writer of this level of
> language. How many C users do you think understand all the ins and
> outs?
I don't know how many understand *all* the ins and outs. I think a lost
of C programmers understand VLAs well enough to use them. (Most C
programmers don't look for ways to make things more difficult than they
need to be.)
>> I seriously urge you to contact jacob navia, the author and maintainer
>> of lcc-win, and let him know about this bug.
>
> I doubt it is still under active development. I'm also sure he would
> have heard about any problems by now.
It's likely that he hasn't heard about a bug with 2-dimensional VLAs.
But if you don't want to contact him, I'll do it myself. I'll post to
comp.compilers.lcc, which he followed as of a few years ago. I can
credit you for finding the bug or leave you out of it, whichever you
prefer.
> It's not even clear if it is actually wrong in your example other than
> using more memory than expected. Look at the output of the gcc example
> above: what's with the missing 3 bytes?
What missing 3 bytes? The gcc output looked correct to me.
--
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-08 18:55 +0000 |
| Message-ID | <unhgfu$1kr7q$1@dont-email.me> |
| In reply to | #379929 |
On 08/01/2024 18:25, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
>> This is interesting:
>>
>> unsigned long long int n=SIZE_MAX;
>> int A[n];
>>
>> printf("%zu\n",sizeof(A));
>> printf("%zu\n",SIZE_MAX);
>>
>> This outputs (with gcc):
>>
>> 18446744073709551612
>> 18446744073709551615
>>
>> It goes wrong if you try to write to A beyond whatever the stack size is.
> But if you don't want to contact him, I'll do it myself. I'll post to
> comp.compilers.lcc, which he followed as of a few years ago. I can
> credit you for finding the bug or leave you out of it, whichever you
> prefer.
Best not to mention me; I'm already well-known to him as a bug-finder.
>> It's not even clear if it is actually wrong in your example other than
>> using more memory than expected. Look at the output of the gcc example
>> above: what's with the missing 3 bytes?
>
> What missing 3 bytes? The gcc output looked correct to me.
Look carefully at the last digit. It should be '5' for SIZE_MAX, but
sizeof() reports a value with '2' at the end.
This is a complete program:
#include <stdio.h>
#include <stdint.h>
int main(void) {
unsigned long long int n=SIZE_MAX;
int A[n];
printf("%zu\n",sizeof(A));
printf("%zu\n",SIZE_MAX);
}
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-08 19:01 +0000 |
| Message-ID | <unhgq0$1kr7q$2@dont-email.me> |
| In reply to | #379932 |
On 08/01/2024 18:55, Bart wrote:
> On 08/01/2024 18:25, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>
>>> This is interesting:
>>>
>>> unsigned long long int n=SIZE_MAX;
>>> int A[n];
>>>
>>> printf("%zu\n",sizeof(A));
>>> printf("%zu\n",SIZE_MAX);
>>>
>>> This outputs (with gcc):
>>>
>>> 18446744073709551612
>>> 18446744073709551615
>>>
>>> It goes wrong if you try to write to A beyond whatever the stack size
>>> is.
>
>> But if you don't want to contact him, I'll do it myself. I'll post to
>> comp.compilers.lcc, which he followed as of a few years ago. I can
>> credit you for finding the bug or leave you out of it, whichever you
>> prefer.
>
> Best not to mention me; I'm already well-known to him as a bug-finder.
>
>
>>> It's not even clear if it is actually wrong in your example other than
>>> using more memory than expected. Look at the output of the gcc example
>>> above: what's with the missing 3 bytes?
>>
>> What missing 3 bytes? The gcc output looked correct to me.
>
> Look carefully at the last digit. It should be '5' for SIZE_MAX, but
> sizeof() reports a value with '2' at the end.
Never mind. A is an int array not a char array. So it's size would be
4*SIZE_MAX; that apparently gives the given value when limited to 64 bits.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-08 11:22 -0800 |
| Message-ID | <87o7dvpr4z.fsf@nosuchdomain.example.com> |
| In reply to | #379933 |
Bart <bc@freeuk.cm> writes:
[...]
> Never mind. A is an int array not a char array. So it's size would be
> 4*SIZE_MAX; that apparently gives the given value when limited to 64
> bits.
And I should have read that before posting.
--
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]
Page 27 of 34 — ← Prev page 1 … 25 26 [27] 28 29 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web