Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #382146 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2024-02-09 00:39 +0000 |
| Last post | 2024-02-16 04:11 +0100 |
| Articles | 20 on this page of 517 — 24 participants |
Back to article view | Back to comp.lang.c
How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 00:39 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 00:53 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 02:10 +0000
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 07:31 -0800
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 01:13 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-09 09:27 +0100
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 10:16 +0000
Re: How About Disallowing Assignments In Expressions? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-09 10:36 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:17 +0000
Re: How About Disallowing Assignments In Expressions? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-09 14:08 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 22:41 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 23:54 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-10 13:03 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-11 10:46 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-09 14:43 +0100
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 22:43 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-10 14:42 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 16:54 +0100
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 16:35 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 09:09 -0800
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 17:22 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 09:34 -0800
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-09 18:02 +0000
Re: How About Disallowing Assignments In Expressions? fir <fir@grunge.pl> - 2024-02-09 19:46 +0100
Re: How About Disallowing Assignments In Expressions? fir <fir@grunge.pl> - 2024-02-09 21:48 +0100
Re: How About Disallowing Assignments In Expressions? fir <fir@grunge.pl> - 2024-02-11 12:09 +0100
Re: How About Disallowing Assignments In Expressions? fir <fir@grunge.pl> - 2024-02-11 12:23 +0100
Re: How About Disallowing Assignments In Expressions? fir <fir@grunge.pl> - 2024-02-11 12:37 +0100
Re: How About Disallowing Assignments In Expressions? fir <fir@grunge.pl> - 2024-02-11 12:46 +0100
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 17:38 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 09:49 -0800
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-09 18:04 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 10:28 -0800
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 18:52 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-09 20:20 +0100
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 13:11 -0800
Re: How About Disallowing Assignments In Expressions? fir <fir@grunge.pl> - 2024-02-09 23:11 +0100
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 22:14 +0000
Re: How About Disallowing Assignments In Expressions? dave_thompson_2@comcast.net - 2024-02-26 04:22 -0500
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-27 12:40 +0100
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-27 13:21 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:29 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 02:37 +0000
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 03:06 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-10 15:02 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 21:46 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 20:16 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 20:17 -0800
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-10 16:53 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 21:49 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:36 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 16:55 +0100
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-10 13:06 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-10 16:58 +0100
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-10 22:45 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-10 22:49 +0000
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-11 00:11 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:50 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-11 00:15 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:45 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-11 00:17 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-11 01:08 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-11 01:18 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 17:34 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-11 01:42 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 18:00 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-11 05:30 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 21:37 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-12 01:16 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 19:12 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 19:34 -0800
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-12 12:26 +0100
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-12 11:38 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-12 14:36 +0100
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-12 13:57 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-12 16:04 +0100
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-12 08:20 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-12 08:13 -0800
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-12 17:43 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-12 03:47 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 20:12 -0800
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-12 12:23 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-14 21:44 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-14 14:38 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 08:43 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-15 15:55 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-15 08:27 -0800
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-15 10:06 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-11 16:55 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-11 18:05 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-11 18:00 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-12 12:40 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-12 20:27 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-13 09:07 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-13 09:35 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-13 11:36 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-13 12:12 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-13 14:15 +0100
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-13 12:32 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-13 13:56 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-13 15:10 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-13 15:20 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-13 17:30 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-13 17:35 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-13 18:58 +0100
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-13 18:27 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-13 19:54 +0000
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-13 21:08 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-13 21:15 +0000
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-13 22:50 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 22:45 +0000
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-16 23:55 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 02:22 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 22:43 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-13 12:58 -0800
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-13 22:56 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-13 15:30 -0800
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-14 02:48 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-14 09:35 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-14 09:34 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-14 11:11 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-14 10:43 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-14 13:32 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-15 08:23 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 08:51 +0000
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-15 17:27 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-16 03:37 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 04:46 +0000
Building Code Again (was: How About Disallowing Assignments In Expressions?) bart <bc@freeuk.com> - 2024-02-14 11:30 +0000
Re: Building Code Again (was: How About Disallowing Assignments In Expressions?) Michael S <already5chosen@yahoo.com> - 2024-02-14 14:14 +0200
Re: Building Code Again Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-14 13:46 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-14 14:17 +0000
Re: Building Code Again scott@slp53.sl.home (Scott Lurndal) - 2024-02-14 16:03 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-14 17:04 +0000
Re: Building Code Again scott@slp53.sl.home (Scott Lurndal) - 2024-02-14 17:58 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-14 19:35 +0000
Re: Building Code Again Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-14 20:07 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-14 21:01 +0000
Re: Building Code Again scott@slp53.sl.home (Scott Lurndal) - 2024-02-14 21:47 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-15 01:07 +0000
Re: Building Code Again Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-15 03:08 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-15 11:44 +0000
Re: Building Code Again Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-15 16:40 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-15 18:02 +0000
Re: Building Code Again Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-16 00:29 +0000
Re: Building Code Again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 04:45 +0000
Re: Building Code Again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 08:56 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-15 10:32 +0000
Re: Building Code Again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 23:05 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-16 23:41 +0000
Re: Building Code Again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 02:26 +0000
Re: Building Code Again scott@slp53.sl.home (Scott Lurndal) - 2024-02-15 15:10 +0000
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-15 15:36 +0000
Re: Building Code Again David Brown <david.brown@hesbynett.no> - 2024-02-15 22:16 +0100
Re: Building Code Again bart <bc@freeuk.com> - 2024-02-15 21:29 +0000
Re: Building Code Again Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-16 00:19 +0000
Re: Building Code Again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 04:42 +0000
Re: Building Code Again Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-16 05:53 +0000
Re: Building Code Again Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-16 09:54 +0000
Re: Building Code Again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 22:48 +0000
Re: Building Code Again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-14 21:51 +0000
Re: Building Code Again (was: How About Disallowing Assignments In Expressions?) David Brown <david.brown@hesbynett.no> - 2024-02-14 13:40 +0100
Re: Building Code Again Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-14 14:13 +0000
Re: Building Code Again Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-14 21:48 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-14 15:58 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 22:47 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 08:57 +0000
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-15 17:29 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-15 22:18 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-16 04:14 +0100
Re: How About Disallowing Assignments In Expressions? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-15 19:53 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-12 01:17 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-12 12:42 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 17:00 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-13 22:10 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-13 14:19 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-14 20:51 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-14 13:21 -0800
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-14 21:54 +0000
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-14 22:37 -0800
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-15 14:20 +0100
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-15 13:47 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-17 20:45 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-17 20:45 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 02:16 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 02:39 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 02:40 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-18 15:46 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 16:06 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 18:12 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-18 22:34 +0000
Re: How About Disallowing Assignments In Expressions? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-18 23:06 +0000
Re: How About Disallowing Assignments In Expressions? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-02-19 00:06 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-19 02:26 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-19 08:58 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-19 14:21 +0000
[OT] was Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 16:20 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-19 16:52 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 18:04 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 18:30 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 05:45 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-20 09:00 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 22:37 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-21 08:41 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-20 03:27 -0500
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 22:38 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-20 23:56 -0500
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-20 10:09 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-20 18:10 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-20 18:26 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-20 18:30 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 18:54 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-20 18:59 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-20 19:27 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 19:35 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-20 19:39 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 22:43 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 22:40 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-21 08:52 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-21 11:25 -0500
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 18:51 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-21 00:24 -0500
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-22 01:37 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-02-20 18:47 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-21 00:14 -0500
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-21 11:21 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-20 15:49 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-19 18:14 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-20 16:16 +0100
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-20 16:59 +0000
Re: [OT] was Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 22:36 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-19 16:28 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 18:09 +0100
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-19 08:04 -0800
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-19 17:58 -0800
Re: How About Disallowing Assignments In Expressions? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-02-19 19:21 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-20 00:05 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 01:37 +0000
Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-20 03:32 -0500
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 17:06 +0000
Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-20 12:37 -0500
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 19:29 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 23:10 +0000
Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-21 00:34 -0500
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-21 06:20 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-20 16:19 +0100
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-19 18:19 -0800
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-20 17:20 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-20 09:46 -0800
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-20 19:39 +0000
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 18:14 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-20 11:01 -0800
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-20 20:09 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 23:03 +0000
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-21 00:33 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-21 00:45 +0000
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-21 01:57 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-21 06:21 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-21 09:14 +0100
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-20 09:06 +0100
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-20 11:20 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-20 13:03 +0100
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-21 01:35 -0800
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 02:43 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-20 11:02 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-20 13:37 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-20 16:32 +0100
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 17:12 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-21 09:27 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-21 11:08 +0000
Re: How About Disallowing Assignments In Expressions? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-20 12:43 -0800
Re: How About Disallowing Assignments In Expressions? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-20 12:43 -0800
Re: How About Disallowing Assignments In Expressions? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-20 12:11 -0800
Re: How About Disallowing Assignments In Expressions? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-20 12:13 -0800
Re: How About Disallowing Assignments In Expressions? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-02-21 01:29 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-19 02:12 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-19 09:00 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 23:41 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 23:42 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-19 02:14 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-19 05:17 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-19 09:29 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 01:33 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 16:18 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 17:55 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 01:34 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-18 23:46 +0100
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-17 17:22 -0800
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 07:48 +0000
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-18 09:34 +0000
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-18 11:30 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 12:00 +0000
Re: How About Disallowing Assignments In Expressions? Richard Harnden <richard.harnden@gmail.invalid> - 2024-02-18 12:39 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 22:19 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 15:59 +0100
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-18 23:48 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-15 16:41 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 01:16 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-16 08:54 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 23:08 +0000
Re: How About Disallowing Assignments In Expressions? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-16 15:23 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-16 17:13 -0800
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-17 12:04 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-17 13:10 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-17 16:01 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-17 15:54 +0000
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-17 22:08 +0200
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-17 20:13 +0000
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-17 22:33 +0200
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-18 15:52 +0100
Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-17 17:35 -0500
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-17 23:43 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 02:34 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-18 15:59 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 22:23 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-18 23:53 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 23:38 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-19 02:20 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-19 05:19 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-19 15:15 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-20 10:02 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-19 09:36 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 04:34 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-19 05:18 +0000
Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-19 00:39 -0500
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 01:35 +0000
Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-20 03:18 -0500
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-20 10:11 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 23:16 +0000
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-20 23:22 +0000
Re: How About Disallowing Assignments In Expressions? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-16 12:20 -0800
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-16 21:24 +0000
Re: How About Disallowing Assignments In Expressions? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-16 21:39 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 23:08 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-16 16:52 -0800
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-17 01:43 +0000
Re: How About Disallowing Assignments In Expressions? Richard Harnden <richard.harnden@gmail.invalid> - 2024-02-17 10:08 +0000
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-18 04:32 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-18 14:02 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 22:30 +0000
Re: How About Disallowing Assignments In Expressions? gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-17 05:07 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-17 12:09 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-17 13:07 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-17 16:54 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-17 18:46 +0100
Re: How About Disallowing Assignments In Expressions? gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-17 19:37 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-18 16:01 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 08:59 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-15 14:21 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-15 16:47 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-15 17:11 +0000
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-16 08:33 -0800
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-16 17:45 +0000
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-17 15:56 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 01:18 +0000
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-16 02:29 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-16 08:59 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 23:11 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-17 12:11 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 02:43 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-18 16:14 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 23:39 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-19 09:50 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 01:45 +0000
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-16 10:01 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 23:10 +0000
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-16 23:44 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 02:42 +0000
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-18 11:09 +0200
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 12:09 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 15:54 +0100
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-18 17:42 +0200
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 17:56 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 05:01 +0100
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-18 21:07 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 05:01 +0100
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-19 10:15 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 10:52 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 22:34 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-13 22:20 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-14 00:18 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-14 20:52 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-15 08:00 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 09:00 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-15 14:23 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 01:20 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-16 03:46 +0100
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-15 06:14 -0800
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 16:55 +0100
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-13 18:11 +0200
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-14 00:36 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-14 00:55 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-14 01:11 +0100
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-14 02:19 +0000
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-14 03:02 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-13 20:10 -0800
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-14 13:14 +0100
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-13 17:13 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-14 00:44 +0100
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-14 09:46 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-14 13:26 +0100
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-14 14:36 +0200
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-14 15:29 +0100
[OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-15 07:54 +0100
Re: [OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) David Brown <david.brown@hesbynett.no> - 2024-02-15 14:34 +0100
Re: [OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-16 03:49 +0100
Re: [OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) David Brown <david.brown@hesbynett.no> - 2024-02-16 09:04 +0100
Re: [OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-16 16:38 +0000
Re: [OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) David Brown <david.brown@hesbynett.no> - 2024-02-16 18:25 +0100
Re: [OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-16 12:23 -0800
Re: [OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 22:41 +0000
Re: [OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-16 15:29 -0800
Re: [OT] Pascal and popularity (was Re: How About Disallowing Assignments In Expressions?) G <g@nowhere.invalid> - 2024-02-16 18:11 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 08:47 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-15 15:15 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 08:48 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-15 15:16 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 01:12 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-16 04:03 +0100
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-16 09:49 +0100
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-16 15:35 +0200
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-17 18:54 +0100
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:52 +0100
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 13:15 -0800
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-12 12:49 +0100
Re: How About Disallowing Assignments In Expressions? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-12 14:51 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-12 15:33 -0800
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 17:09 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 21:48 +0000
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-10 22:47 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:57 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-12 01:14 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 17:14 +0100
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-13 17:34 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-14 01:21 +0100
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-13 16:59 -0800
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-14 12:02 +0200
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-14 15:54 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-14 08:03 -0800
Re: How About Disallowing Assignments In Expressions? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-14 20:31 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-14 21:53 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-14 14:47 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 08:42 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-15 14:40 +0100
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-14 22:04 -0800
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-14 22:11 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-14 22:31 -0800
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-17 16:10 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-17 16:45 -0800
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 02:35 +0100
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-17 18:07 -0800
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 06:45 +0100
Re: How About Disallowing Assignments In Expressions? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-18 12:37 -0500
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 02:30 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 06:46 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 06:12 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 15:38 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 10:57 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 02:28 +0000
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-18 11:02 +0200
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 15:36 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 11:01 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-18 15:31 +0100
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 17:43 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 22:10 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 05:06 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-18 22:09 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 05:14 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-19 05:13 +0000
Re: How About Disallowing Assignments In Expressions? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-19 07:54 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 17:48 +0100
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-19 08:58 -0800
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-19 18:14 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-20 01:31 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-20 09:26 +0100
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-19 17:58 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-19 19:17 -0800
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-14 22:07 -0800
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-14 15:50 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 15:58 -0800
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 16:52 +0100
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-13 18:23 +0200
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-13 17:06 +0000
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-13 19:41 +0200
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-13 18:31 +0000
Re: How About Disallowing Assignments In Expressions? scott@slp53.sl.home (Scott Lurndal) - 2024-02-13 18:34 +0000
Re: How About Disallowing Assignments In Expressions? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-13 18:40 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-13 13:20 -0800
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-15 08:38 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-13 13:14 -0800
Re: How About Disallowing Assignments In Expressions? bart <bc@freeuk.com> - 2024-02-09 15:43 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-09 16:57 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 17:29 +0100
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-13 19:22 +0200
Re: How About Disallowing Assignments In Expressions? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-13 17:30 +0000
Re: How About Disallowing Assignments In Expressions? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-13 17:33 +0000
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-13 19:49 +0200
Re: How About Disallowing Assignments In Expressions? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-13 18:01 +0000
Re: How About Disallowing Assignments In Expressions? Michael S <already5chosen@yahoo.com> - 2024-02-13 20:19 +0200
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-13 19:02 +0100
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-13 13:25 -0800
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-14 21:54 -0800
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-14 22:17 -0800
Re: How About Disallowing Assignments In Expressions? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-15 06:07 -0800
Re: How About Disallowing Assignments In Expressions? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-02-09 19:47 +0000
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 21:31 +0000
Re: How About Disallowing Assignments In Expressions? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-02-10 08:05 +0000
Re: How About Disallowing Assignments In Expressions? David Brown <david.brown@hesbynett.no> - 2024-02-10 17:06 +0100
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 17:39 +0100
Re: How About Disallowing Assignments In Expressions? Richard Kettlewell <invalid@invalid.invalid> - 2024-02-11 17:21 +0000
Re: How About Disallowing Assignments In Expressions? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 16:12 -0300
Re: How About Disallowing Assignments In Expressions? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 16:15 -0300
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-12 01:13 +0000
Re: How About Disallowing Assignments In Expressions? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 19:09 -0800
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-13 17:52 +0100
Re: How About Disallowing Assignments In Expressions? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-16 01:09 +0000
Re: How About Disallowing Assignments In Expressions? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-16 04:11 +0100
Page 6 of 26 — ← Prev page 1 … 4 5 [6] 7 8 … 26 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-13 15:10 +0100 |
| Message-ID | <uqft7s$2458n$1@dont-email.me> |
| In reply to | #382394 |
On 13/02/2024 13:32, bart wrote:
> On 13/02/2024 10:36, David Brown wrote:
>> On 13/02/2024 10:35, Malcolm McLean wrote:
>>> On 13/02/2024 08:07, David Brown wrote:
>
>>> The "C implentation" would be be the program created by the person
>>> who writes the complier.
>>
>> No, that would be the compiler.
>>
>> The "C implementation" includes the compiler, associated tools like
>> assemblers and linkers, headers, the standard C library, and parts of
>> the target system that are needed in order to execute the program.
>>
>>> The "C installation" the system set up by the person who provides the
>>> compiler.
>>
>> I am trying to understand what you mean by this - as usual, it is not
>> easy as you insist on using your own invented terms in your own way,
>> and have great difficultly explaining them to others.
>>
>> Maybe you are talking about what others might refer to as a "toolchain",
>
>
> It seems clear to me what the difference is between installation and
> implementation.
>
> A factory implements a washing machine, and somebody else decides where
> to install it in their house and how and to what it is hooked up.
I would agree with that difference (and the distinction you made below,
which I snipped for brevity).
But it is not, apparently, what Malcolm is talking about.
However, I am pretty sure that that discussion is going nowhere, and
Malcolm will continue in his Humpty-Dumpty quest to use words to mean
exactly what /he/ thinks they mean, rather than trying to communicate
sensibly with others. And I am also fairly sure that it doesn't affect
the issues with booleans.
>>> Often one and the same, but not necessarily. You can have a compiler
>>> written by someone else and an API written by someone else, put them
>>> together, and say "this shall be what we use to create C programs for
>>> this platform". So you have set up the C installation, but you are
>>> not the implementor.
>>>
>>
>> The term "C implementation" is not connected to who makes the
>> compiler, library, installation packages or anything else. It's a
>> /thing/, not a person or group, and it is the characteristics of the C
>> implementation that are important, not where it came from.
>
> So it just 'exists' without anyone having created it?
>
No. But the creator is irrelevant. A car is a "car" because of how it
works and what you can do with it. It doesn't matter if you built it
yourself or bought one pre-built.
>
>> Yes, a standard boolean type is an extremely important feature in a
>> programming language. The fact that C did not have one until C99 has
>> resulted in a great deal of inconvenience and wasted effort. Then in
>> 1999, we got a standard boolean type in C. Use it! No, it is not
>> sufficient to have a "typedef int bool" in a header to make a /good/
>> boolean type. No, "true" should not be -1. No, you should never
>> define your own type "bool".
>
> It's not /that/ important. The concept is more important than having a
> dedicated type.
The concept is made a lot clearer by having a dedicated type.
>
> I added a proper boolean type to my scripting language at one point.
> Then I streamlined it and got rid of it.
>
> There is an `integer` type which can represent a million different kinds
> of things; why make a special type for a thing that has the values of 0
> or 1?
The special type should hold values of true and false - it is the
restriction of the values that makes it special, and makes it suitable
for the concept of a boolean truth value. The restriction of values is key.
>
> (In dynamic code, extra types mean spending longer doing runtime type
> checking.)
>
> A proper _Bool type gives the possibility of arrays of _Bools that
> occupy one bit per element. However that doesn't happen here:
>
> _Bool A[1024];
> printf("%zu\n", sizeof(A));
>
> I get '1024' with gcc -O3, not 128. (My scripting language, despite not
> having Bool, does have 1-bit arrays. Those can be more useful.)
C's concepts of objects and arrays disallow such compact arrays. This
is both a limitation and a feature. On the one hand, it means you can't
conveniently have space-saving bit/bool arrays. On the other hand, it
means that if "xs" is an array, you can always access different elements
independently, all objects have unique addresses (within their
lifetimes), underlying representations of objects can copied with
memcpy(), every object has a "sizeof" size in bytes, and so on. Compact
bit/bool arrays are a useful concept, but would not fit as normal arrays
in C.
>
>>> will not be interpreted correctly. But we can live with that.
>>
>> We can live with all kinds of things - that does not mean we /should/
>> live with it.
>>
>> Pico C appears to be a dead project. And it was never intended to be
>> more than a tiny handler for a subset of C - of unspecified version,
>> and without any attempt at conformance. It's broken version of
>> <stdbool.h> is dangerously wrong and has no place in anything that
>> claims to call itself "C" or "C-like". It should be either fixed, or
>> removed entirely.
>
> You're fond of saying that.
I think it is important.
I'm fine with compilers (or other C tools) handling only a subset of C,
or only an older version of the language. I'm fine with them having
extensions. I'm fine with them being not quite perfect, or having some
limitations or missing elements. But there are three things I want
tools to do:
1. Document what version of the C standards they support, what
limitations or subsets it has, and what extensions it has. Document how
to enable or disable these.
2. Make it clear right at the start if it really is a "C" tool, able to
conform substantially to at least one C standard, or a "Sort-of C" tool
that has significant and intentional deviations.
3. Do not have features that are syntactically the same as features of
C, but do not conform semantically to C. If there are outstanding
reasons for this, then it must at least be clearly documented.
Pico C breaks point 3 here, and it does so for no good reason. It could
simply have omitted <stdbool.h> and been just as useful. There is no
situation in which it is a good idea to have a <stdbool.h> header
defining a "bool" type that does not conform to the C99 "_Bool" type.
I've seen other compilers break point 3 for at least somewhat good
reasons, such as microcontroller compilers that have 32-bit "double" types.
The problem with this is that existing correct code could appear to
compile cleanly, but not work as expected even if the code was fully
portable conforming C. That is never a good thing.
I am not saying that tools that break these rules are not useful - I am
simply saying that I want tools that do so to be clear about it and
document it.
>
>> But as it is a dead project there is little point in reporting the
>> error.
>>
>>
>>>
>>> The Pico C would be our "C installation" by the way.
>>
>> Or, to use the correct term, the "C implementation". Or perhaps the
>> "Sort-of C implementation".
>
> Even C++ is a 'sort-of-C' implementation.
You could certainly consider it as having a sort-of C subset, yes.
>
> Suppose you have a C program that uses 85% of the features of C. You use
> a C compiler which only implements that same 85% subset. Your program
> works perfectly.
>
> But I guess you would still look down your knows at such a product?
>
If it implements a useful 85% subset of C (of some standard), and
/documents/ its missing features, that's fine.
I am fine with an implementation that says it implements C99 except for
complex numbers, wide characters and VLAs. No problem.
I am not fine an implementation that says it implements C99, and
provides <complex.h> where functions like ccos() were implement as a
simple "return" assembly instruction.
Do you see the difference?
> Some C compilers implement a subset of the language, some a superset. I
> expect a superset is fine? But neither are actually C!
>
Supersets are also fine, as long as they don't conflict with conforming
C. (It's okay if there are documented ways to enable or disable them.
A compiler could have "asm" statements as an extension, but should have
a flag to disable this for code that uses "asm" as an identifier.) And
to be useful, they should be documented.
> And of course, using compiler options to further customise the language
> is also acceptable.
Yes, when documented.
>
> "PicoC is a very small C interpreter for scripting. It was originally
> written as the script language for a UAV's on-board flight system. It's
> also very suitable for other robotic, embedded and non-embedded
> applications."
>
> Do you object to its use of "C"?
>
I don't know if it is close enough to some version of C for it to be
reasonable to call it a "C compiler" (or "C interpreter") without
qualification. I haven't looked at it in any kind of detail. But I
/do/ know it has a <stdbool.h> header that most certainly does not
define a C "bool" type, and I see that as a problem. In particular, it
is a pointless problem - it serves no purpose, but could cause subtle
problems when used with code that is correct and conforming C, tested
and debugged with other implementations.
That does not mean that it is not a useful tool. But it would, IMHO, be
a /better/ tool if that header were simply omitted entirely.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-13 15:20 +0000 |
| Message-ID | <uqg1bv$24to4$1@dont-email.me> |
| In reply to | #382398 |
On 13/02/2024 14:10, David Brown wrote:
> On 13/02/2024 13:32, bart wrote:
>>
>>
>> "PicoC is a very small C interpreter for scripting. It was originally
>> written as the script language for a UAV's on-board flight system.
>> It's also very suitable for other robotic, embedded and non-embedded
>> applications."
>>
>> Do you object to its use of "C"?
>>
>
> I don't know if it is close enough to some version of C for it to be
> reasonable to call it a "C compiler" (or "C interpreter") without
> qualification. I haven't looked at it in any kind of detail. But I
> /do/ know it has a <stdbool.h> header that most certainly does not
> define a C "bool" type, and I see that as a problem. In particular, it
> is a pointless problem - it serves no purpose, but could cause subtle
> problems when used with code that is correct and conforming C, tested
> and debugged with other implementations.
>
So this is how they do it.
/* string.h library for large systems - small embedded systems use
clibrary.c instead */
#include "../interpreter.h"
#ifndef BUILTIN_MINI_STDLIB
static int trueValue = 1;
static int falseValue = 0;
/* structure definitions */
const char StdboolDefs[] = "typedef int bool;";
/* creates various system-dependent definitions */
void StdboolSetupFunc(Picoc *pc)
{
/* defines */
VariableDefinePlatformVar(pc, NULL, "true", &pc->IntType, (union
AnyValue *)&trueValue, FALSE);
VariableDefinePlatformVar(pc, NULL, "false", &pc->IntType, (union
AnyValue *)&falseValue, FALSE);
VariableDefinePlatformVar(pc, NULL,
"__bool_true_false_are_defined", &pc->IntType, (union AnyValue
*)&trueValue, FALSE);
}
#endif /* !BUILTIN_MINI_STDLIB */
Whilst I have't actually checked, presumably the interpreter calls
StdBoolSetUpFunc() when it hits "#include <stdbool.h>", and that puts
variables called "true" and "false" which are ints into global scope,
plus another int (not a boolean ironically) to flag that the function
has been called. Somehow the typedef is picked up elsewhere.
> That does not mean that it is not a useful tool. But it would, IMHO, be
> a /better/ tool if that header were simply omitted entirely.
>
>
Now this means that the vast majority of code which is sanely written
and uses "stdbool.h", but isn't written specifically for Pico C, will be
interpreted correctly. But an tiny amount may break. And if it is
running on a UAV which is armed with a nuclear missile, that may be a
bit alarming. But mostly it won't be, and it will be fine.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-13 17:30 +0100 |
| Message-ID | <uqg5fo$25m7f$1@dont-email.me> |
| In reply to | #382399 |
On 13/02/2024 16:20, Malcolm McLean wrote:
> On 13/02/2024 14:10, David Brown wrote:
>> On 13/02/2024 13:32, bart wrote:
>>>
>>>
>>> "PicoC is a very small C interpreter for scripting. It was originally
>>> written as the script language for a UAV's on-board flight system.
>>> It's also very suitable for other robotic, embedded and non-embedded
>>> applications."
>>>
>>> Do you object to its use of "C"?
>>>
>>
>> I don't know if it is close enough to some version of C for it to be
>> reasonable to call it a "C compiler" (or "C interpreter") without
>> qualification. I haven't looked at it in any kind of detail. But I
>> /do/ know it has a <stdbool.h> header that most certainly does not
>> define a C "bool" type, and I see that as a problem. In particular,
>> it is a pointless problem - it serves no purpose, but could cause
>> subtle problems when used with code that is correct and conforming C,
>> tested and debugged with other implementations.
>>
> So this is how they do it.
By "they", you mean "the Pico C source code" rather than any users of
Pico C, or anyone else.
>
> /* string.h library for large systems - small embedded systems use
> clibrary.c instead */
> #include "../interpreter.h"
>
> #ifndef BUILTIN_MINI_STDLIB
>
> static int trueValue = 1;
> static int falseValue = 0;
>
>
> /* structure definitions */
> const char StdboolDefs[] = "typedef int bool;";
>
> /* creates various system-dependent definitions */
> void StdboolSetupFunc(Picoc *pc)
> {
> /* defines */
> VariableDefinePlatformVar(pc, NULL, "true", &pc->IntType, (union
> AnyValue *)&trueValue, FALSE);
> VariableDefinePlatformVar(pc, NULL, "false", &pc->IntType, (union
> AnyValue *)&falseValue, FALSE);
> VariableDefinePlatformVar(pc, NULL,
> "__bool_true_false_are_defined", &pc->IntType, (union AnyValue
> *)&trueValue, FALSE);
> }
>
> #endif /* !BUILTIN_MINI_STDLIB */
>
> Whilst I have't actually checked, presumably the interpreter calls
> StdBoolSetUpFunc() when it hits "#include <stdbool.h>", and that puts
> variables called "true" and "false" which are ints into global scope,
> plus another int (not a boolean ironically) to flag that the function
> has been called. Somehow the typedef is picked up elsewhere.
>
>
>> That does not mean that it is not a useful tool. But it would, IMHO,
>> be a /better/ tool if that header were simply omitted entirely.
>>
>>
> Now this means that the vast majority of code which is sanely written
> and uses "stdbool.h", but isn't written specifically for Pico C, will be
> interpreted correctly.
That is not true.
Code that relies on "bool" values being 0 or 1 is perfectly "sane", and
will not work with the broken "bool" in Pico C.
Code that uses "bool b = p;", where "p" is a pointer, is perfectly sane
and may not work if Pico C correctly complains about the constraint
error from "int b = p;".
It is true that a lot of code that uses "bool", "true" and "false" will
work in the face of "typedef int bool". It is also true that some will
not - and there was nothing wrong or insane about the code. Such code
may fail subtly with Pico C, and only in some circumstances. People
using it will have to check their code, and change anything of the form
"bool b = x;" into "bool b = !!x;" to be sure.
> But an tiny amount may break. And if it is
> running on a UAV which is armed with a nuclear missile, that may be a
> bit alarming. But mostly it won't be, and it will be fine.
>
I am not at ease with an attitude of "There's a completely unnecessary,
known and easily fixable mistake in this software, but hopefully you
won't be using the tool for anything too serious and won't have many
problems". That is simply not how a programmer should think.
This one case rules out Pico C for me. I can agree that most uses of
"bool" will be okay - but apparently the Pico C author couldn't care
less about such things, and has neither the knowledge nor interest in
finding out how C is defined, and the project has no reviewers, testers,
bug reporters or checkers who are capable of confirming its correctness.
I could not trust that the program is doing the right thing for
anything else - there could be countless other small subtle things that
would go wrong with perfectly good C code. (Looking through the issues
for the project, it seems this is definitely the case.)
Don't misunderstand me here - I have no reason to demand or expect that
the Pico C author should only write quality tools that conform
accurately to the C standards. He/she could have written a simple
little tool, and published it for others to play with. And maybe it is
good enough for some uses. But it is not of the quality I would want
for a language tool - at least not without clear information and
documentation about its limitations.
I have filed this issue with Pico C, despite the project being dead, so
that anyone considering using it can see the problem.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-13 17:35 +0000 |
| Message-ID | <uqg99s$26d7a$1@dont-email.me> |
| In reply to | #382411 |
On 13/02/2024 16:30, David Brown wrote: > On 13/02/2024 16:20, Malcolm McLean wrote: >> >>> >> Now this means that the vast majority of code which is sanely written >> and uses "stdbool.h", but isn't written specifically for Pico C, will >> be interpreted correctly. > > That is not true. > > Code that relies on "bool" values being 0 or 1 is perfectly "sane", and > will not work with the broken "bool" in Pico C. > Pico C won't coerce a boolean to 1 or 0. Whilst it's easy t devise perfectly legal C code where this matters, it's less easy to think of an example which could also be defended as "sane". > > Code that uses "bool b = p;", where "p" is a pointer, is perfectly sane > and may not work if Pico C correctly complains about the constraint > error from "int b = p;". > Though that is an exception. A null pointer is conventionally "not there", and so it's reasonable for null / not null to be boolean. However bool b = p; still isn't very good. It should be bool b = p ? true : false; to make it explicit.> > It is true that a lot of code that uses "bool", "true" and "false" will > work in the face of "typedef int bool". It is also true that some will > not - and there was nothing wrong or insane about the code. Such code > may fail subtly with Pico C, and only in some circumstances. People > using it will have to check their code, and change anything of the form > "bool b = x;" into "bool b = !!x;" to be sure. > And if we rip out stdbool.h support, none of the code wll work. However it won;t fail subty an donly in some circumstances. > > >> But an tiny amount may break. And if it is running on a UAV which is >> armed with a nuclear missile, that may be a bit alarming. But mostly >> it won't be, and it will be fine. >> > > I am not at ease with an attitude of "There's a completely unnecessary, > known and easily fixable mistake in this software, but hopefully you > won't be using the tool for anything too serious and won't have many > problems". That is simply not how a programmer should think. > Well you don't seem to understand the realities of it. I'm sure I've the skills to patch Pico C to have a real boolean type which only has one bit. But I can't do that quickly or easily. And Pico C is not under active development, and they say it is frozen and they want to keep it small. It's likely that no-one will accept the pull request. So now our Pico C has diverged from the trunk, and that causes issues. And a lot of programs are not too serious, or the costs of bugs are not too high. > > This one case rules out Pico C for me. I can agree that most uses of > "bool" will be okay - but apparently the Pico C author couldn't care > less about such things, and has neither the knowledge nor interest in > finding out how C is defined, and the project has no reviewers, testers, > bug reporters or checkers who are capable of confirming its correctness. > I could not trust that the program is doing the right thing for > anything else - there could be countless other small subtle things that > would go wrong with perfectly good C code. (Looking through the issues > for the project, it seems this is definitely the case.) > > Don't misunderstand me here - I have no reason to demand or expect that > the Pico C author should only write quality tools that conform > accurately to the C standards. He/she could have written a simple > little tool, and published it for others to play with. And maybe it is > good enough for some uses. But it is not of the quality I would want > for a language tool - at least not without clear information and > documentation about its limitations. > It was used in a real UAV. So it was connected to something which could crash. But the danger is that people might submit to it long functions in general purpose C code which was written for a fully conforming compiler, and it's not really up to that. I would agree. But often if you have a C interpreter, that's not how its going to be used. The Baby X resource compiler needs a way of converting a pixel value to an arbitrary output format, and my current answer to that is "you are a C programmer, just dive into the code and hack". But it's hardly ideal, and a little "rgb triplet to C" function specified in some description language would be the better approach. And Pico C would support that. Virtually every function would be so trivial that the limitations. wouldn't matter. > > I have filed this issue with Pico C, despite the project being dead, so > that anyone considering using it can see the problem. >If anyone is interested in Pico C we could fork it and enhance it. But I can't think of many uses for a C interpreter. It's theoretically interesting to have an intepreter rather than a compiler, however. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-13 18:58 +0100 |
| Message-ID | <uqgakm$26kkk$1@dont-email.me> |
| In reply to | #382419 |
On 13/02/2024 18:35, Malcolm McLean wrote:
> On 13/02/2024 16:30, David Brown wrote:
>> On 13/02/2024 16:20, Malcolm McLean wrote:
>>>
>
>>>>
>>> Now this means that the vast majority of code which is sanely written
>>> and uses "stdbool.h", but isn't written specifically for Pico C, will
>>> be interpreted correctly.
>>
>> That is not true.
>>
>> Code that relies on "bool" values being 0 or 1 is perfectly "sane",
>> and will not work with the broken "bool" in Pico C.
>>
> Pico C won't coerce a boolean to 1 or 0. Whilst it's easy t devise
> perfectly legal C code where this matters, it's less easy to think of an
> example which could also be defended as "sane".
inline bool majority_of_three(bool a, bool b, bool c) {
return (a + b + c) >= 2;
}
This can be used with arguments of any scaler type. That relies both on
the constraints and semantics of converting to bool which "int" does not
share, and on the bool values being 0 or 1.
I can certainly tell you that I have written code that relies on bool's
being 0 or 1, and that I only write "sane" code. I can't be bothered
searching projects for real examples.
I am not claiming it is common, but it certainly exists.
> >
>> Code that uses "bool b = p;", where "p" is a pointer, is perfectly
>> sane and may not work if Pico C correctly complains about the
>> constraint error from "int b = p;".
>>
> Though that is an exception. A null pointer is conventionally "not
> there", and so it's reasonable for null / not null to be boolean.
> However bool b = p; still isn't very good. It should be bool b = p ?
> true : false; to make it explicit.>
Why? It is common to write "if (p) ...", or "while (p) ...". If I
thought it would be clearer, I would consider "bool b = (bool) p;".
>> It is true that a lot of code that uses "bool", "true" and "false"
>> will work in the face of "typedef int bool". It is also true that
>> some will not - and there was nothing wrong or insane about the code.
>> Such code may fail subtly with Pico C, and only in some
>> circumstances. People using it will have to check their code, and
>> change anything of the form "bool b = x;" into "bool b = !!x;" to be
>> sure.
>> And if we rip out stdbool.h support, none of the code wll work. However
> it won;t fail subty an donly in some circumstances.
Hard failures are better than subtle and invisible failures.
Pico C is does not, AFAIK, support C99 in general - there is no reason
to suppose it will work with code that uses <stdbool.h>.
>>
>>
>>> But an tiny amount may break. And if it is running on a UAV which is
>>> armed with a nuclear missile, that may be a bit alarming. But mostly
>>> it won't be, and it will be fine.
>>>
>>
>> I am not at ease with an attitude of "There's a completely
>> unnecessary, known and easily fixable mistake in this software, but
>> hopefully you won't be using the tool for anything too serious and
>> won't have many problems". That is simply not how a programmer should
>> think.
>>
> Well you don't seem to understand the realities of it. I'm sure I've the
> skills to patch Pico C to have a real boolean type which only has one
> bit. But I can't do that quickly or easily. And Pico C is not under
> active development, and they say it is frozen and they want to keep it
> small. It's likely that no-one will accept the pull request. So now our
> Pico C has diverged from the trunk, and that causes issues. And a lot of
> programs are not too serious, or the costs of bugs are not too high.
I am not blaming /you/ for mistakes in Pico C. I am blaming the author
of Pico C for them, and for not documenting the limitations and
non-conformities.
I am blaming /you/ for your statements defending blatantly incorrect
code and saying "it will be fine".
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-13 18:27 +0000 |
| Message-ID | <rwOyN.323519$7sbb.202542@fx16.iad> |
| In reply to | #382419 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On 13/02/2024 16:30, David Brown wrote: > The Baby >X resource compiler needs a way of converting a pixel value to an >arbitrary output format, and my current answer to that is "you are a C >programmer, Mine answer would be to use netpbm rather than reinventing the wheel for the Nth time.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-13 19:54 +0000 |
| Message-ID | <uqghei$27te2$1@dont-email.me> |
| In reply to | #382426 |
On 13/02/2024 18:27, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> On 13/02/2024 16:30, David Brown wrote: >> The Baby >> X resource compiler needs a way of converting a pixel value to an >> arbitrary output format, and my current answer to that is "you are a C >> programmer, > > Mine answer would be to use netpbm rather than reinventing the wheel > for the Nth time. I checked that out. This is the relevant program. https://netpbm.sourceforge.net/doc/ppmtoarbtxt.html However whilst this might be able to be configured to do what we want, I think there is still a case for a dedicated resource compiler. However it's open source, so maybe steal the grammar rules. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-13 21:08 +0000 |
| Message-ID | <uqglp6$28nv0$1@dont-email.me> |
| In reply to | #382430 |
On 13/02/2024 19:54, Malcolm McLean wrote: > On 13/02/2024 18:27, Scott Lurndal wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> On 13/02/2024 16:30, David Brown wrote: >>> The Baby >>> X resource compiler needs a way of converting a pixel value to an >>> arbitrary output format, and my current answer to that is "you are a C >>> programmer, >> >> Mine answer would be to use netpbm rather than reinventing the wheel >> for the Nth time. > > I checked that out. > This is the relevant program. > > https://netpbm.sourceforge.net/doc/ppmtoarbtxt.html No, that's not Linux-centric at all! I looked at the sources, and it's the usual story. At least, the configure file here only runs a Perl script, which is a bit different. I tried just compiling one sample program, but it's missing pm_config, presumably creating during some elaborate configuration process. You'd have thought that image-processing, translating one file to another, is among the most portable of tasks. More so even than language tools as there is no target platform involved. So why can't it 'just work'? Provide some default pm_config.h if necessary. This is why reinventing the wheel can be fruitful. Here, just incorporating someone else's wheels is hard. (There are binaries of these for Windows that I saw, dated 2005, but there are 300 small programs; an unwieldy set of dependencies.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-13 21:15 +0000 |
| Message-ID | <i_QyN.358394$xHn7.118760@fx14.iad> |
| In reply to | #382432 |
bart <bc@freeuk.com> writes: >On 13/02/2024 19:54, Malcolm McLean wrote: >> On 13/02/2024 18:27, Scott Lurndal wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> On 13/02/2024 16:30, David Brown wrote: >>>> The Baby >>>> X resource compiler needs a way of converting a pixel value to an >>>> arbitrary output format, and my current answer to that is "you are a C >>>> programmer, >>> >>> Mine answer would be to use netpbm rather than reinventing the wheel >>> for the Nth time. >> >> I checked that out. >> This is the relevant program. >> >> https://netpbm.sourceforge.net/doc/ppmtoarbtxt.html > >No, that's not Linux-centric at all! It predates linux and ran on dozens of unix variants. <deleted another bart rant>
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-13 22:50 +0000 |
| Message-ID | <uqgro0$29m9i$1@dont-email.me> |
| In reply to | #382434 |
On 13/02/2024 21:15, Scott Lurndal wrote: > bart <bc@freeuk.com> writes: >> On 13/02/2024 19:54, Malcolm McLean wrote: >>> On 13/02/2024 18:27, Scott Lurndal wrote: >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>> On 13/02/2024 16:30, David Brown wrote: >>>>> The Baby >>>>> X resource compiler needs a way of converting a pixel value to an >>>>> arbitrary output format, and my current answer to that is "you are a C >>>>> programmer, >>>> >>>> Mine answer would be to use netpbm rather than reinventing the wheel >>>> for the Nth time. >>> >>> I checked that out. >>> This is the relevant program. >>> >>> https://netpbm.sourceforge.net/doc/ppmtoarbtxt.html >> >> No, that's not Linux-centric at all! > > It predates linux and ran on dozens of unix variants. > > <deleted another bart rant> Some observations suggesting why there might be good reasons for reinventing wheels. You don't see it because you permanently live in a Unix-shaped box and everything you deal with is designed for that box.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-16 22:45 +0000 |
| Message-ID | <uqooi7$25h4$4@dont-email.me> |
| In reply to | #382440 |
On Tue, 13 Feb 2024 22:50:40 +0000, bart wrote: > You don't see it because you permanently live in a Unix-shaped box and > everything you deal with is designed for that box. Think of the walls of any box as dividing the Universe into two parts. The way you tell which is which is that “inside” is normally much smaller than “outside”. Now think of the wall between you and us: we are the ones who are free to stretch our arms out, walk and run and even fly about freely, while you are the one complaining about not being able to do the same. Which one sounds more like “inside” and which one “outside”?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-16 23:55 +0000 |
| Message-ID | <uqosks$2si8$1@dont-email.me> |
| In reply to | #382592 |
On 16/02/2024 22:45, Lawrence D'Oliveiro wrote: > On Tue, 13 Feb 2024 22:50:40 +0000, bart wrote: > >> You don't see it because you permanently live in a Unix-shaped box and >> everything you deal with is designed for that box. > > Think of the walls of any box as dividing the Universe into two parts. The > way you tell which is which is that “inside” is normally much smaller than > “outside”. > > Now think of the wall between you and us: we are the ones who are free to > stretch our arms out, walk and run and even fly about freely, while you > are the one complaining about not being able to do the same. > > Which one sounds more like “inside” and which one “outside”? It sounds like you're the ones who are locked in to all those myriad different tools and all your different systems. I got my first portable machine exactly 30 years ago, and for the next decade or two was able to work anywhere, either camping next to a beach, or on a tropical island, or from my car. I didn't need the internet!
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-18 02:22 +0000 |
| Message-ID | <uqrpld$n43b$2@dont-email.me> |
| In reply to | #382604 |
On Fri, 16 Feb 2024 23:55:07 +0000, bart wrote: > On 16/02/2024 22:45, Lawrence D'Oliveiro wrote: > >> Which one sounds more like “inside” and which one “outside”? > > It sounds like you're the ones who are locked in to all those myriad > different tools and all your different systems. Great. So what are you complaining about? Because remember, most of the noise and whining seems to be coming from your side of the wall, not ours.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-16 22:43 +0000 |
| Message-ID | <uqoodu$25h4$3@dont-email.me> |
| In reply to | #382432 |
On Tue, 13 Feb 2024 21:08:55 +0000, bart wrote: > No, that's not Linux-centric at all! Feel free to stick to the Windows-centric equivalent, then.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-13 12:58 -0800 |
| Message-ID | <877cj8axo6.fsf@nosuchdomain.example.com> |
| In reply to | #382399 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Now this means that the vast majority of code which is sanely written
> and uses "stdbool.h", but isn't written specifically for Pico C, will
> be interpreted correctly. But an tiny amount may break. And if it is
> running on a UAV which is armed with a nuclear missile, that may be a
> bit alarming. But mostly it won't be, and it will be fine.
You're suggesting that correctness doesn't matter unless the software
controls nuclear missiles.
No. Even if that was hyperbole -- no.
--
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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-13 22:56 +0000 |
| Message-ID | <uqgs2c$29nvr$1@dont-email.me> |
| In reply to | #382431 |
On 13/02/2024 20:58, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] >> Now this means that the vast majority of code which is sanely written >> and uses "stdbool.h", but isn't written specifically for Pico C, will >> be interpreted correctly. But an tiny amount may break. And if it is >> running on a UAV which is armed with a nuclear missile, that may be a >> bit alarming. But mostly it won't be, and it will be fine. > > You're suggesting that correctness doesn't matter unless the software > controls nuclear missiles. > > No. Even if that was hyperbole -- no. > But if software is running on a UAV which carries nuclear missiles and something goes wrong, millions of people might be killed. Whilst if the software that I write for a living goes wrong the worst thing that can happen on any plausible scenario is that an artist's drawing gets ruined and my company's liability for that is limited to a hundred and twenty dollars. You do see the difference. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-13 15:30 -0800 |
| Message-ID | <87eddg9c2r.fsf@nosuchdomain.example.com> |
| In reply to | #382441 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 13/02/2024 20:58, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>>> Now this means that the vast majority of code which is sanely written
>>> and uses "stdbool.h", but isn't written specifically for Pico C, will
>>> be interpreted correctly. But an tiny amount may break. And if it is
>>> running on a UAV which is armed with a nuclear missile, that may be a
>>> bit alarming. But mostly it won't be, and it will be fine.
>> You're suggesting that correctness doesn't matter unless the
>> software
>> controls nuclear missiles.
>> No. Even if that was hyperbole -- no.
>>
> But if software is running on a UAV which carries nuclear missiles and
> something goes wrong, millions of people might be killed. Whilst if
> the software that I write for a living goes wrong the worst thing that
> can happen on any plausible scenario is that an artist's drawing gets
> ruined and my company's liability for that is limited to a hundred and
> twenty dollars. You do see the difference.
Of course I see the difference. You apparently don't understand my
objection to your statement.
*Of course* correctness matters when software is used to control nuclear
missiles. You suggested that it doesn't matter when software isn't used
to control nuclear missiles.
The software I work on in my current job doesn't control nuclear
missiles, but errors could literally kill people.
Errors in software in other fields could cost substantial amounts of
money, or subject people to civil or criminal liability, or cause
illness or injury, or damage the reputation of the company that sells
it, or any of a number of other possible Bad Things.
Sure, sometimes correctness is important, and sometimes it's far less
so. I set the bar at or slightly above quick programs that I write, run
once, and discard. You seem to be setting it just below nukes. Perhaps
that's not what you meant, but it's what you wrote.
And if you're suggesting that ruining a customer's art and being liable
for $120 is no big deal, then ...
Oh, never mind, I'm not even going to finish that sentence.
--
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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-14 02:48 +0000 |
| Message-ID | <uqh9mc$2bss0$1@dont-email.me> |
| In reply to | #382444 |
On 13/02/2024 23:30, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> On 13/02/2024 20:58, Keith Thompson wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> [...] >>>> Now this means that the vast majority of code which is sanely written >>>> and uses "stdbool.h", but isn't written specifically for Pico C, will >>>> be interpreted correctly. But an tiny amount may break. And if it is >>>> running on a UAV which is armed with a nuclear missile, that may be a >>>> bit alarming. But mostly it won't be, and it will be fine. >>> You're suggesting that correctness doesn't matter unless the >>> software >>> controls nuclear missiles. >>> No. Even if that was hyperbole -- no. >>> >> But if software is running on a UAV which carries nuclear missiles and >> something goes wrong, millions of people might be killed. Whilst if >> the software that I write for a living goes wrong the worst thing that >> can happen on any plausible scenario is that an artist's drawing gets >> ruined and my company's liability for that is limited to a hundred and >> twenty dollars. You do see the difference. > > Of course I see the difference. You apparently don't understand my > objection to your statement. > > *Of course* correctness matters when software is used to control nuclear > missiles. You suggested that it doesn't matter when software isn't used > to control nuclear missiles. > > The software I work on in my current job doesn't control nuclear > missiles, but errors could literally kill people. > > Errors in software in other fields could cost substantial amounts of > money, or subject people to civil or criminal liability, or cause > illness or injury, or damage the reputation of the company that sells > it, or any of a number of other possible Bad Things. > > Sure, sometimes correctness is important, and sometimes it's far less > so. I set the bar at or slightly above quick programs that I write, run > once, and discard. You seem to be setting it just below nukes. Perhaps > that's not what you meant, but it's what you wrote. > > And if you're suggesting that ruining a customer's art and being liable > for $120 is no big deal, then ... > > Oh, never mind, I'm not even going to finish that sentence. > Of course we can't afford a reputation for selling buggy software which ruins the artist's artwork. So everything is tested quite a lot before release. But in the nature of interactive graphical software, if it looks OK, it generally for that reason is OK. So the tests are quite easy to do. But if something goes wrong and a bug does slip through, all we can be sued for for 120 dollars. And an innocent kitten cannot by any plausible chain of consequences be killed, we don't have to worry about that sort of issue. Then the drawng platform we run under isn't exactly bug free. Whilst there is a point in having a perfect tool which runs under an imperfect platform, because at least it is never crashing in the tool itself, if it will crash on occasion because of the platform anyway. So yes, obviously we try not to ship bugs. But if we had to double the cost of the software to achieve the same standards of correctness which you must achieve, because you can kill people if there is a bug in yuur software, it would be a poor business decision and not a good use of resources. Personally I would be unhappy using Pico C for a UAV, but not for the proof of concept programmig language hobby project which was what I tried to use it for. However in fact it has been used for a UAV. So my perception of the standrads required for admittedly unamanned aircraft may be wrong. I've never written any software for aviation. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-14 09:35 +0100 |
| Message-ID | <uqhtvp$2ilrc$1@dont-email.me> |
| In reply to | #382441 |
On 13/02/2024 23:56, Malcolm McLean wrote: > On 13/02/2024 20:58, Keith Thompson wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> [...] >>> Now this means that the vast majority of code which is sanely written >>> and uses "stdbool.h", but isn't written specifically for Pico C, will >>> be interpreted correctly. But an tiny amount may break. And if it is >>> running on a UAV which is armed with a nuclear missile, that may be a >>> bit alarming. But mostly it won't be, and it will be fine. >> >> You're suggesting that correctness doesn't matter unless the software >> controls nuclear missiles. >> >> No. Even if that was hyperbole -- no. >> > But if software is running on a UAV which carries nuclear missiles and > something goes wrong, millions of people might be killed. Whilst if the > software that I write for a living goes wrong the worst thing that can > happen on any plausible scenario is that an artist's drawing gets ruined > and my company's liability for that is limited to a hundred and twenty > dollars. You do see the difference. > You seem to be conflating the /risk/ of errors with the /consequences/ of errors. It is quite clear that if the consequences of an error are people getting killed, you need to handle things differently than if the consequences are image glitches in a frame of a computer game. Risk analysis involves considering the risks and consequences, and comparing it to the cost of finding and fixing errors. And the conclusion might be that you know your software has bugs, but it is not worth the cost trying to fix them - it is more economically viable to work around them or avoid them. Here we are talking about /known/ issues. The author of Pico C knows the <stdbool.h> implementation is wrong. (He also knows that his handling of integer promotions is wrong - and that's a error with far bigger effects.) A responsible software publisher will include a list of known issues here. The "readme.md" should have this information right at the top. Then potential users can do a risk assessment - they can estimate how likely it is that their code will hit these bugs, and what the consequences of that would be, and whether they can work around the issues or accept that the software is useful despite the risks. Hiding or denying the bugs, or glossing over them with "it will be fine", is irresponsible. So is an attitude of "you get what you pay for" - it's only $120 (or free), so you can expect things to break. It is fine to say that your time or budget does not extend to a development process that can eliminate all bugs - very little software can be written in a way that provably has no errors, and generally you can only do the best that resources allow to reduce the risk and consequences of errors. But when you /know/ you have a bug, it's a different matter. The simple act of documenting it clearer reduces the users' risk and consequences by orders of magnitude. For software, the biggest unknown factor is use and re-use. Bad bools are very unlikely to have major consequences if Bart uses Pico-C to script compilation of his code. But if the project gets forked and re-used, and embedded in other software, and eventually it ends up as part of a sandbox system for emulating or interpreting security software, it could be a completely different matter. The Pico C author's careless attitude, combined with the "it will be fine" thoughtlessness of people like you along the way, can result in big problems even though at each step it all looks like a very minor issue. Responsible programmers aim for correctness, for everything they code, all the time. They don't aim to find their bugs in testing, they aim to write code that they /know/ is correct, by design, and by knowledge of the surrounding code, the language, the tools. Sometimes they make mistakes. Sometimes there is an error outside their control, such as in the specifications. Sometimes outside pressure - management, sales, etc., - force them to leave code that they know is buggy or has high risks of errors. But they are not happy about it, and they don't ignore clear errors with "it will be fine".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-14 09:34 +0000 |
| Message-ID | <uqi1f2$2j7mt$1@dont-email.me> |
| In reply to | #382457 |
On 14/02/2024 08:35, David Brown wrote: > On 13/02/2024 23:56, Malcolm McLean wrote: >> On 13/02/2024 20:58, Keith Thompson wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> [...] >>>> Now this means that the vast majority of code which is sanely written >>>> and uses "stdbool.h", but isn't written specifically for Pico C, will >>>> be interpreted correctly. But an tiny amount may break. And if it is >>>> running on a UAV which is armed with a nuclear missile, that may be a >>>> bit alarming. But mostly it won't be, and it will be fine. >>> >>> You're suggesting that correctness doesn't matter unless the software >>> controls nuclear missiles. >>> >>> No. Even if that was hyperbole -- no. >>> >> But if software is running on a UAV which carries nuclear missiles and >> something goes wrong, millions of people might be killed. Whilst if >> the software that I write for a living goes wrong the worst thing that >> can happen on any plausible scenario is that an artist's drawing gets >> ruined and my company's liability for that is limited to a hundred and >> twenty dollars. You do see the difference. >> > > You seem to be conflating the /risk/ of errors with the /consequences/ > of errors. It is quite clear that if the consequences of an error are > people getting killed, you need to handle things differently than if the > consequences are image glitches in a frame of a computer game. > > Risk analysis involves considering the risks and consequences, and > comparing it to the cost of finding and fixing errors. And the > conclusion might be that you know your software has bugs, but it is not > worth the cost trying to fix them - it is more economically viable to > work around them or avoid them. > > Here we are talking about /known/ issues. The author of Pico C knows > the <stdbool.h> implementation is wrong. (He also knows that his > handling of integer promotions is wrong - and that's a error with far > bigger effects.) > > A responsible software publisher will include a list of known issues > here. The "readme.md" should have this information right at the top. > Then potential users can do a risk assessment - they can estimate how > likely it is that their code will hit these bugs, and what the > consequences of that would be, and whether they can work around the > issues or accept that the software is useful despite the risks. > > Hiding or denying the bugs, or glossing over them with "it will be > fine", is irresponsible. So is an attitude of "you get what you pay > for" - it's only $120 (or free), so you can expect things to break. It > is fine to say that your time or budget does not extend to a development > process that can eliminate all bugs - very little software can be > written in a way that provably has no errors, and generally you can only > do the best that resources allow to reduce the risk and consequences of > errors. > > But when you /know/ you have a bug, it's a different matter. The simple > act of documenting it clearer reduces the users' risk and consequences > by orders of magnitude. > > > For software, the biggest unknown factor is use and re-use. Bad bools > are very unlikely to have major consequences if Bart uses Pico-C to > script compilation of his code. But if the project gets forked and > re-used, and embedded in other software, and eventually it ends up as > part of a sandbox system for emulating or interpreting security > software, it could be a completely different matter. The Pico C > author's careless attitude, combined with the "it will be fine" > thoughtlessness of people like you along the way, can result in big > problems even though at each step it all looks like a very minor issue. > > Responsible programmers aim for correctness, for everything they code, > all the time. They don't aim to find their bugs in testing, they aim to > write code that they /know/ is correct, by design, and by knowledge of > the surrounding code, the language, the tools. Sometimes they make > mistakes. Sometimes there is an error outside their control, such as in > the specifications. Sometimes outside pressure - management, sales, > etc., - force them to leave code that they know is buggy or has high > risks of errors. But they are not happy about it, and they don't ignore > clear errors with "it will be fine". > > Now I know that you think Bart should just use make. But let's say it's agreed to proceed with the system I proposed, which is a C interpeter to drive a build script. Now I suggested modifying one of Bart's own compilers. But that's more difficult than I thought. So my second option is Pico C. Now I think that is achievable. If there's sufficient consensus that the system is worth producing, we can hook up Pico C and thrash out a support library, with the resources we have in this newsgroup, from people who are likely to want to contribute. Now if you think we shouldn't do that because of the danger of the scripting system being used in a critical environment and an error in the boolean or other component of Pico C propagating, then how do you think that we should proceed? -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
Page 6 of 26 — ← Prev page 1 … 4 5 [6] 7 8 … 26 Next page →
Back to top | Article view | comp.lang.c
csiph-web