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 5 of 26 — ← Prev page 1 … 3 4 [5] 6 7 … 26 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-11 20:12 -0800 |
| Message-ID | <87zfw68gng.fsf@nosuchdomain.example.com> |
| In reply to | #382362 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 11 Feb 2024 19:12:35 -0800, Keith Thompson wrote:
>
>> int main(void) {
>> _Bool b;
>> int i;
>> _Bool *ptr = &i;
>> // constraint violation because _Bool and int are not compatible
>> }
>>
>> Do you understand that int and _Bool are distinct and incompatible
>> types ...
>
> No more so than, say, int and short int.
Correct. int, short int, and _Bool are three distinct and incompatible
types.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-12 12:23 +0100 |
| Message-ID | <uqcv3o$1fikf$1@dont-email.me> |
| In reply to | #382362 |
On 12/02/2024 04:47, Lawrence D'Oliveiro wrote:
> On Sun, 11 Feb 2024 19:12:35 -0800, Keith Thompson wrote:
>
>> int main(void) {
>> _Bool b;
>> int i;
>> _Bool *ptr = &i;
>> // constraint violation because _Bool and int are not compatible
>> }
>>
>> Do you understand that int and _Bool are distinct and incompatible
>> types ...
>
> No more so than, say, int and short int.
These are indeed distinct and incompatible types. That applies even if
they happen to be the same size.
Do you know what "incompatible types" are, and what they mean? Do you
realise that they cannot be swapped around as you suggest?
As an example, look at the code generated for this with gcc for the
msp430 (a 16-bit target, where "int" and "short int" are the same size,
and where the assembly is simple enough to understand).
<https://godbolt.org/z/81cE5YThz>
int sizeof_short = sizeof(short int);
int sizeof_int = sizeof(int);
int foo1(int * p, short int * q) {
*p = 10;
*q += 1;
return *p;
}
int foo2(int * p, int * q) {
*p = 10;
*q += 1;
return *p;
}
foo1:
MOV.W #10, @R12
ADD.W #1, @R13
MOV.B #10, R12
RET
foo2:
MOV.W #10, @R12
ADD.W #1, @R13
MOV.W @R12, R12
RET
sizeof_int:
.short 2
sizeof_short:
.short 2
The compiler knows that in "foo1", "p" and "q" cannot point to the same
thing, because they are incompatible types. For "foo2", when swapping
"short int" for "int", the code is less efficient - it needs an extra
read from memory.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-14 21:44 +0000 |
| Message-ID | <uqjc8o$2r2ac$3@dont-email.me> |
| In reply to | #382371 |
On Mon, 12 Feb 2024 12:23:35 +0100, David Brown wrote: > Do you know what "incompatible types" are, and what they mean? Do you > realise that they cannot be swapped around as you suggest? And yet, all the examples posted so far have involved, not the actual types, but pointers to them.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-14 14:38 -0800 |
| Message-ID | <87sf1u8yeu.fsf@nosuchdomain.example.com> |
| In reply to | #382493 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 12 Feb 2024 12:23:35 +0100, David Brown wrote:
>> Do you know what "incompatible types" are, and what they mean? Do you
>> realise that they cannot be swapped around as you suggest?
>
> And yet, all the examples posted so far have involved, not the actual
> types, but pointers to them.
Because pointers to incompatible types are a good way to demonstrate
incompatibility.
Two types can be incompatible even if there are implicit conversions
between them. For example:
int i = 0;
long l = 0;
i = l;
l = i;
This is valid code that does not demonstrate the fact that int and long
are incompatible. But if two types foo and bar are incompatible, then
foo* and bar* are also incompatible *and there are no implicit
conversions between foo* and bar*. That's why the examples use
pointers.
int i = 0;
int *pi = &i;
long l = 0;
long *pl = &l;
i = l; // valid even though int and long are incompatible
pi = pl; // constraint violation because int and long are incompatible
Do you understand that int and long are incompatible even though they're
implicitly convertible, even if they happen to have the same size and
representation? Do you understand what "incompatible types" are? If
not, please consult the standard. If you're using C11 or N1570, start
with section 6.2.7, "Compatible type and composite type" (or the
equivalent subsection in another edition).
Finally, upthread in reponse to Ben's statement:
```
The type of c == d is int, but the value will be either 0 or 1.
```
you wrote:
```
That is the only kind of “boolean” C has.
```
Can you explain exactly what you meant by that? It could easily mean
that you think that int values of 0 and 1 are the only kind of boolean C
has, which is clearly incorrect.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-15 08:43 +0000 |
| Message-ID | <uqkir4$379pl$5@dont-email.me> |
| In reply to | #382499 |
On Wed, 14 Feb 2024 14:38:01 -0800, Keith Thompson wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> And yet, all the examples posted so far have involved, not the actual >> types, but pointers to them. > > Because pointers to incompatible types are a good way to demonstrate > incompatibility. But it was those types I was talking about, not pointers to them.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-15 15:55 +0000 |
| Message-ID | <87y1blk9id.fsf@bsb.me.uk> |
| In reply to | #382518 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > On Wed, 14 Feb 2024 14:38:01 -0800, Keith Thompson wrote: > >> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >> >>> And yet, all the examples posted so far have involved, not the actual >>> types, but pointers to them. >> >> Because pointers to incompatible types are a good way to demonstrate >> incompatibility. > > But it was those types I was talking about, not pointers to them. You seem to be arguing just for the sake it now since you pointedly refuse to answer Keith's question: "Do you understand that int and long are incompatible even though they're implicitly convertible, even if they happen to have the same size and representation?" -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-15 08:27 -0800 |
| Message-ID | <877cj58zhe.fsf@nosuchdomain.example.com> |
| In reply to | #382518 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 14 Feb 2024 14:38:01 -0800, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> And yet, all the examples posted so far have involved, not the actual
>>> types, but pointers to them.
>>
>> Because pointers to incompatible types are a good way to demonstrate
>> incompatibility.
>
> But it was those types I was talking about, not pointers to them.
I'll assume either that you understand type compatibility, or you don't
care.
If that's not the case and you have questions, feel free to ask.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-15 10:06 +0100 |
| Message-ID | <uqkk70$37m01$1@dont-email.me> |
| In reply to | #382493 |
On 14/02/2024 22:44, Lawrence D'Oliveiro wrote: > On Mon, 12 Feb 2024 12:23:35 +0100, David Brown wrote: > >> Do you know what "incompatible types" are, and what they mean? Do you >> realise that they cannot be swapped around as you suggest? > > And yet, all the examples posted so far have involved, not the actual > types, but pointers to them. Keith's post explains about pointers to incompatible types. Compatibility is also relevant for declarations. All declarations of the same function or object with external linkage must be the same within a program. It is undefined behaviour to have this : int foo(int); and this : int foo(long int); in the same program. That is true even if "int" and "long int" have the same size, or are passed using the same ABI conventions. Compilers will complain if they are within the same translation unit, but it is undefined (and usually not diagnosed) if they are in different translation units. There are /many/ situations where types must be compatible. I don't want to try to list all the rules here - you can look them up yourself.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-11 16:55 +0000 |
| Message-ID | <uqau5o$11nm8$1@dont-email.me> |
| In reply to | #382305 |
On 11/02/2024 02:00, Keith Thompson wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: >> On Sat, 10 Feb 2024 17:34:51 -0800, Keith Thompson wrote: >>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>> On Sun, 11 Feb 2024 01:08:51 +0000, Ben Bacarisse wrote: > [...] >>>>> The type of c == d is int, but the value will be either 0 or 1. >>>> >>>> That is the only kind of “boolean” C has. >>> >>> No it isn't. C99 added _Bool, which can be called bool if you include >>> <stdbool.h>. C23 (not yet released) will make bool a keyword, with >>> _Bool as an alternative spelling. >>> >>> But the equality and relational operators still yield results of type >>> int with value 0 or 1. >> >> All just new, different names for what I said: still the only kind of >> “boolean” C has. > > I can imagine that you're trying to express something that's correct, > but I honestly have no idea what it might be. > > C has a boolean type, called "_Bool" or "bool", added in C99. _Bool is > a distinct type, not the same as or compatible with any other type. > > Equality and relational operators yield results of type int, not _Bool. > > An expression of any scalar type (which includes integer, > floating-point, and pointer types) can be used as a condition. > > Assuming you agree with all that, I have no idea what you mean by "the > only kind of “boolean” C has". > Other lanaguages were designed with a "boolean" type which had special rules (bool + bool would either be disallowed or yield 1 if both were true), and was intended to be used wherever a value was logically either true or false. C didn't and used a int with just happened to be 1 or 0 for this purpose, and whilst booleans have now been added, the old system cannot be entirely eliminated and remains. You can achieve most of the benefits of a boolean type by aliasing "int' to "bool" and defining "true" and "false", and a lot of C installations do exactly this. -- 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-11 18:05 +0100 |
| Message-ID | <uqauo4$11vps$1@dont-email.me> |
| In reply to | #382335 |
On 11/02/2024 17:55, Malcolm McLean wrote: > On 11/02/2024 02:00, Keith Thompson wrote: >> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>> On Sat, 10 Feb 2024 17:34:51 -0800, Keith Thompson wrote: >>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>>> On Sun, 11 Feb 2024 01:08:51 +0000, Ben Bacarisse wrote: >> [...] >>>>>> The type of c == d is int, but the value will be either 0 or 1. >>>>> >>>>> That is the only kind of “boolean” C has. >>>> >>>> No it isn't. C99 added _Bool, which can be called bool if you include >>>> <stdbool.h>. C23 (not yet released) will make bool a keyword, with >>>> _Bool as an alternative spelling. >>>> >>>> But the equality and relational operators still yield results of type >>>> int with value 0 or 1. >>> >>> All just new, different names for what I said: still the only kind of >>> “boolean” C has. >> >> I can imagine that you're trying to express something that's correct, >> but I honestly have no idea what it might be. >> >> C has a boolean type, called "_Bool" or "bool", added in C99. _Bool is >> a distinct type, not the same as or compatible with any other type. >> >> Equality and relational operators yield results of type int, not _Bool. >> >> An expression of any scalar type (which includes integer, >> floating-point, and pointer types) can be used as a condition. >> >> Assuming you agree with all that, I have no idea what you mean by "the >> only kind of “boolean” C has". >> > Other lanaguages were designed with a "boolean" type which had special > rules (bool + bool would either be disallowed or yield 1 > if both were true), and was intended to be used wherever a value was > logically either true or false. C didn't and used a int with just > happened to be 1 or 0 for this purpose, and whilst booleans have now > been added, the old system cannot be entirely eliminated and remains. Yes, we all know that. (Well, everyone who has learned a bit of C99 knows that.) It's very difficult to change things in a language that has as much use as C - changing the type of the value of expressions like "x == y" would have been a breaking change. When C++ was forked from C, it was able to make such breaking changes - thus "x == y" gives a bool in C++. But for C, it was too late. > You can achieve most of the benefits of a boolean type by aliasing "int' > to "bool" and defining "true" and "false", and a lot of C installations > do exactly this. > No, you can't. That gives you the worst of all worlds. Use type "bool" when you want a boolean. It is /not/ the same as an int, or an enumerated type, or an unsigned char, or anything else that might be used as a "home-made boolean" - it has important additional characteristics. "Home-made boolean" types might be considered useful in C90, but not in C99. Recommending them now is bad advice, and recommending that you do so using the names "bool", "true" and "false" which conflict with C's real boolean type is extraordinarily silly.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-11 18:00 +0000 |
| Message-ID | <uqb1vc$12k3v$1@dont-email.me> |
| In reply to | #382336 |
On 11/02/2024 17:05, David Brown wrote: > On 11/02/2024 17:55, Malcolm McLean wrote: >> On 11/02/2024 02:00, Keith Thompson wrote: >>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>> On Sat, 10 Feb 2024 17:34:51 -0800, Keith Thompson wrote: >>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>>>> On Sun, 11 Feb 2024 01:08:51 +0000, Ben Bacarisse wrote: >>> [...] >>>>>>> The type of c == d is int, but the value will be either 0 or 1. >>>>>> >>>>>> That is the only kind of “boolean” C has. >>>>> >>>>> No it isn't. C99 added _Bool, which can be called bool if you include >>>>> <stdbool.h>. C23 (not yet released) will make bool a keyword, with >>>>> _Bool as an alternative spelling. >>>>> >>>>> But the equality and relational operators still yield results of type >>>>> int with value 0 or 1. >>>> >>>> All just new, different names for what I said: still the only kind of >>>> “boolean” C has. >>> >>> I can imagine that you're trying to express something that's correct, >>> but I honestly have no idea what it might be. >>> >>> C has a boolean type, called "_Bool" or "bool", added in C99. _Bool is >>> a distinct type, not the same as or compatible with any other type. >>> >>> Equality and relational operators yield results of type int, not _Bool. >>> >>> An expression of any scalar type (which includes integer, >>> floating-point, and pointer types) can be used as a condition. >>> >>> Assuming you agree with all that, I have no idea what you mean by "the >>> only kind of “boolean” C has". >>> >> Other lanaguages were designed with a "boolean" type which had special >> rules (bool + bool would either be disallowed or yield 1 >> if both were true), and was intended to be used wherever a value was >> logically either true or false. C didn't and used a int with just >> happened to be 1 or 0 for this purpose, and whilst booleans have now >> been added, the old system cannot be entirely eliminated and remains. > > Yes, we all know that. (Well, everyone who has learned a bit of C99 > knows that.) It's very difficult to change things in a language that > has as much use as C - changing the type of the value of expressions > like "x == y" would have been a breaking change. When C++ was forked > from C, it was able to make such breaking changes - thus "x == y" gives > a bool in C++. But for C, it was too late. > So in fact it should be pretty obvious what LDO is getting at. >> You can achieve most of the benefits of a boolean type by aliasing >> "int' to "bool" and defining "true" and "false", and a lot of C >> installations do exactly this. >> > > No, you can't. That gives you the worst of all worlds. > > Use type "bool" when you want a boolean. It is /not/ the same as an > int, or an enumerated type, or an unsigned char, or anything else that > might be used as a "home-made boolean" - it has important additional > characteristics. "Home-made boolean" types might be considered useful > in C90, but not in C99. Recommending them now is bad advice, and > recommending that you do so using the names "bool", "true" and "false" > which conflict with C's real boolean type is extraordinarily silly. > I used to say "bool breaks libraries" and this is exactly the problem. A simple typedef bool "bool" to "int" and definiing "true" and "false" creates problems because there are no namespaces, you export the symbols, and either they clash or they create mismash of subtly different Boolean types. So I am not recommending it in user code. However I am saying that it does achieve most of the benefits of having a boolean type, and therefore people who do this are not entirely stupid. But I'm talking about the C installation, so normally the person who provides the compiler, not the user code. -- 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-12 12:40 +0100 |
| Message-ID | <uqd039$1fnp7$1@dont-email.me> |
| In reply to | #382338 |
On 11/02/2024 19:00, Malcolm McLean wrote:
> On 11/02/2024 17:05, David Brown wrote:
>> On 11/02/2024 17:55, Malcolm McLean wrote:
>>> On 11/02/2024 02:00, Keith Thompson wrote:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>> On Sat, 10 Feb 2024 17:34:51 -0800, Keith Thompson wrote:
>>>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>>>> On Sun, 11 Feb 2024 01:08:51 +0000, Ben Bacarisse wrote:
>>>> [...]
>>>>>>>> The type of c == d is int, but the value will be either 0 or 1.
>>>>>>>
>>>>>>> That is the only kind of “boolean” C has.
>>>>>>
>>>>>> No it isn't. C99 added _Bool, which can be called bool if you
>>>>>> include
>>>>>> <stdbool.h>. C23 (not yet released) will make bool a keyword, with
>>>>>> _Bool as an alternative spelling.
>>>>>>
>>>>>> But the equality and relational operators still yield results of type
>>>>>> int with value 0 or 1.
>>>>>
>>>>> All just new, different names for what I said: still the only kind of
>>>>> “boolean” C has.
>>>>
>>>> I can imagine that you're trying to express something that's correct,
>>>> but I honestly have no idea what it might be.
>>>>
>>>> C has a boolean type, called "_Bool" or "bool", added in C99. _Bool is
>>>> a distinct type, not the same as or compatible with any other type.
>>>>
>>>> Equality and relational operators yield results of type int, not _Bool.
>>>>
>>>> An expression of any scalar type (which includes integer,
>>>> floating-point, and pointer types) can be used as a condition.
>>>>
>>>> Assuming you agree with all that, I have no idea what you mean by "the
>>>> only kind of “boolean” C has".
>>>>
>>> Other lanaguages were designed with a "boolean" type which had
>>> special rules (bool + bool would either be disallowed or yield 1
>>> if both were true), and was intended to be used wherever a value
>>> was logically either true or false. C didn't and used a int with just
>>> happened to be 1 or 0 for this purpose, and whilst booleans have now
>>> been added, the old system cannot be entirely eliminated and remains.
>>
>> Yes, we all know that. (Well, everyone who has learned a bit of C99
>> knows that.) It's very difficult to change things in a language that
>> has as much use as C - changing the type of the value of expressions
>> like "x == y" would have been a breaking change. When C++ was forked
>> from C, it was able to make such breaking changes - thus "x == y"
>> gives a bool in C++. But for C, it was too late.
>>
> So in fact it should be pretty obvious what LDO is getting at.
I agree - it is fairly obvious what he means. It is equally obvious
that he is wrong.
>
>>> You can achieve most of the benefits of a boolean type by aliasing
>>> "int' to "bool" and defining "true" and "false", and a lot of C
>>> installations do exactly this.
>>>
>>
>> No, you can't. That gives you the worst of all worlds.
>>
>> Use type "bool" when you want a boolean. It is /not/ the same as an
>> int, or an enumerated type, or an unsigned char, or anything else that
>> might be used as a "home-made boolean" - it has important additional
>> characteristics. "Home-made boolean" types might be considered useful
>> in C90, but not in C99. Recommending them now is bad advice, and
>> recommending that you do so using the names "bool", "true" and "false"
>> which conflict with C's real boolean type is extraordinarily silly.
>>
> I used to say "bool breaks libraries" and this is exactly the problem.
That is why C99 calls the type "_Bool", and you need to include
<stdbool.h> to get the nicer name "bool". Now with C23, the C standards
committee feel confident that the proportion of code that used "bool"
for their own types is small enough that it is safe to make "bool",
"true" and "false" keywords.
And it is why it is insane to suggest that it is a good idea to make
your own pseudo-boolean type in C and call it "bool". It was a
questionable idea in the late nineties when C99 was known to be coming
soon, a bad idea in the early naughties when it had been published and
compiler support was gaining, and is certainly not an acceptable idea now.
> A
> simple typedef bool "bool" to "int" and definiing "true" and "false"
> creates problems because there are no namespaces, you export the
> symbols, and either they clash or they create mismash of subtly
> different Boolean types.
Correct.
> So I am not recommending it in user code.
Then what were you doing when you wrote this?
"""
You can achieve most of the benefits of a boolean type by aliasing
"int' to "bool" and defining "true" and "false", and a lot of C
installations do exactly this.
"""
> However I am saying that it does achieve most of the benefits of having
> a boolean type, and therefore people who do this are not entirely
> stupid. But I'm talking about the C installation, so normally the person
> who provides the compiler, not the user code.
>
And what is a "C installation" ? Do you mean a "C /implementation/" ?
Do you mean your own modification to headers or libraries after you have
installed a toolchain? Do you mean a company's standard additional
libraries?
Or do you mean that C implementations simply put "typedef int bool;" as
their <stdbool.h> implementation? That would, of course, be utter nonsense.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-12 20:27 +0000 |
| Message-ID | <uqduum$1mm6v$1@dont-email.me> |
| In reply to | #382374 |
On 12/02/2024 11:40, David Brown wrote: > On 11/02/2024 19:00, Malcolm McLean wrote: >> > That is why C99 calls the type "_Bool", and you need to include > <stdbool.h> to get the nicer name "bool". Now with C23, the C standards > committee feel confident that the proportion of code that used "bool" > for their own types is small enough that it is safe to make "bool", > "true" and "false" keywords. > > And it is why it is insane to suggest that it is a good idea to make > your own pseudo-boolean type in C and call it "bool". It was a > questionable idea in the late nineties when C99 was known to be coming > soon, a bad idea in the early naughties when it had been published and > compiler support was gaining, and is certainly not an acceptable idea now. > >> A simple typedef bool "bool" to "int" and definiing "true" and "false" >> creates problems because there are no namespaces, you export the >> symbols, and either they clash or they create mismash of subtly >> different Boolean types. > > Correct. > >> So I am not recommending it in user code. > > Then what were you doing when you wrote this? > > """ > You can achieve most of the benefits of a boolean type by aliasing > "int' to "bool" and defining "true" and "false", and a lot of C > installations do exactly this. > """ > >> However I am saying that it does achieve most of the benefits of >> having a boolean type, and therefore people who do this are not >> entirely stupid. But I'm talking about the C installation, so normally >> the person who provides the compiler, not the user code. >> > > And what is a "C installation" ? Do you mean a "C /implementation/" ? > Do you mean your own modification to headers or libraries after you have > installed a toolchain? Do you mean a company's standard additional > libraries? > > Or do you mean that C implementations simply put "typedef int bool;" as > their <stdbool.h> implementation? That would, of course, be utter > nonsense. > > The "C installation " is not a rigorously defined concept and can be thought of as a fuzzy set. But basically it means someone who provides both the compiler and a library which must be used on that platform, and therefore has a similar status to the standard library, but just for that platform. So for example Mircrosoft provide a file called "windef.h" which contains the following declarations. typedef int BOOL; #ifndef FALSE #define FALSE 0 #endif #ifndef TRUE #define TRUE 1 #endif They use upper case. But otherwise it's exactly as I stated. In my view this is reasonable. But it wouldn't be reasonable in a libarary designed to do fast Fiurier transforms, for example. It's reasonable because windef.h is part of the "C installation". -- 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 09:07 +0100 |
| Message-ID | <uqf801$20hb9$1@dont-email.me> |
| In reply to | #382383 |
On 12/02/2024 21:27, Malcolm McLean wrote: > On 12/02/2024 11:40, David Brown wrote: >> On 11/02/2024 19:00, Malcolm McLean wrote: >>> >> That is why C99 calls the type "_Bool", and you need to include >> <stdbool.h> to get the nicer name "bool". Now with C23, the C >> standards committee feel confident that the proportion of code that >> used "bool" for their own types is small enough that it is safe to >> make "bool", "true" and "false" keywords. >> >> And it is why it is insane to suggest that it is a good idea to make >> your own pseudo-boolean type in C and call it "bool". It was a >> questionable idea in the late nineties when C99 was known to be coming >> soon, a bad idea in the early naughties when it had been published and >> compiler support was gaining, and is certainly not an acceptable idea >> now. >> >>> A simple typedef bool "bool" to "int" and definiing "true" and >>> "false" creates problems because there are no namespaces, you export >>> the symbols, and either they clash or they create mismash of subtly >>> different Boolean types. >> >> Correct. >> >>> So I am not recommending it in user code. >> >> Then what were you doing when you wrote this? >> >> """ >> You can achieve most of the benefits of a boolean type by aliasing >> "int' to "bool" and defining "true" and "false", and a lot of C >> installations do exactly this. >> """ >> >>> However I am saying that it does achieve most of the benefits of >>> having a boolean type, and therefore people who do this are not >>> entirely stupid. But I'm talking about the C installation, so >>> normally the person who provides the compiler, not the user code. >>> >> >> And what is a "C installation" ? Do you mean a "C /implementation/" ? >> Do you mean your own modification to headers or libraries after you >> have installed a toolchain? Do you mean a company's standard >> additional libraries? >> >> Or do you mean that C implementations simply put "typedef int bool;" >> as their <stdbool.h> implementation? That would, of course, be utter >> nonsense. >> >> > The "C installation " is not a rigorously defined concept and can be > thought of as a fuzzy set. But basically it means someone who provides > both the compiler and a library which must be used on that platform, and > therefore has a similar status to the standard library, but just for > that platform. That would be the "C implementation", and it /is/ a well-established term. It would be helpful if you used the standard terms here. > So for example Mircrosoft provide a file called "windef.h" which > contains the following declarations. > > typedef int BOOL; > > #ifndef FALSE > #define FALSE 0 > #endif > > #ifndef TRUE > #define TRUE 1 > #endif > None of that defines "bool", "true" or "false". This is /very/ different. It is a typical pre-C99 pseudo-boolean, and made sense before C99. The "windef.h" file needs to keep these for compatibility, especially in light of MS's notoriously poor and late C99 support, but no one should consider using them for anything now except as required for compatibility with external code that has them. (For example, if you are calling a function that takes a "BOOL *" pointer, you can't replace that with a "bool *" pointer.) > They use upper case. But otherwise it's exactly as I stated. And the upper case makes all the difference. As far as C is concerned, and as far as any trained C programmer is concerned, the difference is perfectly clear. Windows has a convention in its API and windef.h and windows.h headers of using all-caps names for locally defined type names that are specific and consistent for all Windows versions, and don't change according to the processor type - things like BYTE and LONG have existed from 16-bit Windows, through 32-bit and 64-bit Windows. They are not easily mistaken for the C standard types. > In my view > this is reasonable. But it wouldn't be reasonable in a libarary designed > to do fast Fiurier transforms, for example. It's reasonable because > windef.h is part of the "C installation". > I agree that this was a reasonable practice from MS, prior to C99. I wish they had moved over to C99 types like "bool" and the sized integer types (int32_t, etc.) as soon as these were standardised, keeping the old all-caps types only for compatibility with old code, and deprecating them as soon as reasonably possible. But prior to C99 they couldn't really have done much better. And I agree that a major C implementation, and the nearest Windows has to standard platform headers, can reasonably claim generic names like BOOL. It is normal for C90 libraries to have their own types for things like booleans, but they should be named with prefixes like the rest of the library - so you might have "fft_Boolean". Of course, anything this century should be in at least C99 and use standard types, but this kind of thing still hangs around because some code stretches back to last century. But these types are /not/ a substitute for standard C bool. They don't do the same thing. They are not as good. They are not as standard. They were the best be had a generation ago, but there is no reason to use them now except for interfacing with old code, and certainly no reason to consider defining a new home-made boolean.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-13 09:35 +0000 |
| Message-ID | <uqfd4d$21bu6$1@dont-email.me> |
| In reply to | #382389 |
On 13/02/2024 08:07, David Brown wrote: > On 12/02/2024 21:27, Malcolm McLean wrote: >> >> The "C installation " is not a rigorously defined concept and can be >> thought of as a fuzzy set. But basically it means someone who provides >> both the compiler and a library which must be used on that platform, >> and therefore has a similar status to the standard library, but just >> for that platform. > > That would be the "C implementation", and it /is/ a well-established > term. It would be helpful if you used the standard terms here. > The "C implentation" would be be the program created by the person who writes the complier. The "C installation" the system set up by the person who provides the compiler. 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. >> So for example Mircrosoft provide a file called "windef.h" which >> contains the following declarations. >> >> typedef int BOOL; >> >> #ifndef FALSE >> #define FALSE 0 >> #endif >> >> #ifndef TRUE >> #define TRUE 1 >> #endif >> > > None of that defines "bool", "true" or "false". This is /very/ different. > > It is a typical pre-C99 pseudo-boolean, and made sense before C99. The > "windef.h" file needs to keep these for compatibility, especially in > light of MS's notoriously poor and late C99 support, but no one should > consider using them for anything now except as required for > compatibility with external code that has them. (For example, if you > are calling a function that takes a "BOOL *" pointer, you can't replace > that with a "bool *" pointer.) > >> They use upper case. But otherwise it's exactly as I stated. > > And the upper case makes all the difference. As far as C is concerned, > and as far as any trained C programmer is concerned, the difference is > perfectly clear. Windows has a convention in its API and windef.h and > windows.h headers of using all-caps names for locally defined type names > that are specific and consistent for all Windows versions, and don't > change according to the processor type - things like BYTE and LONG have > existed from 16-bit Windows, through 32-bit and 64-bit Windows. They > are not easily mistaken for the C standard types. > >> In my view this is reasonable. But it wouldn't be reasonable in a >> libarary designed to do fast Fiurier transforms, for example. It's >> reasonable because windef.h is part of the "C installation". >> > > I agree that this was a reasonable practice from MS, prior to C99. I > wish they had moved over to C99 types like "bool" and the sized integer > types (int32_t, etc.) as soon as these were standardised, keeping the > old all-caps types only for compatibility with old code, and deprecating > them as soon as reasonably possible. But prior to C99 they couldn't > really have done much better. And I agree that a major C > implementation, and the nearest Windows has to standard platform > headers, can reasonably claim generic names like BOOL. > > It is normal for C90 libraries to have their own types for things like > booleans, but they should be named with prefixes like the rest of the > library - so you might have "fft_Boolean". Of course, anything this > century should be in at least C99 and use standard types, but this kind > of thing still hangs around because some code stretches back to last > century. > Yes, and it's a nightmare, because whilst it's obvious that an fft_boolean is a variable which is meant to represent "true" or "false", it's not so obvious where code which calls but does not implement the Fourier transforms should use it, and it might not even be binary compatible with other types in the program designed to do the same thing. A standrd atype is blessing, and all you really need for that is a simple standard header declaring "bool" as a type, and "true" and "false" as constants. Now "false" must be zero, But should "true" be 1 or -1? > > But these types are /not/ a substitute for standard C bool. They don't > do the same thing. They are not as good. They are not as standard. > They were the best be had a generation ago, but there is no reason to > use them now except for interfacing with old code, and certainly no > reason to consider defining a new home-made boolean. > I discussed using Pico C to implement a build system recently. Now I have't checked, but it's not fully featured and I don't think it supports coercing a boolean to be 1 or 0. But by providing a trivial header we could get most C source which uses "bool" to interpret correctly. And that would be a lot easier than trying to modify the interpeter. Of course char *ptr = something(); bool flag = (bool) ptr; if (flag == true) will not be interpreted correctly. But we can live with that. The Pico C would be our "C installation" by the way. We wouldn't claim to be the implenters. Not every word has to have been used before in exactly the same context to be used correctly, as you seem to think. (Now let's start a flame war because I did English at Oxford whilst you didn't). -- 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 11:36 +0100 |
| Message-ID | <uqfgnv$21tva$1@dont-email.me> |
| In reply to | #382391 |
On 13/02/2024 10:35, Malcolm McLean wrote: > On 13/02/2024 08:07, David Brown wrote: >> On 12/02/2024 21:27, Malcolm McLean wrote: >>> >>> The "C installation " is not a rigorously defined concept and can be >>> thought of as a fuzzy set. But basically it means someone who >>> provides both the compiler and a library which must be used on that >>> platform, and therefore has a similar status to the standard library, >>> but just for that platform. >> >> That would be the "C implementation", and it /is/ a well-established >> term. It would be helpful if you used the standard terms here. >> > > 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", which typically includes the non-compiler parts of the C implementation (like an assembler, linker, and standard library), as well as additional useful tools such as objcopy, make, a debugger, and perhaps an editor or IDE, and common platform-specific headers and libraries. MSVC is a toolchain, and comes with windef.h (amongst many other things). You might also refer to TDM as a Windows-hosted gcc toolchain. But you might also be talking about a customised setup, either done by an individual on their own systems, or by a company wanting all their developers to have the same development environment. > 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 for example Mircrosoft provide a file called "windef.h" which >>> contains the following declarations. >>> >>> typedef int BOOL; >>> >>> #ifndef FALSE >>> #define FALSE 0 >>> #endif >>> >>> #ifndef TRUE >>> #define TRUE 1 >>> #endif >>> >> >> None of that defines "bool", "true" or "false". This is /very/ >> different. >> >> It is a typical pre-C99 pseudo-boolean, and made sense before C99. >> The "windef.h" file needs to keep these for compatibility, especially >> in light of MS's notoriously poor and late C99 support, but no one >> should consider using them for anything now except as required for >> compatibility with external code that has them. (For example, if you >> are calling a function that takes a "BOOL *" pointer, you can't >> replace that with a "bool *" pointer.) >> >>> They use upper case. But otherwise it's exactly as I stated. >> >> And the upper case makes all the difference. As far as C is >> concerned, and as far as any trained C programmer is concerned, the >> difference is perfectly clear. Windows has a convention in its API >> and windef.h and windows.h headers of using all-caps names for locally >> defined type names that are specific and consistent for all Windows >> versions, and don't change according to the processor type - things >> like BYTE and LONG have existed from 16-bit Windows, through 32-bit >> and 64-bit Windows. They are not easily mistaken for the C standard >> types. >> >>> In my view this is reasonable. But it wouldn't be reasonable in a >>> libarary designed to do fast Fiurier transforms, for example. It's >>> reasonable because windef.h is part of the "C installation". >>> >> >> I agree that this was a reasonable practice from MS, prior to C99. I >> wish they had moved over to C99 types like "bool" and the sized >> integer types (int32_t, etc.) as soon as these were standardised, >> keeping the old all-caps types only for compatibility with old code, >> and deprecating them as soon as reasonably possible. But prior to C99 >> they couldn't really have done much better. And I agree that a major >> C implementation, and the nearest Windows has to standard platform >> headers, can reasonably claim generic names like BOOL. >> >> It is normal for C90 libraries to have their own types for things like >> booleans, but they should be named with prefixes like the rest of the >> library - so you might have "fft_Boolean". Of course, anything this >> century should be in at least C99 and use standard types, but this >> kind of thing still hangs around because some code stretches back to >> last century. >> > Yes, and it's a nightmare, because whilst it's obvious that an > fft_boolean is a variable which is meant to represent "true" or "false", > it's not so obvious where code which calls but does not implement the > Fourier transforms should use it, and it might not even be binary > compatible with other types in the program designed to do the same > thing. A standrd atype is blessing, and all you really need for that is > a simple standard header declaring "bool" as a type, and "true" and > "false" as constants. Now "false" must be zero, But should "true" be 1 > or -1? Have you been living under a rock for the last 25 years? Do you write code for the OCCC, or are you aiming for a "featured article" in the Daily WTF? <https://thedailywtf.com/articles/what_is_truth_0x3f_> <https://thedailywtf.com/articles/Extra-Boolean> 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". > > >> But these types are /not/ a substitute for standard C bool. They >> don't do the same thing. They are not as good. They are not as >> standard. They were the best be had a generation ago, but there is no >> reason to use them now except for interfacing with old code, and >> certainly no reason to consider defining a new home-made boolean. >> > I discussed using Pico C to implement a build system recently. Now I > have't checked, but it's not fully featured and I don't think it > supports coercing a boolean to be 1 or 0. But by providing a trivial > header we could get most C source which uses "bool" to interpret > correctly. And that would be a lot easier than trying to modify the > interpeter. Of course > > char *ptr = something(); > bool flag = (bool) ptr; > if (flag == true) > > 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. 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". > We wouldn't claim > to be the implenters. Not every word has to have been used before in > exactly the same context to be used correctly, as you seem to think. > Do you have any reason or purpose behind your deliberate and continuous misuse of terms and your insistence on making up your own language? I can appreciate that you are often ignorant about the C language, the C standards, and the terms used there. Ignorance is not a problem - it's easily cured by someone giving you the missing knowledge or correcting mistakes. This is part of what we do in this group - helping each other understand more about C. But when you have been told the correct terms, please use them. > (Now let's start a flame war because I did English at Oxford whilst you > didn't). Let's not.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-13 12:12 +0000 |
| Message-ID | <uqfmao$22v44$1@dont-email.me> |
| In reply to | #382392 |
On 13/02/2024 10:36, David Brown wrote: > On 13/02/2024 10:35, Malcolm McLean wrote: >> > 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. > Its' quite simple. Basically in my view you have no business declaring and exporting a boolean type if you are an ordinary library writer. Only if you set things up. Only if you are Microsoft or Nintendo or someone else who legitimately may claim to have the right to dictate what should and should not be on that platform. Which normally means that you will alos be the person who writes the compiler and therefore the "implementor". But not necessarily, so "implentation" ins;t quite th right word and we need anew one. I don't think there is a generally accepted term for this idea, as is often the case for unexceptional and rutine ideas which neverthelss don;t come up very often. So I chose "installation", a perfectly normal word which in slang means "the set up". Now this sort of thing irritates some of the others, and so I shouldn't have to explain and justify to some people the basics of how to use the English language. > Maybe you are talking about what others might refer to as a "toolchain", > which typically includes the non-compiler parts of the C implementation > (like an assembler, linker, and standard library), as well as additional > useful tools such as objcopy, make, a debugger, and perhaps an editor or > IDE, and common platform-specific headers and libraries. MSVC is a > toolchain, and comes with windef.h (amongst many other things). You > might also refer to TDM as a Windows-hosted gcc toolchain. > > But you might also be talking about a customised setup, either done by > an individual on their own systems, or by a company wanting all their > developers to have the same development environment. > Yes, can be the second. Embedded developers talk about "toolchains" but non-embedded developers mostly don't, and it's not really relevant that in a typical C implemntation several programs are run to create the exectuable instead of only one. But it is relevant that all the developers have the same development environment. If everyone shall use "BOOL" rather than "bool" because that is the customised common header chosen by the company, that's exactly what I am talking about. > >> Yes, and it's a nightmare, because whilst it's obvious that an >> fft_boolean is a variable which is meant to represent "true" or >> "false", it's not so obvious where code which calls but does not >> implement the Fourier transforms should use it, and it might not even >> be binary compatible with other types in the program designed to do >> the same thing. A standrd atype is blessing, and all you really need >> for that is a simple standard header declaring "bool" as a type, and >> "true" and "false" as constants. Now "false" must be zero, But should >> "true" be 1 or -1? > > Have you been living under a rock for the last 25 years? Do you write > code for the OCCC, or are you aiming for a "featured article" in the > Daily WTF? > > <https://thedailywtf.com/articles/what_is_truth_0x3f_> > <https://thedailywtf.com/articles/Extra-Boolean> > "Have you stopped beating your wife?" True / false often isn't adequate. And fuzzy logic is an attempt to address this sort of issue. Another way would be to add extra categories, like "unknown", "halfway between", or, in this case "unfair". > 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". > true can be -1 in boolean logic. The real reason is that -1 is all bits set, so ~true == false. But of course a one bit number is either -1 or 0 in two;s complement notation. However someone has to take decsion on this and there should be one standard, I totally agree. > > 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. > But as it is a dead project there is little point in reporting the error. > There aren't that many open source, free to use C intepreters hanging around. I did try to use Pico C for a hobby project that never got to release, and one of the reasons I abandoned it was that Pico C was difficult to use. But I did get C functions entered and running. If "bool" is available then it makes programs a bit easier to read and there is a slight benefit, but it's only slight, and you can write C programs perfectly well without it. The problem comes when people who have no business doing so declare a boolean type. If Pico C calls its boolean header stdbool.h and it is subtly different from how stdbool.h is supposed to work then it could be dangerous, I agree, but it's unlikely anyone would connect my hobby project up to a nuclear missile. -- 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 14:15 +0100 |
| Message-ID | <uqfq1a$23jkn$1@dont-email.me> |
| In reply to | #382393 |
On 13/02/2024 13:12, Malcolm McLean wrote: > On 13/02/2024 10:36, David Brown wrote: >> On 13/02/2024 10:35, Malcolm McLean wrote: >>> >> 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. >> > Now this sort of thing irritates some of the others, and so I shouldn't > have to explain and justify to some people the basics of how to use the > English language. The way to avoid this would be to use standard terms correctly in the first place. And if what you intend to say is not covered by the standard term, explain what you mean - don't just leap in with yet another home-made term and expect everyone else to read your mind. >> >> But you might also be talking about a customised setup, either done by >> an individual on their own systems, or by a company wanting all their >> developers to have the same development environment. >> > Yes, can be the second. Embedded developers talk about "toolchains" but > non-embedded developers mostly don't, and it's not really relevant that > in a typical C implemntation several programs are run to create the > exectuable instead of only one. But it is relevant that all the > developers have the same development environment. If everyone shall use > "BOOL" rather than "bool" because that is the customised common header > chosen by the company, that's exactly what I am talking about. Finally we are getting somewhere. >> >>> Yes, and it's a nightmare, because whilst it's obvious that an >>> fft_boolean is a variable which is meant to represent "true" or >>> "false", it's not so obvious where code which calls but does not >>> implement the Fourier transforms should use it, and it might not even >>> be binary compatible with other types in the program designed to do >>> the same thing. A standrd atype is blessing, and all you really need >>> for that is a simple standard header declaring "bool" as a type, and >>> "true" and "false" as constants. Now "false" must be zero, But should >>> "true" be 1 or -1? >> >> Have you been living under a rock for the last 25 years? Do you write >> code for the OCCC, or are you aiming for a "featured article" in the >> Daily WTF? >> >> <https://thedailywtf.com/articles/what_is_truth_0x3f_> >> <https://thedailywtf.com/articles/Extra-Boolean> >> > "Have you stopped beating your wife?" > True / false often isn't adequate. I did not expect a yes/no answer to these rhetorical questions, and did not in any way suggest that I was looking for one. I was ridiculing the idea of making more home-made booleans 25 years after they became unnecessary and outdated, and especially the idea of doing something as silly as making "true" have the value -1. > > >> 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". >> > true can be -1 in boolean logic. No, it cannot. Boolean logic has "true" and "false", sometimes donated 1 and 0 for convenience. As a logic system, these 1 and 0 representations bear no relation to the normal numbers 1 and 0 - they are just symbols. Programming language implementations always need to represent things as numbers in the end, since that is what computer hardware deals with. How the logical concepts of "true" and "false" are represented is arbitrary, though usually picked to be efficient to implement and helpful to programmers if the language supports conversion from boolean types to number types. Some languages use -1 for "true" in this sense, others treat all non-zero values as "true". It is most common, I believe, to see 1 as the canonical representation of "true". Some, however, will use 0 for "true" and 1 for "false", or 'T' for true and 'F' for false, or other values. The relevant language here is C. And C99 _Bool uses 1 for true. In all versions of C, the relational operators and logical operators yield 1 for true, and 0 for false. Picking a value for a constant called "true" such that "(true == true) != true" is considered "true" by the language would be insane. > The real reason is that -1 is all bits > set, so ~true == false. But of course a one bit number is either -1 or 0 > in two;s complement notation. > However someone has to take decsion on this and there should be one > standard, I totally agree. That decision was taken 50+ years ago when C was conceived. >> >> 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. But as it is a dead project there is little point >> in reporting the error. >> > There aren't that many open source, free to use C intepreters hanging > around. That does not make Pico C any less of a dead project, or mean that it handles anything other than a vaguely defined language based on a subset of some unspecified version of C with dangerous (or at least unhelpful) additions that differ pointlessly from standard C. It might still be a useful tool. Just don't treat it as anything it is not, and do not use it as some kind of justification for misunderstanding "bool" in C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-13 12:32 +0000 |
| Message-ID | <uqfngh$235bb$1@dont-email.me> |
| In reply to | #382392 |
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.
There might be have two or more installations.
My original C compiler had one of the simplest possible installations:
just run the EXE from wherever it happens to be. Yet even there, you
need to know /where/ it is installed, even if it's just to add that
location to a set of search paths.
Installing two gcc versions on Windows is problematical because gcc
invokes other binaries. Because rather than using paths relative to the
gcc.exe that was run, it uses system PATH settings, so that when it
invokes ld.exe for example, it may end up with ld.exe belonging to the
other installation.
This is little to do with implementation (other than the implementation
is buggy IMO).
>> 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?
> 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.
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?
(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.)
>> 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.
> 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.
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?
Some C compilers implement a subset of the language, some a superset. I
expect a superset is fine? But neither are actually C!
And of course, using compiler options to further customise the language
is also acceptable.
"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"?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-13 13:56 +0000 |
| Message-ID | <87wmr8lb7n.fsf@bsb.me.uk> |
| In reply to | #382394 |
bart <bc@freeuk.com> writes: > 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. And yet I don't think you have understood what Malcolm means. > 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. But that can be you or I, and Malcolm has at last explained that the key point (at least for him) is one of authority: the "installer" has the authority (or maybe just the commercial clout) to insist on "the installation" having a Boolean type, maybe even a non-standard one. The person who "sets things up" (the "installer" of the "installation") in Malcolm's world is Microsoft or Nintendo, not the person who typically installs software on a single user machine. It could (I am sure) be your employer, as they have the authority to insist you use some specific Boolean type, so it is certainly not the same as a "C implantation" in the sense used by the C standard. Comp.lang.c has become so polarised that I can see how you want to be "on Malcolm's side" here, but until just now he had not explained how he was using the vague term "C installation". It's fine to avoid jargon, but you do then have to explain what you mean, and it's still not 100% clear. Ironically, an authority, the WG14 committee, has indeed decreed that "C installations" should have a Boolean type spelled "bool" with "true" and "false" as keywords. It would have been so much simpler had he said, right off the bat, that some entities (Microsoft, the WG14 committee, your employer) have the clout to get away with insisting on a Boolean type, but library authors do not. We could disagree with that, but at least we'd all be on the same page to start with. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 26 — ← Prev page 1 … 3 4 [5] 6 7 … 26 Next page →
Back to top | Article view | comp.lang.c
csiph-web