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 1 of 34 [1] 2 3 … 34 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2023-12-26 16:59 +0100 |
| Subject | Effect of CPP tags |
| Message-ID | <umet9d$3hir9$1@dont-email.me> |
This is a CPP question that arose last month. It's not about an actual issue with the software, just out of curiosity and to be sure it works reliable (it seemingly does). In a C99 program on Linux (Ubuntu) I intended to use usleep() and then also strnlen(). When I added usleep() and its include file I got an error and was asked to define the CPP tag '_BSD_SOURCE'. I did so, and because I wanted side effects of that tag kept as small as possible I prepended it just before the respective #include and put it at the end of my #include list ...other #includes... #define _BSD_SOURCE #include <unistd.h> But as got obvious *that* way there had been side-effects and I had to put the tag at the beginning of all include files (which astonished me) #define _BSD_SOURCE #include <unistd.h> ...other #includes here... For the strnlen() function I needed another CPP tag, '_GNU_SOURCE'. So now I have both CPP tag definitions before the includes #define _GNU_SOURCE /* necessary for strnlen() in string.h */ #define _BSD_SOURCE /* necessary for usleep() in unistd.h */ ...all #includes here... The compile showed no error messages and the code works fine (it seems). Now I'm not feeling very comfortable with that; I seem to declare two different "philosophies" that way, GNU and BSD. And both tags affect all include files. - Is that okay? Last time I looked into the system header files, three decades ago, I got repelled by all the #ifdef's, cascaded and nested, a spaghetti code of dependencies; I'm astonished it works. - And the responsibility to keep all the CPP tags consistent with _all_ the header files lies at the side of the system headers' developers? The programmer doesn't need to care? Janis
[toc] | [next] | [standalone]
| From | Lowell Gilbert <lgusenet@be-well.ilk.org> |
|---|---|
| Date | 2023-12-26 17:45 -0500 |
| Message-ID | <44edf8lh1n.fsf@be-well.ilk.org> |
| In reply to | #379646 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > In a C99 program on Linux (Ubuntu) I intended to use usleep() and then > also strnlen(). usleep() isn't in C99. It comes from POSIX, where it was declared obsolete in 2001. [This information is available in "man usleep".] I don't want to get into checking which version of glibc you're using, and such details, so in this case I'll just recommend that you follow POSIX and use nanosleep() instead. You'll need to multiply by a thousand and reference different include files, but I strongly suspect you can figure that all out on your own. With only fabulously rare exceptions (which mostly involve the programmer knowing more about the implementation of libc than the libc implementors did), user code should not be defining (or undefining) _GNU_SOURCE or _BSD_SOURCE. You seem to have had thoughts in that direction, and you were absolutely right. Be well. -- Lowell Gilbert, embedded/networking software engineer http://be-well.ilk.org/~lowell/
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2023-12-26 22:50 +0000 |
| Message-ID | <20231226143131.916@kylheku.com> |
| In reply to | #379646 |
On 2023-12-26, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > This is a CPP question that arose last month. It's not about an actual > issue with the software, just out of curiosity and to be sure it works > reliable (it seemingly does). > > In a C99 program on Linux (Ubuntu) I intended to use usleep() and then > also strnlen(). > > When I added usleep() and its include file I got an error and was asked > to define the CPP tag '_BSD_SOURCE'. I did so, and because I wanted > side effects of that tag kept as small as possible I prepended it just > before the respective #include and put it at the end of my #include list > > ...other #includes... > #define _BSD_SOURCE > #include <unistd.h> > > But as got obvious *that* way there had been side-effects and I had to > put the tag at the beginning of all include files (which astonished me) Feature selection macros must be in effect before any system header is included, and are usually put on the compiler command line: cc ... -D_BSD_SOURCE -D_XOPEN_SOURCE=700 ... The concept of feature selection macros is documented in POSIX. https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html I will give you an excellent reason not to put them in source code: their behavior is system-specific. No single combination of these things works everywhere. It's best to wrestle that out in the configure scripts and Makefiles, keeping the code clean. The header files in BSD Unixes make the wrong interpretation of how feature selection macros are supposed to work. This affects everything that is based on BSD or has copy and pasted C libraries from BSD: Android's Bionic, Cygwin's Newlib, Apple's Darwin environment. The BSD interpretation of feature selection macros is this: 1. All available identifiers are turned on by default. 2. Feature selection macros *restrict* (subtract) from that set. 3. So do macros coming from the compiler's dialect selection. Under BSD, if you use, say gcc -ansi -D_POSIX_SOURCE, it will stupidly produce the intersection of pure ANSI and POSIX. What you wanted was to use the ANSI C dialect of the language, with POSIX functions. The BSD interpretation is that ANSI means you don't want <stdio.h> to give you the declaration of fileno or fdopen, and so the -D_POSIX_SOURCE won't reveal POSIX things in ANSI/ISO C headers. Similarly, if you picked _POSIX_SOURCE and _BSD_SOURCE, you would stupidly get the intersection of those two, not the union. In other systems, like GNU/Linuxes, Solaris (I think), you get the union: -ansi -D_POSIX_SOURCE -D_BSD_SOURCE would work as you expect: your code is the ANSI dialect, and you want header files to reveal POSIXisms as well as BSD-isms. In the Apple environment, forget about it; fine-grained feature selection is broken: you use -D_DARWIN_C_SOURCE and be done with it. It's like the old -D_HPUX_SOURCE to get anything compiled on HP-UX. > #define _GNU_SOURCE /* necessary for strnlen() in string.h */ I think once you define _GNU_SOURCE, Glibc's feature selection will give you everything. BSD functions in the GNU C library are also considered GNU extensions over POSIX. It's like the GNU equivalent of _DARWIN_C_SOURCE or _HPUX_SOURCE; you're asking to reveal everything from the GNU vendor. On Glibc, the header /usr/include/features.h is the switch where the feature selection public macros get converted into combinations of internal private macros which are then used throughout the headers to turn things on and off. The features.h header contains a block comment which lists the public feature selection macros, and another one that describes the internal ones you're not supposed to use directly. You can see that for _GNU_SOURCE, the comment says: _GNU_SOURCE All of the above, plus GNU extensions. All of the above refers to all the POSIX, X/Open, BSD stuff listed above that. -- 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 | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-12-27 17:11 +0000 |
| Message-ID | <ib2w1CqX8rwIzAb9V@bongo-ra.co> |
| In reply to | #379648 |
On Tue, 26 Dec 2023 22:50:40 -0000 (UTC) Kaz Kylheku <433-929-6894@kylheku.com> wrote: > On 2023-12-26, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > > This is a CPP question that arose last month. It's not about an actual > > issue with the software, just out of curiosity and to be sure it works > > reliable (it seemingly does). > > > > In a C99 program on Linux (Ubuntu) I intended to use usleep() and then > > also strnlen(). > > > > When I added usleep() and its include file I got an error and was asked > > to define the CPP tag '_BSD_SOURCE'. I did so, and because I wanted > > side effects of that tag kept as small as possible I prepended it just > > before the respective #include and put it at the end of my #include list > > > > ...other #includes... > > #define _BSD_SOURCE > > #include <unistd.h> > > > > But as got obvious *that* way there had been side-effects and I had to > > put the tag at the beginning of all include files (which astonished me) > > Feature selection macros must be in effect before any system header > is included, and are usually put on the compiler command line: > > cc ... -D_BSD_SOURCE -D_XOPEN_SOURCE=700 ... > > The concept of feature selection macros is documented in POSIX. > > https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html On Linux there exists also man page feature_test_macros which says : "In order to be effective, a feature test macro must be defined before including any header files." By the way , this kind of question is more appropriate for comp.unix.programmer .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-12-31 14:45 -0800 |
| Message-ID | <86frzit2hx.fsf@linuxsc.com> |
| In reply to | #379649 |
Spiros Bousbouras <spibou@gmail.com> writes: [... on #define _BSD_SOURCE, etc ...] > By the way , this kind of question is more appropriate for > comp.unix.programmer . For what it's worth, I found the discussion valuable. I look at comp.unix.programmer only sporadically, so I'm glad it was posted here.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2023-12-28 17:34 +0100 |
| Message-ID | <umk836$ehn5$1@dont-email.me> |
| In reply to | #379646 |
On 26.12.2023 16:59, Janis Papanagnou wrote: > [...] > In a C99 program on Linux (Ubuntu) I intended to use usleep() and then > also strnlen(). > > When I added usleep() and its include file I got an error and was asked > to define the CPP tag '_BSD_SOURCE'. [...] Thanks for all the replies. Kaz wrote: >> Feature selection macros must be in effect before any system header >> is included, and are usually put on the compiler command line: Right. This time I came from the functions' man pages and read that such tags are necessary for them, so I didn't think about the original purpose of these tags. I forgot that decades ago we used for platform specific declarations. Thanks for refreshing my neurons. >> I think once you define _GNU_SOURCE, Glibc's feature selection will >> give you everything. Indeed. I removed the one obsolete tag. Lowell wrote: >> usleep() isn't in C99. It comes from POSIX, where it was declared >> obsolete in 2001. Yes, I read about that. Though here I'm just programming non-portably for my local (and static, non-changing) environment, so it's not an issue in practice. Generally I try to program close to standards (but standards obviously also change, as we see). >> I'll just recommend that you follow POSIX and use nanosleep() >> instead. When I had read about the various 'sleep' options I decided to use one which supports sub-second resolution and with a most simple interface. That's why my choice was the simple 'usleep(usec);' even if obsolete by POSIX. The nanosleep() is not "very complex", sure, but I'd have to litter my code with variables unnecessary in my context, and also the advertised "advantages" of this function do not apply in my case.[*] And thanks for your confirmation that my "thoughts" about "not looking right to use _GNU_SOURCE and _BSD_SOURCE" was not unjustified. Spiros wrote: >> By the way , this kind of question is more appropriate for >> comp.unix.programmer I was indeed pondering about that. But I'm not programming Unix, and here I came from an application programming question so my choice was this newsgroup, and I think (and hope) it has not been a bad choice. I certainly found the experts to get the clarifications, suggestions, and insights that were helpful. Janis [*] To illustrate: I recall a similar decision in Java context. There was a simple and easy to use rexexp library (from Apache, IIRC). And there was also a most flexible blown up library that made its usage a lot more bulky (using and instantiating many classes and dependencies). I used the simple, user-friendly one. Later the bulky library became the Java standard.
[toc] | [prev] | [next] | [standalone]
| From | Lowell Gilbert <lgusenet@be-well.ilk.org> |
|---|---|
| Date | 2023-12-28 14:11 -0500 |
| Message-ID | <4434vmp2fl.fsf@be-well.ilk.org> |
| In reply to | #379656 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> Lowell wrote:
>>> I'll just recommend that you follow POSIX and use nanosleep()
>>> instead.
>
> When I had read about the various 'sleep' options I decided to use one
> which supports sub-second resolution and with a most simple interface.
> That's why my choice was the simple 'usleep(usec);' even if obsolete
> by POSIX. The nanosleep() is not "very complex", sure, but I'd have to
> litter my code with variables unnecessary in my context, and also the
> advertised "advantages" of this function do not apply in my case.[*]
To be honest,I didn't actually understand where your problem came from
in the first place -- I just chose not to bring up more than one point
at a time. While usleep() is obsolete, it works fine, without any
feature test macro games, on (as far as I know) all POSIX-ish
systems. Certainly on recent Ubuntu, the following program compiles and
runs perfectly well without even any warnings with even the most extreme
levels of warning enabled:
#include <stdio.h>
#include <unistd.h>
int main(void)
{
printf("starting\n");
usleep(2500000);
printf("finishing\n");
}
--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-12-28 13:13 -0800 |
| Message-ID | <87wmsyuj1l.fsf@nosuchdomain.example.com> |
| In reply to | #379657 |
Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
[...]
> To be honest,I didn't actually understand where your problem came from
> in the first place -- I just chose not to bring up more than one point
> at a time. While usleep() is obsolete, it works fine, without any
> feature test macro games, on (as far as I know) all POSIX-ish
> systems. Certainly on recent Ubuntu, the following program compiles and
> runs perfectly well without even any warnings with even the most extreme
> levels of warning enabled:
>
> #include <stdio.h>
> #include <unistd.h>
>
> int main(void)
> {
> printf("starting\n");
> usleep(2500000);
> printf("finishing\n");
> }
I think the warnings you enabled weren't extreme enough:
$ gcc -std=c11 -c c.c
c.c: In function ‘main’:
c.c:7:4: warning: implicit declaration of function ‘usleep’; did you mean ‘sleep’? [-Wimplicit-function-declaration]
7 | usleep(2500000);
| ^~~~~~
| sleep
$
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2023-12-28 21:47 +0000 |
| Message-ID | <20231228134234.49@kylheku.com> |
| In reply to | #379658 |
On 2023-12-28, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
> [...]
>> To be honest,I didn't actually understand where your problem came from
>> in the first place -- I just chose not to bring up more than one point
>> at a time. While usleep() is obsolete, it works fine, without any
>> feature test macro games, on (as far as I know) all POSIX-ish
>> systems. Certainly on recent Ubuntu, the following program compiles and
>> runs perfectly well without even any warnings with even the most extreme
>> levels of warning enabled:
>>
>> #include <stdio.h>
>> #include <unistd.h>
>>
>> int main(void)
>> {
>> printf("starting\n");
>> usleep(2500000);
>> printf("finishing\n");
>> }
>
> I think the warnings you enabled weren't extreme enough:
>
> $ gcc -std=c11 -c c.c
> c.c: In function ‘main’:
> c.c:7:4: warning: implicit declaration of function ‘usleep’; did you mean ‘sleep’? [-Wimplicit-function-declaration]
> 7 | usleep(2500000);
> | ^~~~~~
> | sleep
> $
What's actually happening is that -std=c11 causes <unistd.h> to hide
the usleep declaration. (Even tough <unistd.h> isn't in ISO C).
If you just use:
gcc -Wimplicit-function-declaration -c c.c
it will not warn. Since no feature selection has been made, all symbols
in headers are maximally visible.
Unless you're using an old GCC whose default dialect is gnu89,
the -Wimplicit-functiond-declaration option is already present in
the default dialect (like gnu99, gnu11 or gnu17).
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-12-28 15:12 -0800 |
| Message-ID | <87sf3lvs43.fsf@nosuchdomain.example.com> |
| In reply to | #379662 |
Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2023-12-28, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
>> [...]
>>> To be honest,I didn't actually understand where your problem came from
>>> in the first place -- I just chose not to bring up more than one point
>>> at a time. While usleep() is obsolete, it works fine, without any
>>> feature test macro games, on (as far as I know) all POSIX-ish
>>> systems. Certainly on recent Ubuntu, the following program compiles and
>>> runs perfectly well without even any warnings with even the most extreme
>>> levels of warning enabled:
>>>
>>> #include <stdio.h>
>>> #include <unistd.h>
>>>
>>> int main(void)
>>> {
>>> printf("starting\n");
>>> usleep(2500000);
>>> printf("finishing\n");
>>> }
>>
>> I think the warnings you enabled weren't extreme enough:
>>
>> $ gcc -std=c11 -c c.c
>> c.c: In function ‘main’:
>> c.c:7:4: warning: implicit declaration of function ‘usleep’; did you mean ‘sleep’? [-Wimplicit-function-declaration]
>> 7 | usleep(2500000);
>> | ^~~~~~
>> | sleep
>> $
>
> What's actually happening is that -std=c11 causes <unistd.h> to hide
> the usleep declaration. (Even tough <unistd.h> isn't in ISO C).
That's an interesting choice. Just including <unistd.h> has undefined
behavior as far as ISO C is concerned, but gcc never (?) warns about
that regardless of the options.
In glibc on Ubuntu 22.04, the declaration of usleep() in <unistd.h>
is protected by:
#if (defined __USE_XOPEN_EXTENDED && !defined __USE_XOPEN2K8) \
|| defined __USE_MISC
IMHO it would have been better if standards that extend the C library
declared all additional declarations in non-standard headers like
<unistd.h> rather than adding them to ISO C standard headers like
<stdio.h> and <stdlib.h>. But a lot of the stuff that POSIX adds
probably predates ISO C90, so there was never a good opportunity to make
a clean split.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-20 14:29 -0800 |
| Message-ID | <86y1cjiqpu.fsf@linuxsc.com> |
| In reply to | #379664 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > [...] Just including <unistd.h> has undefined behavior as far as > ISO C is concerned, [...] Not true. The behavior of #include <unistd.h> is defined in section 6.10.2 p2. One of two things is true: either the header named is part of the implementation, or it isn't. If the named header is part of the implementation, then it constitutes a language extension, and so it must be documented (and defined). If the named header is not part of the implementation, it still must be a header that the implementation can process (because of the constraint in 6.10.2 p1), and it must be processed the same way as a header that is part of the implementation (because of how the behavior is defined in 6.10.2 p2). Implementations are not at liberty to do anything they want just because the header named is not part of the implementation; such headers must be processed in just the same way as standard or extension headers, no matter how it is that they happen to be in the set of places the implementation has defined (and documented) to hold headers.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-21 04:46 +0000 |
| Message-ID | <20240120203343.615@kylheku.com> |
| In reply to | #380545 |
On 2024-01-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> [...] Just including <unistd.h> has undefined behavior as far as >> ISO C is concerned, [...] > > Not true. The behavior of #include <unistd.h> is defined in > section 6.10.2 p2. One of two things is true: either the header > named is part of the implementation, or it isn't. If the named > header is part of the implementation, then it constitutes a > language extension, and so it must be documented (and defined). The problem with this reasoning is 1. Implementations in fact have internal headers that are not documented, and which are not supposed to be included directly. You will not get documentation for every single header that is accessible via #include, and it is not reasonable for ISO C to require it. I don't see where it does. 2. A documented extension continues to be undefined behavior. The behavior is "defined", but not "ISO C defined". So even if all the implementation's internal headers were documented as extensions, their use would still be UB. Undefined behavior is for which "this document imposes not requirements", right? It is not behavior for which "this document, together with the ocumentation accompanying a given implementation, imposes no requirements". Just "this document" (and no other). If "this document" imposes no requirements, it's "undefined behavior", no matter who or what imposes additional requirements! Intuitively, a header which is part of an implementation can do anything. For instance #include <pascal.h> can cause the rest of the translation unit to be analyzed as Pascal syntax, and not C. An implementation can provide a header <reboot.h>, including which causes a reboot at compile time, link time, or execution time. If such headers happen to exist, what in the standard is violated? I used to experience a lot of push-back against the above views, but I'm seeing that people are coming around. -- 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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-01-21 10:56 -0500 |
| Message-ID | <uojes7$7nc8$1@dont-email.me> |
| In reply to | #380557 |
On 1/20/24 23:46, Kaz Kylheku wrote: > On 2024-01-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: ... >> named is part of the implementation, or it isn't. If the named >> header is part of the implementation, then it constitutes a >> language extension, and so it must be documented (and defined). > > The problem with this reasoning is > 1. Implementations in fact have internal headers that are not > documented, and which are not supposed to be included directly. You > will not get documentation for every single header that > is accessible via #include, and it is not reasonable for ISO C to > require it. I don't see where it does. "An implementation shall be accompanied by a document that defines all implementation-defined and locale-specific characteristics and all extensions." 4p9
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-01-21 12:11 -0500 |
| Message-ID | <uojj7p$8crh$1@dont-email.me> |
| In reply to | #380557 |
Initially, I accidentally sent my response as private e-mail to Kaz rather than to the group. With his permission, here's the response he sent: On 1/21/24 01:37, Kaz Kylheku wrote: > On 2024-01-20 21:50, James Kuyper wrote: >> "An implementation shall be accompanied by a document that defines all >> implementation-defined and locale-specific characteristics and all >> extensions." 4p9 > That sentence says something subtly different from something like > "an implementation shall document everything that looks stable enough > to be an extension". > > It is saying that there is required to be a document, and that in > that document there may be a list of one or more extensions. > > The standard is defining the *fact* that this list is exhaustive: > it comprises all the extensions that are offered in the contract > between implementor and programmer. > > Thus, for instance, if programmers empirically discover a behavior > which is not defined by ISO C, and which is not in that list, > it is not an extension. The standard states that that list has > all the extensions, and that discovered feature is not on it. > > The sentence does not require implementors to document, > as an extension, every header file that is reachable by an #include > directive. The standard doesn't provide a definition for "extension", though it makes many uses of the term, identifying a variety of things as possible or common extensions to C. What you're saying is, essentially, that extensions are defined as such by the fact that they are listed as such in that document. The biggest problem I have with that is that ISO has a convention that allows them to say just that - all they would have had to do is put "extension" in italics in 4p9, and that would identify the sentence in which it occurs as the definition of the term. They didn't choose to do so. I concede that they might not have thought of doing so. However, it seems more reasonable to me that whether or not something is an extension is not supposed to be up to the implementor to decide. Instead, anything that is an extension must be listed. This would be an easier interpretation to defend if there were any explicit definition of "extension" in the standard.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-21 17:55 +0000 |
| Message-ID | <20240121094637.874@kylheku.com> |
| In reply to | #380573 |
On 2024-01-21, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > However, it seems more reasonable to me that whether or not something is > an extension is not supposed to be up to the implementor to decide. > Instead, anything that is an extension must be listed. This would be an > easier interpretation to defend if there were any explicit definition of > "extension" in the standard. The implication is that anything that works by accident must be listed as an extension. If function arguments happen to be evaluated left to right, with all side effects complete between them, this has to be listed as an extension. Then in the future when the vendor finds that inconvenient for further compiler work, they have to take away the extension. I don't see how it can not be the implementor's privilege to assert what is reliable for use and documented, versus what is not. Unless they have some legal contract with particular customers, requiring certain things be provided. -- 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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-01-21 21:57 -0500 |
| Message-ID | <uoklil$et2j$2@dont-email.me> |
| In reply to | #380576 |
On 1/21/24 12:55, Kaz Kylheku wrote: > On 2024-01-21, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> However, it seems more reasonable to me that whether or not something is >> an extension is not supposed to be up to the implementor to decide. >> Instead, anything that is an extension must be listed. This would be an >> easier interpretation to defend if there were any explicit definition of >> "extension" in the standard. > > The implication is that anything that works by accident must be listed > as an extension. If function arguments happen to be evaluated left to > right, with all side effects complete between them, this has to be > listed as an extension. Then in the future when the vendor finds that > inconvenient for further compiler work, they have to take away the > extension. No, that's unspecified behavior, if 4p9 were intended to be understood as mandating documentation of all unspecified behavior, it would make the category of implementation-defined behavior redundant. Since extensions are also explicitly prohibited from changing the behavior of strictly conforming code, I think that in order for something qualify as an extension, it has to define behavior that the standard leaves undefined. In a certain sense, every implementation implicitly defines that behavior - whatever it is that actually happens when the behavior is undefined is that definition. However, I think an extension should have to be explicitly activated by some deliberate user choice, such as a compiler option or by defining the behavior of some kinds of syntax not allowed by the C standard. That's just IMHO, of course - in the absence of a explicit definition in the standard, it's hard to be sure what the committee intended.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-24 07:42 -0800 |
| Message-ID | <86il3ieo0t.fsf@linuxsc.com> |
| In reply to | #380607 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/21/24 12:55, Kaz Kylheku wrote:
>
>> On 2024-01-21, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>
>>> However, it seems more reasonable to me that whether or not
>>> something is an extension is not supposed to be up to the
>>> implementor to decide. Instead, anything that is an extension
>>> must be listed. This would be an easier interpretation to defend
>>> if there were any explicit definition of "extension" in the
>>> standard.
>>
>> The implication is that anything that works by accident must be
>> listed as an extension. If function arguments happen to be
>> evaluated left to right, with all side effects complete between
>> them, this has to be listed as an extension. Then in the future
>> when the vendor finds that inconvenient for further compiler work,
>> they have to take away the extension.
>
> No, that's unspecified behavior, if 4p9 were intended to be
> understood as mandating documentation of all unspecified behavior,
> it would make the category of implementation-defined behavior
> redundant.
Quite so.
> Since extensions are also explicitly prohibited from changing the
> behavior of strictly conforming code, I think that in order for
> something qualify as an extension, it has to define behavior that
> the standard leaves undefined.
The essential property of an extension is that it must specify a
language feature or library feature that is not specified in the C
standard. Implementations are free to /define/ undefined behavior
any way they want, and doing so doesn't require an extension; the
point of documenting an extension is to /specify what happens/ in
certain cases, which also means giving a guarantee that what is
documented is what will happen (with the understanding that the
guarantee is only that the implementation will make its best
efforts to do so, because some results are outside of an
implementation's ability to control).
(I note in passing that an odd consequence of how the C standard
uses certain terminology is that "defining" something doesn't stop
it from being "undefined". The term "undefined behavior" is thus
something of a misnomer. But I digress.)
Conversely, an extension can specify a feature that is not, or
might not be, undefined behavior, but still needs to be documented
as an extension. For example
#include <foo.h>
is not undefined behavior, but must be documented as an extension
if the header <foo.h> is part of the implementation, because what
is in the header <foo.h> is not specified in the C standard.
Similarly, a declaration like
typedef __uint128_t U128;
is not necessarily undefined behavior, because implementations are
free to define reserved identifiers any way they wish. But if it's
important that it work, then it must be documented as an extension,
as otherwise an implementation is free to reject it by virtue of
using a language feature not specified in the C standard (which
therefore means the program is not strictly conforming, and so can
be rejected).
> In a certain sense, every
> implementation implicitly defines that behavior - whatever it is
> that actually happens when the behavior is undefined is that
> definition. However, I think an extension should have to be
> explicitly activated by some deliberate user choice, such as a
> compiler option or by defining the behavior of some kinds of
> syntax not allowed by the C standard. That's just IMHO, of course
> - in the absence of a explicit definition in the standard, it's
> hard to be sure what the committee intended.
That's a QOI issue. I'm not convinced that it's a good idea in
all cases. For example, either of the two cases mentioned above:
#include <foo.h>
typedef __uint128_t U128;
do not IMO need an explicit user action to activate, because it's
obvious they are making use of extensions, and are pretty unlikely
to occur by accident. I concede however that other people may
reasonably hold other views on that question.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-31 12:43 -0800 |
| Message-ID | <86wmrp9qt8.fsf@linuxsc.com> |
| In reply to | #380576 |
Kaz Kylheku <433-929-6894@kylheku.com> writes: > On 2024-01-21, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > >> However, it seems more reasonable to me that whether or not something is >> an extension is not supposed to be up to the implementor to decide. >> Instead, anything that is an extension must be listed. This would be an >> easier interpretation to defend if there were any explicit definition of >> "extension" in the standard. > > The implication is that anything that works by accident must be > listed as an extension. If function arguments happen to be > evaluated left to right, with all side effects complete between > them, this has to be listed as an extension. Then in the future > when the vendor finds that inconvenient for further compiler work, > they have to take away the extension. > > I don't see how it can not be the implementor's privilege to > assert what is reliable for use and documented, versus what is > not. It's important to understand what constitutes an extension. And there are different kinds of extensions. If an implementation chooses, say, to evaluate function arguments always left-to-right, that is perfectly okay (and need not be an extension). But if an there is to be a /guarantee/ that function arguments will always be evaluated left-to-right, that means providing a guarantee that the C standard does not; thus we have an extension (to the requirements in the C standard), and the extension must be documented. This case is one kind of extension. If an implementation chooses to alter the semantics of, for example, an extern declaration inside a function body, so that the declared identifier has file scope rather than block scope, that is a different kind of extension. At the point of the extern declaration we can't actually detect any difference. A subsequent use, however, outside the function body, would normally be a constraint violation and so require a diagnostic, but under the altered semantics the identifier has already been declared and so no diagnostic is needed. (Note that this behavior is one of the cases listed in Annex J.5, "Common extensions".) This example illustrates a second kind of extension, and they always must be documented as such. If an implementation chooses to define, for example, __uint128_t to be the name of an integer type, that represents a third kind of extension. (Annex J.5 also mentions such definitions as an example on its list of "Common extensions".) Such cases must be documented as extensions because, one, the expected default is that there be no definition (which normally would cause a diagnostic because of some constraint violation), and two, only the implementation is in a position to know if the symbol in question was defined by the implementation or by something else. Clearly any definition the implementation provides signals a change from the expected default, which by any reasonable definition of the word constitutes an extension, and hence must be documented.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-31 13:41 -0800 |
| Message-ID | <87cythrxip.fsf@nosuchdomain.example.com> |
| In reply to | #381406 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
> It's important to understand what constitutes an extension. And
> there are different kinds of extensions.
>
> If an implementation chooses, say, to evaluate function arguments
> always left-to-right, that is perfectly okay (and need not be an
> extension). But if an there is to be a /guarantee/ that function
> arguments will always be evaluated left-to-right, that means
> providing a guarantee that the C standard does not; thus we have an
> extension (to the requirements in the C standard), and the extension
> must be documented. This case is one kind of extension.
If an implementation chooses to guarantee left-to-right evaluation, I
don't see anything in the standard that requires that guarantee to be
documented. (Of course it can and should be.)
It's not entirely clear to me exactly what must or must not be
considered to be an "extension" as the C standard uses the term. The
standard doesn't show the word "extension" in italics or provide a
definition in section 3.
Unless your point is that it's not a guarantee unless it's documented?
But I don't see that that documentation is required *by the standard*.
[...]
> If an implementation chooses to define, for example, __uint128_t to
> be the name of an integer type, that represents a third kind of
> extension. (Annex J.5 also mentions such definitions as an example
> on its list of "Common extensions".) Such cases must be documented
> as extensions because, one, the expected default is that there be no
> definition (which normally would cause a diagnostic because of some
> constraint violation), and two, only the implementation is in a
> position to know if the symbol in question was defined by the
> implementation or by something else. Clearly any definition the
> implementation provides signals a change from the expected default,
> which by any reasonable definition of the word constitutes an
> extension, and hence must be documented.
Again, that can and should be documented, but since any use of the
identifer __uint128_t has undefined behavior, I don't see any
requirement in the standard that it must be documented.
(Aside: gcc has an extension adding __int128 as a keyword, supporting
types "__int128" and "unsigned __int128", but only on some target
systems. These do not qualify as extended integer types. I understand
that "__uint128_t" was a hypothetical example.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 09:19 +0100 |
| Message-ID | <upfk6t$1vt73$1@dont-email.me> |
| In reply to | #381412 |
On 31/01/2024 22:41, Keith Thompson wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Kaz Kylheku <433-929-6894@kylheku.com> writes: >> It's important to understand what constitutes an extension. And >> there are different kinds of extensions. >> >> If an implementation chooses, say, to evaluate function arguments >> always left-to-right, that is perfectly okay (and need not be an >> extension). But if an there is to be a /guarantee/ that function >> arguments will always be evaluated left-to-right, that means >> providing a guarantee that the C standard does not; thus we have an >> extension (to the requirements in the C standard), and the extension >> must be documented. This case is one kind of extension. > > If an implementation chooses to guarantee left-to-right evaluation, I > don't see anything in the standard that requires that guarantee to be > documented. (Of course it can and should be.) > I would say that a "guarantee" is a promise - in this case, from the compiler writers to compiler users. It's not a guarantee if they don't tell anyone! Then it's just an implementation detail. But I don't see that it has to be documented in any particular way, or called an "extension". IIRC MSVC's "guarantee" that it won't use type-based alias analysis for optimisation (and thus casting between pointer types will work as some people think they should work) is "documented" in a blog post by one of the compiler developers. Of course it is up to the user to decide how much they trust the guaranteed additional behaviour. A mailing list post with "We'll evaluate left to right, or your money back!" or a note in a blog page would probably not inspire as much confidence as clear information in the main reference documentation for a compiler.
[toc] | [prev] | [next] | [standalone]
Page 1 of 34 [1] 2 3 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web