Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90018 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2016-07-05 02:38 -0700 |
| Last post | 2016-11-27 10:05 -0800 |
| Articles | 20 on this page of 354 — 37 participants |
Back to article view | Back to comp.lang.c
double free G G <gdotone@gmail.com> - 2016-07-05 02:38 -0700
Re: double free Ian Collins <ian-news@hotmail.com> - 2016-07-05 21:45 +1200
Re: double free Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-05 07:08 -0400
Re: double free G G <gdotone@gmail.com> - 2016-07-05 16:41 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-05 10:50 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-05 11:06 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-05 19:07 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-05 12:16 +0000
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-05 13:57 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-05 08:43 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-05 14:57 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-10 18:49 +0000
Re: double free G G <gdotone@gmail.com> - 2016-07-05 17:03 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-05 17:25 -0700
Re: double free Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-07-06 19:09 +0000
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-06 15:22 -0400
Re: double free Nobody <nobody@nowhere.invalid> - 2016-07-09 06:13 +0100
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-09 10:16 -0400
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-09 08:58 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 13:28 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-11 10:41 +0000
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-09 20:27 +0200
Re: double free "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-07-09 11:31 -0700
Re: double free Gareth Owen <gwowen@gmail.com> - 2016-07-09 20:14 +0100
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 15:34 -0400
Re: double free jameskuyper@verizon.net - 2016-07-09 14:02 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 14:10 -0700
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-09 17:14 -0400
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 14:24 -0700
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-09 17:31 -0400
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-09 20:50 -0400
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-09 15:50 -0400
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-10 11:32 +0200
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-10 16:01 -0400
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-11 10:07 +0200
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-11 08:15 -0400
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 06:53 -0700
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-11 10:35 -0600
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 09:48 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 11:02 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 11:01 -0700
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-11 13:03 -0600
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 10:57 -0700
Re: double free albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-27 13:29 +0100
Re: double free Melzzzzz <mel@zzzzz.com> - 2016-11-27 14:07 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-10 13:05 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-10 05:31 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-10 13:42 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-11 01:07 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 13:39 -0700
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-10 11:53 +0200
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-10 04:11 -0700
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-10 08:47 -0400
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-10 16:05 -0400
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-09 17:43 -0600
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-09 17:32 -0700
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-09 20:34 -0600
Re: double free Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-07-10 06:25 +0000
Re: double free supercat@casperkitty.com - 2016-07-11 08:02 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-11 11:01 +0000
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 04:07 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 12:17 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 04:59 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 13:07 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 13:38 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 14:11 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 18:54 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 11:09 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 19:47 +0100
Re: double free Ike Naar <ike@iceland.freeshell.org> - 2016-07-11 19:08 +0000
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-11 21:19 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 21:34 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 13:48 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-11 22:49 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 23:20 +0100
Re: double free Udyant Wig <udyant.wig@gmail.com> - 2016-07-12 10:26 +0530
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-11 22:34 -0700
Re: double free Ike Naar <ike@iceland.freeshell.org> - 2016-07-12 06:39 +0000
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 00:41 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 08:57 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 01:16 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 09:27 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 11:48 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 08:46 +0100
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-12 10:42 +0200
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 09:59 +0100
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-12 12:46 +0200
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 09:08 -0700
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-12 18:51 +0200
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 11:28 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 19:53 +0100
Re: double free supercat@casperkitty.com - 2016-07-12 12:19 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 14:26 -0700
Re: double free Ken Brody <kenbrody@spamcop.net> - 2016-07-12 11:00 -0400
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 16:18 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 08:44 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 09:24 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 17:34 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 09:52 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 09:40 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-12 18:22 +0100
Re: double free Gareth Owen <gwowen@gmail.com> - 2016-07-13 18:33 +0100
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-13 14:00 -0400
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 19:16 +0100
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 09:15 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 09:04 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-18 11:10 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-20 08:52 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-20 09:36 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 18:23 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 08:42 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 11:24 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-12 11:52 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 13:18 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-12 16:42 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-12 17:21 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 09:35 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-12 18:08 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-12 18:14 +0100
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 10:01 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-18 18:20 +0100
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 09:26 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-21 18:57 +0100
Re: double free Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:41 +0530
Re: double free BartC <bc@freeuk.com> - 2016-07-22 19:47 +0100
Re: double free supercat@casperkitty.com - 2016-07-22 11:58 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-22 12:03 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-22 20:26 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-22 13:12 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 08:57 +0000
Re: double free BartC <bc@freeuk.com> - 2016-07-23 10:21 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-23 11:08 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-23 12:36 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 07:14 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-23 16:41 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:17 +0000
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-23 20:42 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-23 12:51 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-23 21:50 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-23 14:17 -0700
Re: double free luser droog <luser.droog@gmail.com> - 2016-07-23 15:53 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-23 20:55 -0700
Re: double free luser droog <luser.droog@gmail.com> - 2016-07-23 22:21 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-24 10:35 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-24 02:55 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 04:05 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-24 14:03 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-24 14:24 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-24 15:15 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-24 16:01 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 11:36 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-24 19:52 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 12:14 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 11:13 -0700
Re: double free Martin Shobe <mashobe9@gmail.com> - 2016-07-24 14:52 -0500
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:59 -0700
Re: double free Martin Shobe <mashobe9@gmail.com> - 2016-07-25 19:32 -0500
Re: double free supercat@casperkitty.com - 2016-07-25 07:39 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 10:55 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 08:30 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-23 11:11 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-23 12:39 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 20:25 +0000
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 12:51 -0700
Re: double free supercat@casperkitty.com - 2016-07-22 13:18 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 08:23 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-24 19:36 +0100
Re: double free albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-02 10:21 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 10:57 +0000
Re: double free BartC <bc@freeuk.com> - 2016-12-02 12:33 +0000
Re: double free David Brown <david.brown@hesbynett.no> - 2016-12-02 14:07 +0100
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 10:19 -0500
Re: double free Keith Thompson <kst-u@mib.org> - 2016-12-02 08:56 -0800
Re: double free "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 12:31 -0500
Re: double free Keith Thompson <kst-u@mib.org> - 2016-12-02 11:42 -0800
Re: double free supercat@casperkitty.com - 2016-07-12 08:46 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 09:16 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-12 09:27 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 08:20 -0700
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-12 12:47 -0400
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-12 22:21 +0000
Re: double free BartC <bc@freeuk.com> - 2016-07-12 23:27 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-12 16:28 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 00:23 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 08:43 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 11:21 +0100
Re: double free Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-13 12:56 +0200
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 12:35 +0100
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-13 10:34 -0400
Re: double free Cal Dershowitz <cal@example.invalid> - 2016-07-15 05:57 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-13 11:17 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 04:30 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 12:33 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 13:41 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 13:57 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 06:10 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 20:08 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 15:11 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 18:14 +0100
Re: double free Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-13 19:20 +0200
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 18:24 +0100
Re: double free Robert Wessel <robertwessel2@yahoo.com> - 2016-07-15 00:51 -0500
Re: double free luser droog <luser.droog@gmail.com> - 2016-07-15 02:18 -0700
Re: double free "Osmium" <r124c4u102@comcast.net> - 2016-07-15 07:12 -0500
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-15 13:14 +0100
Re: double free Rosario19 <Ros@invalid.invalid> - 2016-07-18 09:28 +0200
Re: double free BartC <bc@freeuk.com> - 2016-07-13 18:43 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 20:15 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 21:14 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 13:24 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-13 21:50 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:21 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 13:02 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 21:34 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 13:51 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-13 22:22 +0100
Re: double free Robert Wessel <robertwessel2@yahoo.com> - 2016-07-15 01:08 -0500
Re: double free Reinhardt Behm <rbehm@hushmail.com> - 2016-07-15 17:33 +0800
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-15 05:02 -0700
Re: double free Reinhardt Behm <rbehm@hushmail.com> - 2016-07-15 21:15 +0800
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 14:48 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-15 08:02 -0700
Re: double free Cal Dershowitz <cal@example.invalid> - 2016-07-18 01:42 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 03:07 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 22:01 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 22:14 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 14:31 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 23:03 +0100
Re: double free "Osmium" <r124c4u102@comcast.net> - 2016-07-13 17:53 -0500
Re: double free supercat@casperkitty.com - 2016-07-13 16:18 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-13 16:19 -0700
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-13 22:44 -0400
Re: double free Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-14 09:44 +0200
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 17:07 -0700
Re: double free supercat@casperkitty.com - 2016-07-14 07:13 -0700
Re: double free Robert Wessel <robertwessel2@yahoo.com> - 2016-07-15 01:18 -0500
Re: double free Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-13 10:46 -0400
Re: double free Robert Wessel <robertwessel2@yahoo.com> - 2016-07-15 00:59 -0500
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-14 23:47 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-15 11:22 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 11:35 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 14:33 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 15:16 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 16:19 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 08:39 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-15 16:54 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 21:20 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 16:45 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 17:15 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 17:42 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 21:18 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 21:06 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-15 21:46 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 23:08 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-16 01:26 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 18:22 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-15 18:48 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-15 18:40 -0700
Re: double free supercat@casperkitty.com - 2016-07-15 10:09 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 11:07 -0700
Re: double free supercat@casperkitty.com - 2016-07-15 12:11 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 12:30 -0700
Re: double free supercat@casperkitty.com - 2016-07-15 12:41 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-15 13:04 -0700
Re: double free supercat@casperkitty.com - 2016-07-15 14:26 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-19 10:00 -0700
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 12:46 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 13:19 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 13:30 +0100
Re: double free Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-13 20:53 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-13 21:37 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-13 05:22 -0700
Re: double free supercat@casperkitty.com - 2016-07-13 07:07 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-14 19:31 +0100
Re: double free supercat@casperkitty.com - 2016-07-14 12:10 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-14 23:16 +0100
Re: double free supercat@casperkitty.com - 2016-07-14 16:00 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-14 12:34 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-14 20:57 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-14 13:15 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-14 21:27 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-14 21:31 +0100
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 09:46 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-19 13:32 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 13:46 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 06:00 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 09:23 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 09:38 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-19 17:51 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 18:22 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:02 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 11:42 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 12:27 -0700
Re: double free Philip Lantz <prl@canterey.us> - 2016-07-21 10:02 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-21 10:25 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-21 18:27 +0100
Re: double free Cal Dershowitz <cal@example.invalid> - 2016-07-29 00:42 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 08:59 +0000
Re: double free BartC <bc@freeuk.com> - 2016-07-19 15:22 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 15:59 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-19 16:39 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 16:55 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-19 17:49 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 18:20 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-19 19:03 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-19 19:22 +0100
sizeof (was Re: double free) Ken Brody <kenbrody@spamcop.net> - 2016-07-19 14:44 -0400
Re: sizeof (was Re: double free) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 12:31 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-19 22:46 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 15:19 -0700
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 00:21 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:21 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 12:08 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-19 09:41 -0700
Re: double free Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 18:10 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-22 11:23 +0100
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 03:40 -0700
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-22 10:33 -0700
Re: double free Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 12:47 -0700
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-12 22:18 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 10:53 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-11 21:20 +0100
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 13:56 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-11 22:39 +0100
Re: double free David Brown <david.brown@hesbynett.no> - 2016-07-12 10:57 +0200
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 21:58 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 13:23 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-11 13:00 +0000
Re: double free Keith Thompson <kst-u@mib.org> - 2016-07-11 10:44 -0700
Re: double free Gareth Owen <gwowen@gmail.com> - 2016-07-11 19:10 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 20:22 +0100
Re: double free BartC <bc@freeuk.com> - 2016-07-11 21:11 +0100
Re: double free Gareth Owen <gwowen@gmail.com> - 2016-07-11 21:49 +0100
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 22:01 +0100
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-11 09:09 -0400
Re: double free Richard Heathfield <rjh@cpax.org.uk> - 2016-07-11 14:16 +0100
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-15 13:51 +0000
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-15 12:04 -0400
Re: double free Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-11 17:51 +0200
Re: double free raltbos@xs4all.nl (Richard Bos) - 2016-07-11 10:19 +0000
Re: double free Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-05 08:57 -0600
Re: double free James Kuyper <jameskuyper@verizon.net> - 2016-07-05 11:13 -0400
Re: double free supercat@casperkitty.com - 2016-07-05 09:05 -0700
Re: double free G G <gdotone@gmail.com> - 2016-07-05 16:38 -0700
Re: double free G G <gdotone@gmail.com> - 2016-07-05 16:34 -0700
Re: double free Nobody <nobody@nowhere.invalid> - 2016-07-06 04:10 +0100
Re: double free Siri Cruise <chine.bleu@yahoo.com> - 2016-07-05 21:27 -0700
Re: double free supercat@casperkitty.com - 2016-07-06 02:53 -0700
Re: double free Siri Cruise <chine.bleu@yahoo.com> - 2016-07-06 06:09 -0700
Re: double free supercat@casperkitty.com - 2016-07-06 07:53 -0700
Re: double free "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-07-06 01:25 -0700
Re: double free BartC <bc@freeuk.com> - 2016-07-06 11:12 +0100
Re: double free Thiago Adams <thiago.adams@gmail.com> - 2016-11-27 09:52 -0800
Re: double free supercat@casperkitty.com - 2016-11-27 10:05 -0800
Page 8 of 18 — ← Prev page 1 … 6 7 [8] 9 10 … 18 Next page →
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-07-23 15:53 -0700 |
| Message-ID | <4b97df6b-97ec-4ce8-a263-cbc75f84d335@googlegroups.com> |
| In reply to | #90880 |
On Saturday, July 23, 2016 at 4:17:18 PM UTC-5, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > > On 23/07/2016 20:51, Keith Thompson wrote: > [...] > >> I do not recall Tim saying that this implies one should not use > >> parentheses for clarity. Do you? > > > > He said (referring to knowing all binary op precedence levels): > > > > "I would. And do. And happy to do it. If you can't take > > the heat, stay out of the kitchen." > > > > So he knows exactly what every expression means, and suggests that only > > those who also know all the levels should be coding. So why would anyone > > need extra parentheses? Either something is already clear, or you > > shouldn't be programming. > > Was that intended to answer my question? I believe you are inferring > things he didn't say. > I know Tim will answer for himself in due time, but in the interest of time here's what I recall from when this came up a few months ago. This was close on the heels of a very comprehensive and insightful multi-review of my interpreter for a new APL-like language so I was in the mindset to absorb all available wisdom from his pen to a degree perhaps unique among the readers here. What he said (IIRC) was ditch the parens and use spaces. You should know (or being willing to learn) the relative precedences of the operators that you use in an expression. And you should use spaces to demonstrate what you (the programmer) intend. Much of my code runs afoul of this prescription. But I'm making efforts. For an example of this "style", you should write x = y*z + w; instead of x = (y*z)+w; or even x = (y * z) + w; The first version should match more nicely with the equations in your notebook. I don't venture a `sizeof` example because I haven't done my homework there, yet.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-23 20:55 -0700 |
| Message-ID | <lny44relli.fsf@kst-u.example.com> |
| In reply to | #90884 |
luser droog <luser.droog@gmail.com> writes:
> On Saturday, July 23, 2016 at 4:17:18 PM UTC-5, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> > On 23/07/2016 20:51, Keith Thompson wrote:
>> [...]
>> >> I do not recall Tim saying that this implies one should not use
>> >> parentheses for clarity. Do you?
>> >
>> > He said (referring to knowing all binary op precedence levels):
>> >
>> > "I would. And do. And happy to do it. If you can't take
>> > the heat, stay out of the kitchen."
>> >
>> > So he knows exactly what every expression means, and suggests that only
>> > those who also know all the levels should be coding. So why would anyone
>> > need extra parentheses? Either something is already clear, or you
>> > shouldn't be programming.
>>
>> Was that intended to answer my question? I believe you are inferring
>> things he didn't say.
>
> I know Tim will answer for himself in due time, but in the interest of
> time here's what I recall from when this came up a few months ago.
> This was close on the heels of a very comprehensive and insightful
> multi-review of my interpreter for a new APL-like language so I was
> in the mindset to absorb all available wisdom from his pen to a
> degree perhaps unique among the readers here.
>
> What he said (IIRC) was ditch the parens and use spaces. You should
> know (or being willing to learn) the relative precedences of the
> operators that you use in an expression. And you should use spaces
> to demonstrate what you (the programmer) intend.
>
> Much of my code runs afoul of this prescription. But I'm making efforts.
>
> For an example of this "style", you should write
>
> x = y*z + w;
>
> instead of
>
> x = (y*z)+w;
>
> or even
>
> x = (y * z) + w;
>
> The first version should match more nicely with the equations in your
> notebook.
Thank you, but I don't think that really answers the question I
was asking, or at least the one I meant to ask. The fact that "*"
binds more tightly than "+" is likely to be obvious even to someone
who's not familiar with C. I likely wouldn't use parentheses in
that case myself. I might not even bother with spacing:
x = y * z + w;
> I don't venture a `sizeof` example because I haven't done my homework
> there, yet.
A more relevant example might be:
x | y ^ z
That expression is entirely unambiguous as far as the C standard is
concerned. Tim would argue that a C programmer would know that it's
equivalent to
x | (y ^ z)
and in principle I agree, but I couldn't have written this if I
hadn't looked it up just now. (I even wrote a test program just
to be sure I don't screw up on operator precedence in a discussion
of operator precedence.)
(I *know* all the operator precedences. It just happens that I
keep some of that knowledge outside my head.)
I would certainly advocate using parentheses in that case.
BartC inferred that Tim would recommend *not* using parentheses.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-07-23 22:21 -0700 |
| Message-ID | <1fa8492e-12b5-4edd-a8a7-0eb3bd33daec@googlegroups.com> |
| In reply to | #90888 |
On Saturday, July 23, 2016 at 10:55:30 PM UTC-5, Keith Thompson wrote: > luser droog <luser.droog@gmail.com> writes: > > On Saturday, July 23, 2016 at 4:17:18 PM UTC-5, Keith Thompson wrote: > >> BartC <bc@freeuk.com> writes: > >> > On 23/07/2016 20:51, Keith Thompson wrote: > >> [...] > >> >> I do not recall Tim saying that this implies one should not use > >> >> parentheses for clarity. Do you? > >> > > >> > He said (referring to knowing all binary op precedence levels): > >> > > >> > "I would. And do. And happy to do it. If you can't take > >> > the heat, stay out of the kitchen." > >> > > >> > So he knows exactly what every expression means, and suggests that only > >> > those who also know all the levels should be coding. So why would anyone > >> > need extra parentheses? Either something is already clear, or you > >> > shouldn't be programming. > >> > >> Was that intended to answer my question? I believe you are inferring > >> things he didn't say. > > > > I know Tim will answer for himself in due time, but in the interest of > > time here's what I recall from when this came up a few months ago. > > This was close on the heels of a very comprehensive and insightful > > multi-review of my interpreter for a new APL-like language so I was > > in the mindset to absorb all available wisdom from his pen to a > > degree perhaps unique among the readers here. > > > > What he said (IIRC) was ditch the parens and use spaces. You should > > know (or being willing to learn) the relative precedences of the > > operators that you use in an expression. And you should use spaces > > to demonstrate what you (the programmer) intend. > > > > Much of my code runs afoul of this prescription. But I'm making efforts. > > > > For an example of this "style", you should write > > > > x = y*z + w; > > > > instead of > > > > x = (y*z)+w; > > > > or even > > > > x = (y * z) + w; > > > > The first version should match more nicely with the equations in your > > notebook. > > Thank you, but I don't think that really answers the question I > was asking, or at least the one I meant to ask. The fact that "*" > binds more tightly than "+" is likely to be obvious even to someone > who's not familiar with C. I likely wouldn't use parentheses in > that case myself. I might not even bother with spacing: > > x = y * z + w; > > > I don't venture a `sizeof` example because I haven't done my homework > > there, yet. > > A more relevant example might be: > x | y ^ z > That expression is entirely unambiguous as far as the C standard is > concerned. Tim would argue that a C programmer would know that it's > equivalent to > x | (y ^ z) > and in principle I agree, but I couldn't have written this if I > hadn't looked it up just now. (I even wrote a test program just > to be sure I don't screw up on operator precedence in a discussion > of operator precedence.) > > (I *know* all the operator precedences. It just happens that I > keep some of that knowledge outside my head.) > > I would certainly advocate using parentheses in that case. > BartC inferred that Tim would recommend *not* using parentheses. > I agree on all points. I think this represents a very good defensive practice. The virtue I've come to find in Tim Rentsch's alternative is precisely that it is not "defensive". I see it as an expression of faith in one's fellow programmers. It's coding without training wheels. It invites the reader to learn something new or apply something rusty. It's documented. It's consistent with the behavior of the machine (unless you make a mistake). It is more parsimonious. The more hyperbolic comments just add to the pizzazz. The tag line is still "learn the language" which I think is very consistent with my impression of your position. I think the difference is one of degree or attidude or some other metric metaphor. -- elite w/o elitism
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 10:35 +0100 |
| Message-ID | <nn225c$pss$1@dont-email.me> |
| In reply to | #90888 |
On 24/07/2016 04:55, Keith Thompson wrote: > luser droog <luser.droog@gmail.com> writes: >> What he said (IIRC) was ditch the parens and use spaces. You should >> know (or being willing to learn) the relative precedences of the >> operators that you use in an expression. And you should use spaces >> to demonstrate what you (the programmer) intend. > A more relevant example might be: > x | y ^ z > That expression is entirely unambiguous as far as the C standard is > concerned. Tim would argue that a C programmer would know that it's > equivalent to > x | (y ^ z) > and in principle I agree, > I would certainly advocate using parentheses in that case. > BartC inferred that Tim would recommend *not* using parentheses. How, after all that's said above, can you doubt that Tim would not use or recommend parentheses? What purpose would they serve if everyone involved, coders, readers and maintainers, knows the precedences INSIDE OUT? (I would start worrying about your job I think if you don't know them!) (And in your example, if no one - or no ordinary programmer with a job to do and familiar with multiple languages - can think off-hand why the precedence of ^ should be more or less than | for example, then I don't agree they should be different at all.) Anyway, we might learn the answer in a couple of months (maybe he works on a ship and can only post when he's in port or something). But then, he doesn't always like answering such direct questions. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-24 02:55 -0700 |
| Message-ID | <lntwffe4wn.fsf@kst-u.example.com> |
| In reply to | #90891 |
BartC <bc@freeuk.com> writes:
> On 24/07/2016 04:55, Keith Thompson wrote:
>> luser droog <luser.droog@gmail.com> writes:
>
>>> What he said (IIRC) was ditch the parens and use spaces. You should
>>> know (or being willing to learn) the relative precedences of the
>>> operators that you use in an expression. And you should use spaces
>>> to demonstrate what you (the programmer) intend.
>
>> A more relevant example might be:
>> x | y ^ z
>> That expression is entirely unambiguous as far as the C standard is
>> concerned. Tim would argue that a C programmer would know that it's
>> equivalent to
>> x | (y ^ z)
>> and in principle I agree,
>
>> I would certainly advocate using parentheses in that case.
>> BartC inferred that Tim would recommend *not* using parentheses.
>
> How, after all that's said above, can you doubt that Tim would not use
> or recommend parentheses? What purpose would they serve if everyone
> involved, coders, readers and maintainers, knows the precedences INSIDE
> OUT? (I would start worrying about your job I think if you don't know them!)
I simply don't know, that's all.
> (And in your example, if no one - or no ordinary programmer with a job
> to do and familiar with multiple languages - can think off-hand why the
> precedence of ^ should be more or less than | for example, then I don't
> agree they should be different at all.)
You don't agree with whom? Has anyone here said that ^ *should* have
higher precedence than |? Or do you just mean you disagree with the way
C defines them?
> Anyway, we might learn the answer in a couple of months (maybe he works
> on a ship and can only post when he's in port or something). But then,
> he doesn't always like answering such direct questions.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-24 04:05 -0700 |
| Message-ID | <9cc31b74-0ab7-487d-8289-eebce54a5eb3@googlegroups.com> |
| In reply to | #90892 |
On Sunday, July 24, 2016 at 10:56:01 AM UTC+1, Keith Thompson wrote: > > You don't agree with whom? Has anyone here said that ^ *should* have > higher precedence than |? Or do you just mean you disagree with the way > C defines them? > Someone can write x^y|z and it's not desirable to make a special grammar rule to disallow that. In practice it's unlikely, as there's not much call for building up logical expressions on bitsets in that way, and there's no ^^ operator so the issue doesn't arise for booleans. Because it is unlikely, there's no firm convention. So the choices are a) make it implementation-defined. Pretty pointless, you're just introducing gratuitous opportunities for portability bugs, b) make it left to right precedence, c) give the operators two different level of precedence. There is already a convention for | and &. So c) is the obvious choice. But you can't expect anyone to remember it, and programmers shouldn't rely on it. Just use parentheses. But if someone forgets the parentheses it's not a disaster. Usually it's clear what the expression should be from context, so you can just insert the parentheses to force it to be correct, without necessarily knowing whether that was a bug or not. Or if you know that the code is correct, you know what the precedence must be. Or look it up or put in a diagnostic printf() to check if anything hangs on the matter.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-24 14:03 +0100 |
| Message-ID | <8737mzrxwm.fsf@bsb.me.uk> |
| In reply to | #90893 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, July 24, 2016 at 10:56:01 AM UTC+1, Keith Thompson wrote: >> >> You don't agree with whom? Has anyone here said that ^ *should* have >> higher precedence than |? Or do you just mean you disagree with the way >> C defines them? >> > Someone can write > > x^y|z > > and it's not desirable to make a special grammar rule to disallow that. > In practice it's unlikely, as there's not much call for building up > logical expressions on bitsets in that way, and there's no ^^ operator > so the issue doesn't arise for booleans. Because it is unlikely, there's > no firm convention. > So the choices are a) make it implementation-defined. Pretty pointless, > you're just introducing gratuitous opportunities for portability bugs, > b) make it left to right precedence, c) give the operators two different > level of precedence. b) is usually phrased "make them associate left to right" or, more informally, "they group to the left". > There is already a convention for | and &. So c) is the obvious > choice. Not to me. There is a convention for | and & based on the analogy with arithmetic operations. But | and ^ are, in my mind, both "additive" like + and - (with ^ playing the role not unlike that of -) so I'd expect b) not c). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 14:24 +0100 |
| Message-ID | <nn2fi7$2h8$1@dont-email.me> |
| In reply to | #90895 |
On 24/07/2016 14:03, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Sunday, July 24, 2016 at 10:56:01 AM UTC+1, Keith Thompson wrote: >>> >>> You don't agree with whom? Has anyone here said that ^ *should* have >>> higher precedence than |? Or do you just mean you disagree with the way >>> C defines them? >>> >> Someone can write >> >> x^y|z >> >> and it's not desirable to make a special grammar rule to disallow that. >> In practice it's unlikely, as there's not much call for building up >> logical expressions on bitsets in that way, and there's no ^^ operator >> so the issue doesn't arise for booleans. Because it is unlikely, there's >> no firm convention. >> So the choices are a) make it implementation-defined. Pretty pointless, >> you're just introducing gratuitous opportunities for portability bugs, >> b) make it left to right precedence, c) give the operators two different >> level of precedence. > > b) is usually phrased "make them associate left to right" or, more > informally, "they group to the left". > >> There is already a convention for | and &. So c) is the obvious >> choice. > > Not to me. There is a convention for | and & based on the analogy with > arithmetic operations. But | and ^ are, in my mind, both "additive" > like + and - (with ^ playing the role not unlike that of -) so I'd > expect b) not c). To me, logical operators && and || are different from the bitwise versions & and |. Bitwise, there are 32 or 64 parallel operations on each pair of bits. There is scaling or shifting of the result, and no carry propagation takes place between bits. The same for ^. So there is no relation really to either multiply/divide, or add/subtract. And no reason for any of &, | or ^ to be higher precedence than any other. (It doesn't even matter whether the evaluation is done left to right or right to left.) (In my languages, in order to keep the precedence levels minimal, bitwise ops share the same level as add and subtract. And actually, the first language I created a compiler for, didn't have precedence levels or even parentheses IIRC; everything was evaluated strictly left to right, like a cheap calculator.) --
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 15:15 +0100 |
| Message-ID | <nn2iip$c3a$1@dont-email.me> |
| In reply to | #90896 |
On 24/07/2016 14:24, BartC wrote: [& | ^ operators] > There is scaling or shifting of the result No scaling or shifting, I mean. (It doesn't even matter whether the evaluation is done > left to right or right to left.) That's for two operands. For N operands (and mixed bitwise ops) it can matter very much which end you start from! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 16:01 +0100 |
| Message-ID | <nn2l97$ktt$1@dont-email.me> |
| In reply to | #90895 |
On 24/07/2016 14:03, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Sunday, July 24, 2016 at 10:56:01 AM UTC+1, Keith Thompson wrote: >>> >>> You don't agree with whom? Has anyone here said that ^ *should* have >>> higher precedence than |? Or do you just mean you disagree with the way >>> C defines them? >>> >> Someone can write >> >> x^y|z >> >> and it's not desirable to make a special grammar rule to disallow that. >> In practice it's unlikely, as there's not much call for building up >> logical expressions on bitsets in that way, You never know what people will need. In electronics, there's nothing to stop you inputting x,y to a 2-input XOR-gate, and feeding the output and z to a 2-input OR gate (ie. (x^y)|z). Or inputting y,z to a 2-input OR-gate, and feeding the output and x to a 2-input XOR gate (ie. x^(y|z)). So why shouldn't the same be done in code? Notice that with 2-input gates, you necessarily have to use 'parentheses'. There is no 3-input gate that does a composite XOR and OR! (You can make one, but it would be highly non-standard, and you must specify its behaviour as (x^y)|z or x^(y|z).) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-24 11:36 -0700 |
| Message-ID | <b34c2b23-7644-415c-ba3e-60c22f019ea1@googlegroups.com> |
| In reply to | #90899 |
On Sunday, July 24, 2016 at 4:02:06 PM UTC+1, Bart wrote: > On 24/07/2016 14:03, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > >> On Sunday, July 24, 2016 at 10:56:01 AM UTC+1, Keith Thompson wrote: > >>> > >>> You don't agree with whom? Has anyone here said that ^ *should* have > >>> higher precedence than |? Or do you just mean you disagree with the way > >>> C defines them? > >>> > >> Someone can write > >> > >> x^y|z > >> > >> and it's not desirable to make a special grammar rule to disallow that. > >> In practice it's unlikely, as there's not much call for building up > >> logical expressions on bitsets in that way, > > You never know what people will need. In electronics, there's nothing to > stop you inputting x,y to a 2-input XOR-gate, and feeding the output and > z to a 2-input OR gate (ie. (x^y)|z). > > Or inputting y,z to a 2-input OR-gate, and feeding the output and x to a > 2-input XOR gate (ie. x^(y|z)). > > So why shouldn't the same be done in code? Notice that with 2-input > gates, you necessarily have to use 'parentheses'. > > There is no 3-input gate that does a composite XOR and OR! (You can make > one, but it would be highly non-standard, and you must specify its > behaviour as (x^y)|z or x^(y|z).) > Let's write it out x y z (x^y)|z x^(y|z) 0 0 0 0 0 1 0 0 1 1 0 1 0 1 1 1 1 0 0 0 0 0 1 1 1 1 0 1 1 0 0 1 1 1 1 1 1 1 1 0 We've got 8 possibilities and 256 possible result sets. Those look to me like just two of those 256 plucked at random, with no rhyme or reason. You can invent a use, but it's not something that is at all likely to crop up.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 19:52 +0100 |
| Message-ID | <nn32pi$4sn$1@dont-email.me> |
| In reply to | #90910 |
On 24/07/2016 19:36, Malcolm McLean wrote: > On Sunday, July 24, 2016 at 4:02:06 PM UTC+1, Bart wrote: >> You never know what people will need. In electronics, there's nothing to >> stop you inputting x,y to a 2-input XOR-gate, and feeding the output and >> z to a 2-input OR gate (ie. (x^y)|z). >> >> Or inputting y,z to a 2-input OR-gate, and feeding the output and x to a >> 2-input XOR gate (ie. x^(y|z)). >> >> So why shouldn't the same be done in code? > Let's write it out > > x y z (x^y)|z x^(y|z) > 0 0 0 0 0 > 1 0 0 1 1 > 0 1 0 1 1 > 1 1 0 0 0 > 0 0 1 1 1 > 1 0 1 1 0 > 0 1 1 1 1 > 1 1 1 1 0 > > > We've got 8 possibilities and 256 possible result sets. > Those look to me like just two of those 256 plucked at random, > with no rhyme or reason. You can invent a use, but it's not > something that is at all likely to crop up. Separate them out. Start with A=y|z, which has plenty of uses: x y z A=y|z x^A 0 0 0 0 0 0 0 1 1 1 0 1 0 1 1 0 1 1 1 1 1 0 0 0 1 1 0 1 1 0 1 1 0 1 0 1 1 1 1 0 Now suppose you need either A, or the inverse of A, depending on whether some other signal x is 0 or 1 respectively. You can use XOR for this with A as one input and x as the other: A = y|z B = x^A But this can be written in a single expression: B = x^(y|z) You just can't say that a particular logical expression has no use. -- Bart
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-24 12:14 -0700 |
| Message-ID | <ebfa1cc4-c943-4ff0-9bab-003fe0e87d12@googlegroups.com> |
| In reply to | #90911 |
On Sunday, July 24, 2016 at 7:52:42 PM UTC+1, Bart wrote: > On 24/07/2016 19:36, Malcolm McLean wrote: > > On Sunday, July 24, 2016 at 4:02:06 PM UTC+1, Bart wrote: > > >> You never know what people will need. In electronics, there's nothing to > >> stop you inputting x,y to a 2-input XOR-gate, and feeding the output and > >> z to a 2-input OR gate (ie. (x^y)|z). > >> > >> Or inputting y,z to a 2-input OR-gate, and feeding the output and x to a > >> 2-input XOR gate (ie. x^(y|z)). > >> > >> So why shouldn't the same be done in code? > > > Let's write it out > > > > x y z (x^y)|z x^(y|z) > > 0 0 0 0 0 > > 1 0 0 1 1 > > 0 1 0 1 1 > > 1 1 0 0 0 > > 0 0 1 1 1 > > 1 0 1 1 0 > > 0 1 1 1 1 > > 1 1 1 1 0 > > > > > > We've got 8 possibilities and 256 possible result sets. > > Those look to me like just two of those 256 plucked at random, > > with no rhyme or reason. You can invent a use, but it's not > > something that is at all likely to crop up. > > Separate them out. Start with A=y|z, which has plenty of uses: > > x y z A=y|z x^A > 0 0 0 0 0 > 0 0 1 1 1 > 0 1 0 1 1 > 0 1 1 1 1 > > 1 0 0 0 1 > 1 0 1 1 0 > 1 1 0 1 0 > 1 1 1 1 0 > > Now suppose you need either A, or the inverse of A, depending on whether > some other signal x is 0 or 1 respectively. You can use XOR for this > with A as one input and x as the other: > > A = y|z > B = x^A > > But this can be written in a single expression: > > B = x^(y|z) > > You just can't say that a particular logical expression has no use. > if( y or z ) flip x; fair enough, that could crop up. But you'd likely want to write it out like that.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-24 11:13 -0700 |
| Message-ID | <kfnd1m2sy41.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90895 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Sunday, July 24, 2016 at 10:56:01 AM UTC+1, Keith Thompson wrote: >> >>> You don't agree with whom? Has anyone here said that ^ *should* have >>> higher precedence than |? Or do you just mean you disagree with the way >>> C defines them? >> >> Someone can write >> >> x^y|z >> >> and it's not desirable to make a special grammar rule to disallow that. >> In practice it's unlikely, as there's not much call for building up >> logical expressions on bitsets in that way, and there's no ^^ operator >> so the issue doesn't arise for booleans. Because it is unlikely, there's >> no firm convention. >> So the choices are a) make it implementation-defined. Pretty pointless, >> you're just introducing gratuitous opportunities for portability bugs, >> b) make it left to right precedence, c) give the operators two different >> level of precedence. > > b) is usually phrased "make them associate left to right" or, more > informally, "they group to the left". > >> There is already a convention for | and &. So c) is the obvious >> choice. > > Not to me. There is a convention for | and & based on the analogy with > arithmetic operations. But | and ^ are, in my mind, both "additive" > like + and - (with ^ playing the role not unlike that of -) so I'd > expect b) not c). Let me offer a different perspective on that. All of the bitwise operators &, ^, and | are (individually) both associative and commutative. The bitwise operator ^ is not a good analogy to subtraction (or division) because those operations are neither commutative nor associative. I don't know of a good analogy for the operation of bitwise XOR in the arithmetic domain. But, in terms of bitwise operations, we can look at what the different operations do. An AND operation "makes things smaller", ie, cannot increase the number of one bits. An OR operation "makes things bigger", ie, cannot decrease the number of one bits. An XOR operation "moves things around" - it might increase the number of one bits, or decrease the number of one bits, or increase in one area and decrease in another. If AND is at one end of the spectrum, and OR is at the other end, then it seems reasonable that XOR should be somewhere in the middle. And that's how it is in C precedence rules.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-07-24 14:52 -0500 |
| Message-ID | <nn369o$hjb$1@dont-email.me> |
| In reply to | #90908 |
On 7/24/2016 1:13 PM, Tim Rentsch wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Sunday, July 24, 2016 at 10:56:01 AM UTC+1, Keith Thompson wrote: >>> >>>> You don't agree with whom? Has anyone here said that ^ *should* have >>>> higher precedence than |? Or do you just mean you disagree with the way >>>> C defines them? >>> >>> Someone can write >>> >>> x^y|z >>> >>> and it's not desirable to make a special grammar rule to disallow that. >>> In practice it's unlikely, as there's not much call for building up >>> logical expressions on bitsets in that way, and there's no ^^ operator >>> so the issue doesn't arise for booleans. Because it is unlikely, there's >>> no firm convention. >>> So the choices are a) make it implementation-defined. Pretty pointless, >>> you're just introducing gratuitous opportunities for portability bugs, >>> b) make it left to right precedence, c) give the operators two different >>> level of precedence. >> >> b) is usually phrased "make them associate left to right" or, more >> informally, "they group to the left". >> >>> There is already a convention for | and &. So c) is the obvious >>> choice. >> >> Not to me. There is a convention for | and & based on the analogy with >> arithmetic operations. But | and ^ are, in my mind, both "additive" >> like + and - (with ^ playing the role not unlike that of -) so I'd >> expect b) not c). > > Let me offer a different perspective on that. > > All of the bitwise operators &, ^, and | are (individually) both > associative and commutative. The bitwise operator ^ is not a > good analogy to subtraction (or division) because those > operations are neither commutative nor associative. I don't know > of a good analogy for the operation of bitwise XOR in the > arithmetic domain. Mathematically, XOR is a better analogy for addition than OR. If you combine XOR and AND, you get a field. You don't when you combine OR and AND. > But, in terms of bitwise operations, we can look at what the > different operations do. An AND operation "makes things > smaller", ie, cannot increase the number of one bits. An OR > operation "makes things bigger", ie, cannot decrease the number > of one bits. An XOR operation "moves things around" - it might > increase the number of one bits, or decrease the number of one > bits, or increase in one area and decrease in another. If AND > is at one end of the spectrum, and OR is at the other end, then > it seems reasonable that XOR should be somewhere in the middle. > And that's how it is in C precedence rules. > Is this just speculation or do you have some evidence that this was how it came about? Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-25 09:59 -0700 |
| Message-ID | <kfnzip5r6ve.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90913 |
Martin Shobe <mashobe9@gmail.com> writes: > On 7/24/2016 1:13 PM, Tim Rentsch wrote: >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> >>>> On Sunday, July 24, 2016 at 10:56:01 AM UTC+1, Keith Thompson wrote: >>>> >>>>> You don't agree with whom? Has anyone here said that ^ *should* have >>>>> higher precedence than |? Or do you just mean you disagree with the way >>>>> C defines them? >>>> >>>> Someone can write >>>> >>>> x^y|z >>>> >>>> and it's not desirable to make a special grammar rule to disallow that. >>>> In practice it's unlikely, as there's not much call for building up >>>> logical expressions on bitsets in that way, and there's no ^^ operator >>>> so the issue doesn't arise for booleans. Because it is unlikely, there's >>>> no firm convention. >>>> So the choices are a) make it implementation-defined. Pretty pointless, >>>> you're just introducing gratuitous opportunities for portability bugs, >>>> b) make it left to right precedence, c) give the operators two different >>>> level of precedence. >>> >>> b) is usually phrased "make them associate left to right" or, more >>> informally, "they group to the left". >>> >>>> There is already a convention for | and &. So c) is the obvious >>>> choice. >>> >>> Not to me. There is a convention for | and & based on the analogy with >>> arithmetic operations. But | and ^ are, in my mind, both "additive" >>> like + and - (with ^ playing the role not unlike that of -) so I'd >>> expect b) not c). >> >> Let me offer a different perspective on that. >> >> All of the bitwise operators &, ^, and | are (individually) both >> associative and commutative. The bitwise operator ^ is not a >> good analogy to subtraction (or division) because those >> operations are neither commutative nor associative. I don't know >> of a good analogy for the operation of bitwise XOR in the >> arithmetic domain. > > Mathematically, XOR is a better analogy for addition than OR. If you > combine XOR and AND, you get a field. You don't when you combine OR > and AND. Interesting observation. >> But, in terms of bitwise operations, we can look at what the >> different operations do. An AND operation "makes things >> smaller", ie, cannot increase the number of one bits. An OR >> operation "makes things bigger", ie, cannot decrease the number >> of one bits. An XOR operation "moves things around" - it might >> increase the number of one bits, or decrease the number of one >> bits, or increase in one area and decrease in another. If AND >> is at one end of the spectrum, and OR is at the other end, then >> it seems reasonable that XOR should be somewhere in the middle. >> And that's how it is in C precedence rules. > > Is this just speculation or do you have some evidence that this was > how it came about? Oh, I didn't mean to say this description occurred (or did not occur) to any of the people responsible for choosing the precedences of these operators in C or its precursors. It is a pure after-the-fact memory aid (or rationalization, if you will). But it makes sense to me. If the three bitwise operators &, ^, | all have separate levels of predecence, putting ^ in the middle is (at least to me) the least surprising of the three possible choices.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <mashobe9@gmail.com> |
|---|---|
| Date | 2016-07-25 19:32 -0500 |
| Message-ID | <nn6b3j$720$1@dont-email.me> |
| In reply to | #91035 |
On 7/25/2016 11:59 AM, Tim Rentsch wrote: > Martin Shobe <mashobe9@gmail.com> writes: >> On 7/24/2016 1:13 PM, Tim Rentsch wrote: >>> But, in terms of bitwise operations, we can look at what the >>> different operations do. An AND operation "makes things >>> smaller", ie, cannot increase the number of one bits. An OR >>> operation "makes things bigger", ie, cannot decrease the number >>> of one bits. An XOR operation "moves things around" - it might >>> increase the number of one bits, or decrease the number of one >>> bits, or increase in one area and decrease in another. If AND >>> is at one end of the spectrum, and OR is at the other end, then >>> it seems reasonable that XOR should be somewhere in the middle. >>> And that's how it is in C precedence rules. >> >> Is this just speculation or do you have some evidence that this was >> how it came about? > > Oh, I didn't mean to say this description occurred (or did not > occur) to any of the people responsible for choosing the > precedences of these operators in C or its precursors. It is a > pure after-the-fact memory aid (or rationalization, if you will). > But it makes sense to me. If the three bitwise operators &, ^, | > all have separate levels of predecence, putting ^ in the middle > is (at least to me) the least surprising of the three possible > choices. > That makes sense. Thanks. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-25 07:39 -0700 |
| Message-ID | <7f69fefb-1c32-496a-96ff-4d2d57e32b16@googlegroups.com> |
| In reply to | #90908 |
On Sunday, July 24, 2016 at 1:13:43 PM UTC-5, Tim Rentsch wrote: > All of the bitwise operators &, ^, and | are (individually) both > associative and commutative. The bitwise operator ^ is not a > good analogy to subtraction (or division) because those > operations are neither commutative nor associative. I don't know > of a good analogy for the operation of bitwise XOR in the > arithmetic domain. The logical analogue to subtraction would be an operator which would be equivalent to &~ in cases where the left and right operands have the same type (but which, unlike the operator pair &~, would promote the right-hand operator before taking the complement). Some machine languages include an instruction for that purpose, since it is often a useful operation in bit- related code, but it doesn't seem to be commonplace in programming languages. Note that on e.g. a 32-bit machine, C's type rules mean that code like: firstUint64 &=~ 0x00000000400000000; secondUint64 &=~ 0x00000000800000000; thirdUint64 &=~ 0x00000001000000000; will clear one bit each of firstUint64 and thirdUint64, but will clear 33 bits of secondUint64. Probably not what would be intended, but the lack of a unified "and-not" operator means that the result of "~" is promoted, rather than the operand.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-24 10:55 -0700 |
| Message-ID | <kfnh9besyya.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90880 |
Keith Thompson <kst-u@mib.org> writes: > BartC <bc@freeuk.com> writes: >> On 23/07/2016 20:51, Keith Thompson wrote: > > [...] > >>> I do not recall Tim saying that this implies one should not use >>> parentheses for clarity. Do you? >> >> He said (referring to knowing all binary op precedence levels): >> >> "I would. And do. And happy to do it. If you can't take >> the heat, stay out of the kitchen." >> >> So he knows exactly what every expression means, and suggests that only >> those who also know all the levels should be coding. So why would anyone >> need extra parentheses? Either something is already clear, or you >> shouldn't be programming. > > Was that intended to answer my question? I believe you are inferring > things he didn't say. My comment that started this subthread, together with its orginal context, is this: >>->> BartC <bc@freeuk.com> writes: >>->> >>->> > Are you suggesting that every C programmer ought to know the >>->> > precedence levels of all ten binary operators? >>->> >>->> I would. And do. And happy to do it. If you can't take >>->> the heat, stay out of the kitchen. >>->> >>->> (P.S. There are a lot more than ten.) That's the whole thing. It didn't say anything about how to write code, or that all C programmers /do/ know all the precedence levels, or that one should assume that they do. Only that they ought to know them, and by implication that they should learn if they don't.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-24 08:30 -0700 |
| Message-ID | <kfnlh0rrr3x.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90845 |
BartC <bc@freeuk.com> writes: > On 23/07/2016 11:08, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> <snip> >>> Some people are deluded. There /are/ more precedences than would be >>> reasonable. There /is/ no earthly why <= and == need to have different >>> precedences. And, while there might be a reason why &, ^ and | need to >>> be all different (which I can't think of), there /isn't/ a good one >>> why they all have to be lower than == and <=. (Which means that if >>> (a&b != 0x800) doesn't do what you think.) >> >> I'm curious. If a significant number of people here (maybe all) posted >> their agreement to these complaints, would you stop moaning about C? In >> other words, what's the point of all these posts? Do you want to >> persuade people of the error of C's ways (and if so to what purpose)? >> Or maybe want to show how much better your choices would have been? > > Well Tim Rentsch also has strong and sometimes unconventional views > (despite saying that mine don't count as they are just my opinions!). > > It was him who recommended that people learn *all* the precedences > implying that parentheses should not be used for clarity. That sounded > too much like the school of thought that either programmers should be > perfect, or they should give it up. > > I was putting the opposite view in this sub-thread. > >> Or do you just enjoy a bit of dust up? > > That too. Coming here is a diversion. (And political forums are > becoming boring again in the UK after the last few weeks.) > > And admit that /you/ like sparring with Malcolm for example... Bart is deliberately misrepresenting my comments. He has shown himself in this newsgroup to be nothing more than a provocateur. I hope everyone will keep this in mind when reading his comments or considering a reply. I have no plans to respond to any other of his comments at this time.
[toc] | [prev] | [next] | [standalone]
Page 8 of 18 — ← Prev page 1 … 6 7 [8] 9 10 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web