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 6 of 18 — ← Prev page 1 … 4 5 [6] 7 8 … 18 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-12 18:22 +0100 |
| Message-ID | <nm3915$rlk$1@dont-email.me> |
| In reply to | #90287 |
On 12/07/2016 17:40, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> On Tuesday, July 12, 2016 at 4:44:21 PM UTC+1, Keith Thompson wrote: >>> Imagine a C-like language that differs from C only in that "sizeof" >>> is spelled "$". I presume that, in such a language, you'd be willing >>> to write `$ foo` rather than `$(foo)`. Why does the fact that it's >>> spelled "sizeof" change that? >>> >> Special mathematical symbols are used for basic operations like addition. >> These operations are also functions, you can graph them, take derivatives, >> and so on. > > They're not "functions" in the sense that C uses the word. > >> More complex operations don't always have special symbols, we use >> identifiers like cos or log. And some operations like exponentiation are >> sometimes represented using one convention, sometimes the other, sometimes >> people will write pow(x,y), sometimes x^y or x**y (or the superscript >> convention which I can't type here) > > And in mathematics, it's common to write `cos x` without parentheses. > The word `cos` is treated like a symbol. Not just in maths. In my languages (perhaps others too), things such as 'sin' and 'cos' are operators. That means I can write: y := sin x but I nearly always write sin(x) instead. Although that's partly because I forget I can leave out the parentheses and my fingers just type them, I think it looks better. I wouldn't be against making them mandatory. (I also have operators such 'max' that can written as x max y, or max(x,y) with obligatory parentheses.) Language source code isn't mathematical notation. Not until you can write xy to mean x*y. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-07-13 18:33 +0100 |
| Message-ID | <87shvdqw7h.fsf@gmail.com> |
| In reply to | #90287 |
Keith Thompson <kst-u@mib.org> writes: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> On Tuesday, July 12, 2016 at 4:44:21 PM UTC+1, Keith Thompson wrote: >>> Imagine a C-like language that differs from C only in that "sizeof" >>> is spelled "$". I presume that, in such a language, you'd be willing >>> to write `$ foo` rather than `$(foo)`. Why does the fact that it's >>> spelled "sizeof" change that? >>> >> Special mathematical symbols are used for basic operations like addition. >> These operations are also functions, you can graph them, take derivatives, >> and so on. > > They're not "functions" in the sense that C uses the word. Fortunately that word HAS PLENTY OF OTHER MEANINGS. Not everyone treats the C standard as a Holy Text, Keith. Just you.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-13 14:00 -0400 |
| Message-ID | <16c850f5-d470-8442-0536-360cda8c9d21@verizon.net> |
| In reply to | #90338 |
On 07/13/2016 01:33 PM, Gareth Owen wrote: > Keith Thompson <kst-u@mib.org> writes: ... >> They're not "functions" in the sense that C uses the word. > > Fortunately that word HAS PLENTY OF OTHER MEANINGS. > Not everyone treats the C standard as a Holy Text, Keith. Just you. It isn't a holy text, and Keith doesn't treat it as one. It is, however, the authoritative text for the C language. Holy text is authoritative (at least for those who believe in it's holiness), but authoritative text is not necessarily holy. The standard was written by a committee of very human people, fully capable of making mistakes, and Keith is just as aware as I am that some mistakes were in fact made when writing it. No one has claimed that the committee was divinely inspired. Despite that, it is still, in fact, authoritative. If you're talking about C, and you use a phrase for which the C standard provides a definition, it should be understood as having that meaning. If you intend any other meaning, you should preferably use a different phrase; if that's too inconvenient, you should at least always make clear which alternative meaning you're using.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-13 19:16 +0100 |
| Message-ID | <nm60ht$n26$1@dont-email.me> |
| In reply to | #90338 |
On 13/07/16 18:33, Gareth Owen wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> On Tuesday, July 12, 2016 at 4:44:21 PM UTC+1, Keith Thompson wrote: >>>> Imagine a C-like language that differs from C only in that "sizeof" >>>> is spelled "$". I presume that, in such a language, you'd be willing >>>> to write `$ foo` rather than `$(foo)`. Why does the fact that it's >>>> spelled "sizeof" change that? >>>> >>> Special mathematical symbols are used for basic operations like addition. >>> These operations are also functions, you can graph them, take derivatives, >>> and so on. >> >> They're not "functions" in the sense that C uses the word. > > Fortunately that word HAS PLENTY OF OTHER MEANINGS. Sure. So what? In the context of the C language, it has one meaning that is so overwhelmingly important that any other usages are bound to meet with at least the potential for confusion. So it's probably best to stick to the C meaning of the word. (To be fair to Malcolm, he did at least point out that he was using the word 'function' in its mathematical sense rather than its C sense, so Keith was perhaps a little quick on the trigger there.) > Not everyone treats the C standard as a Holy Text, Keith. Just you. Steady on there, Gareth. He's not the only one. James K is there every Sunday, too. And Eric S. And Ben, of course. And a number of other people that you would certainly know by name. We're a diminishing congregation but still a fairly sizeable one. Why not come along to the next meeting? Every Sunday, 9899 Isoiec Street. If you can play the pipe-organ, so much the better. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-18 09:15 -0700 |
| Message-ID | <kfnvb02ylae.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90338 |
Gareth Owen <gwowen@gmail.com> writes: > Keith Thompson <kst-u@mib.org> writes: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> On Tuesday, July 12, 2016 at 4:44:21 PM UTC+1, Keith Thompson wrote: >>>> Imagine a C-like language that differs from C only in that "sizeof" >>>> is spelled "$". I presume that, in such a language, you'd be willing >>>> to write `$ foo` rather than `$(foo)`. Why does the fact that it's >>>> spelled "sizeof" change that? >>> >>> Special mathematical symbols are used for basic operations like addition. >>> These operations are also functions, you can graph them, take derivatives, >>> and so on. >> >> They're not "functions" in the sense that C uses the word. > > Fortunately that word HAS PLENTY OF OTHER MEANINGS. > Not everyone treats the C standard as a Holy Text, Keith. Just you. The question here is not which usage is authoritative, but which one makes the most sense in context. The posting that Keith was responding to talks about "using the same syntax" (ie, as C function calls). Given that, it seems appropriate to point out a difference between the various senses of the word. At some level I think it is precisely because "function" is being used in different senses that confusion and argument arise.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-18 09:04 -0700 |
| Message-ID | <kfnzipfx78c.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90274 |
Keith Thompson <kst-u@mib.org> writes: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > [...] >> Yes, it's undesireable that C's syntax permits sizeof without the >> parentheses. > > sizeof is a unary operator, like &, *, +, -, ~, and !. Is it > undesirable that C permits them to be used without parentheses? > [...] Micro-nit: Although 'sizeof' expressions are unary expressions, 'sizeof' is not a unary operator (nor is '++' or '--'), as the Standard defines the term. Also it is worth remembering that there is another form of unary expression in C (including pre-C11 C) where the operation symbol is not a punctuator (ie, it is alphabetic).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-18 11:10 -0700 |
| Message-ID | <lnpoqavmto.fsf@kst-u.example.com> |
| In reply to | #90512 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>>> Yes, it's undesireable that C's syntax permits sizeof without the
>>> parentheses.
>>
>> sizeof is a unary operator, like &, *, +, -, ~, and !. Is it
>> undesirable that C permits them to be used without parentheses?
>> [...]
>
> Micro-nit: Although 'sizeof' expressions are unary expressions,
> 'sizeof' is not a unary operator (nor is '++' or '--'), as the
> Standard defines the term.
Good point. (I believe it's defined that way because &, *, et al take a
cast-expression as their operand, while sizeof takes a unary-expression.
The distinction avoids ambiguities in some cases.)
> Also it is worth remembering that there is another form of unary
> expression in C (including pre-C11 C) where the operation symbol
> is not a punctuator (ie, it is alphabetic).
Are you referring to `sizeof ( type-name )`?
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-20 08:52 -0700 |
| Message-ID | <kfnh9bkux0r.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90530 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> [...] >>>> Yes, it's undesireable that C's syntax permits sizeof without the >>>> parentheses. >>> >>> sizeof is a unary operator, like &, *, +, -, ~, and !. Is it >>> undesirable that C permits them to be used without parentheses? >>> [...] >> >> Micro-nit: Although 'sizeof' expressions are unary expressions, >> 'sizeof' is not a unary operator (nor is '++' or '--'), as the >> Standard defines the term. > > Good point. (I believe it's defined that way because &, *, et al take a > cast-expression as their operand, while sizeof takes a unary-expression. > The distinction avoids ambiguities in some cases.) Yes, that was my reaction also. >> Also it is worth remembering that there is another form of unary >> expression in C (including pre-C11 C) where the operation symbol >> is not a punctuator (ie, it is alphabetic). > > Are you referring to `sizeof ( type-name )`? No, I lump that in with the other sizeof. I deliberaly didn't say before to let people have the pleasure of discovering it for themselves, but enough time has passed so a spoiler is warranted. Section 6.10.1 p1. (Note that here too this operator may be used without parentheses.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-20 09:36 -0700 |
| Message-ID | <lnwpkgl11j.fsf@kst-u.example.com> |
| In reply to | #90664 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
>>> Also it is worth remembering that there is another form of unary
>>> expression in C (including pre-C11 C) where the operation symbol
>>> is not a punctuator (ie, it is alphabetic).
>>
>> Are you referring to `sizeof ( type-name )`?
>
> No, I lump that in with the other sizeof. I deliberaly didn't
> say before to let people have the pleasure of discovering it for
> themselves, but enough time has passed so a spoiler is warranted.
> Section 6.10.1 p1. (Note that here too this operator may be used
> without parentheses.)
Very cute. But I question whether that's really a "unary
expression". I note that 6.10.1p1 doesn't use that phrase (though
that's likely what was intended), and I cite the definition of
"unary-expression" in 6.5.3.
Bottom line: I'd say the wording is a bit sloppy, with the result
that the meaning is still perfectly clear but it can lead to pedantic
quibbles like this one.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-21 18:23 -0700 |
| Message-ID | <kfnr3amtqiv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90672 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Tim Rentsch <txr@alumni.caltech.edu> writes: > > [...] > >>>> Also it is worth remembering that there is another form of unary >>>> expression in C (including pre-C11 C) where the operation symbol >>>> is not a punctuator (ie, it is alphabetic). >>> >>> Are you referring to `sizeof ( type-name )`? >> >> No, I lump that in with the other sizeof. I deliberaly didn't >> say before to let people have the pleasure of discovering it for >> themselves, but enough time has passed so a spoiler is warranted. >> Section 6.10.1 p1. (Note that here too this operator may be used >> without parentheses.) > > Very cute. But I question whether that's really a "unary > expression". I note that 6.10.1p1 doesn't use that phrase (though > that's likely what was intended), and I cite the definition of > "unary-expression" in 6.5.3. > > Bottom line: I'd say the wording is a bit sloppy, with the result > that the meaning is still perfectly clear but it can lead to pedantic > quibbles like this one. I understand the quibble. My intention was to make a more substantial point: that other parts of C have operators like 'sizeof', ie, are alphabetic, and which allow parenthesizing the operand even though this is not logically necessary. Therefore it seems clear that the language authors recognize both forms as being acceptable practice. Otherwise, 'defined' would have been specified with only one of these two forms.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-12 08:42 +0100 |
| Message-ID | <nm271l$1o9$1@dont-email.me> |
| In reply to | #90246 |
On 12/07/16 05:56, Udyant Wig wrote: > On 07/12/2016 03:50 AM, BartC wrote: >> However it's not just about how compilers cope with this (obviously >> they do). It's the 'tokenising' that takes place in the mind of the >> human reader of the code that is also relevant. Using ...(*C) instead >> of ...*C makes it less likely that the * might be, however briefly, >> mistaken for a multiply. > > If you are saying that sizeof should be thought of as a function, > then Linus Torvalds would agree with you: > > <URL:https://lkml.org/lkml/2012/7/11/103> > > The mail is quite short, but I produce an excerpt here: > > But "sizeof()" really *is* a function. It acts exactly like a function > of it's argument. There is no reason to not treat it that way. Sure, the > C standard *allows* you to not have parenthesis around an expression > argument, but you should treat that as the parsing oddity it is, nothing > more. There is zero reason not to have the parenthesis there. Linus Torvalds is mistaken. It happens. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-12 11:24 +0100 |
| Message-ID | <87bn2317dl.fsf@bsb.me.uk> |
| In reply to | #90246 |
Udyant Wig <udyant.wig@gmail.com> writes: > On 07/12/2016 03:50 AM, BartC wrote: >> However it's not just about how compilers cope with this (obviously >> they do). It's the 'tokenising' that takes place in the mind of the >> human reader of the code that is also relevant. Using ...(*C) instead >> of ...*C makes it less likely that the * might be, however briefly, >> mistaken for a multiply. > > If you are saying that sizeof should be thought of as a function, > then Linus Torvalds would agree with you: > > <URL:https://lkml.org/lkml/2012/7/11/103> > > The mail is quite short, but I produce an excerpt here: > > But "sizeof()" really *is* a function. It acts exactly like a function > of it's argument. There is no reason to not treat it that way. Sure, the > C standard *allows* you to not have parenthesis around an expression > argument, but you should treat that as the parsing oddity it is, nothing > more. There is zero reason not to have the parenthesis there. No one ever made a splash by being moderate! It's true that sizeof acts like a mathematical function -- albeit one with a very peculiar domain (pieces of C syntax) -- but it does not act like a C function. Adding ()s will make it look like a C function and that is as likely to look as odd to some as leaving it looking like an operator will look odd to others. sizeof(int) // that's an odd function argument sizeof(array) // no conversion from array to pointer sizeof(*p) // unexpectedly valid even when p == NULL Basically sizeof *is* odd because it does an odd job. It had to be specified to be useful rather than consistent. I'd suggest that if parentheses are added (and I am sure they help some people parse sizeof expressions quickly), a space is kept before them to cause a deliberate "hang on" moment for the casual reader: f(x) // a function call sizeof (x) // is that a real function? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-12 11:52 +0100 |
| Message-ID | <nm2i5n$5e9$1@dont-email.me> |
| In reply to | #90260 |
On 12/07/2016 11:24, Ben Bacarisse wrote: > Udyant Wig <udyant.wig@gmail.com> writes: >> But "sizeof()" really *is* a function. It acts exactly like a function >> of it's argument. There is no reason to not treat it that way. Sure, the >> C standard *allows* you to not have parenthesis around an expression >> argument, but you should treat that as the parsing oddity it is, nothing >> more. There is zero reason not to have the parenthesis there. > > No one ever made a splash by being moderate! > > It's true that sizeof acts like a mathematical function -- albeit one > with a very peculiar domain (pieces of C syntax) -- but it does not act > like a C function. Adding ()s will make it look like a C function and > that is as likely to look as odd to some as leaving it looking like an > operator will look odd to others. It will also look like a C macro invocation, which are used everywhere. It can also look like a variable declaration: typedef int F; F(a); sizeof needs parentheses anyway when applied to a type, so necessarily have to look like a function call. (And I suspect most don't even know whether it is types or expressions that don't require the parentheses, so add them just in case!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-12 13:18 +0100 |
| Message-ID | <87shvfyrq6.fsf@bsb.me.uk> |
| In reply to | #90264 |
BartC <bc@freeuk.com> writes: > On 12/07/2016 11:24, Ben Bacarisse wrote: >> Udyant Wig <udyant.wig@gmail.com> writes: > >>> But "sizeof()" really *is* a function. It acts exactly like a function >>> of it's argument. There is no reason to not treat it that way. Sure, the >>> C standard *allows* you to not have parenthesis around an expression >>> argument, but you should treat that as the parsing oddity it is, nothing >>> more. There is zero reason not to have the parenthesis there. >> >> No one ever made a splash by being moderate! >> >> It's true that sizeof acts like a mathematical function -- albeit one >> with a very peculiar domain (pieces of C syntax) -- but it does not act >> like a C function. Adding ()s will make it look like a C function and >> that is as likely to look as odd to some as leaving it looking like an >> operator will look odd to others. > > It will also look like a C macro invocation, which are used > everywhere. I don't see what your point is. Just writing an identifier can look like a macro invocation. That's why is usual to recommend that macros be named in ALL_CAPS. > It can also look like a variable declaration: > > typedef int F; > > F(a); What's that got to do with ()s in uses of sizeof? It bolsters the case for not using redundant parentheses, but both sizeof(a); and sizeof a; can look like a declaration to someone who does not know what sizeof is. > sizeof needs parentheses anyway when applied to a type, so necessarily > have to look like a function call. Not like a C function call of course. That's why I'd always add a space before the ()s just to help avoid it being confused with one. > (And I suspect most don't even know > whether it is types or expressions that don't require the parentheses, > so add them just in case!) Yes, a lot of people do that. Surely the question though is what's the clearest way to show what's going on? I my view, if you like extra ()s then use them by try to show that sizeof is not a function. A space helps to do that and I'd use one where the () are required round a type name even when I don't used extra ()s round an expression. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-12 16:42 +0100 |
| Message-ID | <nm334m$48j$1@dont-email.me> |
| In reply to | #90266 |
On 12/07/2016 13:18, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 12/07/2016 11:24, Ben Bacarisse wrote: >>> Udyant Wig <udyant.wig@gmail.com> writes: >> >>>> But "sizeof()" really *is* a function. It acts exactly like a function >>>> of it's argument. There is no reason to not treat it that way. Sure, the >>>> C standard *allows* you to not have parenthesis around an expression >>>> argument, but you should treat that as the parsing oddity it is, nothing >>>> more. There is zero reason not to have the parenthesis there. >>> >>> No one ever made a splash by being moderate! >>> >>> It's true that sizeof acts like a mathematical function -- albeit one >>> with a very peculiar domain (pieces of C syntax) -- but it does not act >>> like a C function. Adding ()s will make it look like a C function and >>> that is as likely to look as odd to some as leaving it looking like an >>> operator will look odd to others. >> >> It will also look like a C macro invocation, which are used >> everywhere. > > I don't see what your point is. Deliberately trying not to see it? Just writing an identifier can look like > a macro invocation. Obviously I mean a macro that takes arguments. That's why is usual to recommend that macros be > named in ALL_CAPS. > >> It can also look like a variable declaration: >> >> typedef int F; >> >> F(a); > > What's that got to do with ()s in uses of sizeof? You said that adding () to sizeof will make it look like a function. I pointed out a couple of other constructs in C syntax that also look like functions but aren't. sizeof is just a very odd exception: the only operator that is alphanumeric rather than a symbol, and it's not really a proper operator as it is usually expected to yield a compile-time-value, /and/ it can work on types too. If it wasn't for the quirk that sometimes (either for types or expressions, whichever one it is) parentheses are mandatory, then the language would just have insisted on them and there wouldn't be all this fuss. (FWIW, if someone wants a quick way of getting the length of a static array, then might use a macro like this: #define LEN(a) (sizeof(a)/sizeof(a[0])) but when LEN is invoked, the parentheses are needed!) >> (And I suspect most don't even know >> whether it is types or expressions that don't require the parentheses, >> so add them just in case!) > > Yes, a lot of people do that. Surely the question though is what's the > clearest way to show what's going on? I my view, if you like extra ()s > then use them by try to show that sizeof is not a function. Does that matter so much? It's a device for getting the static size of type or an object or that type (or possibly the dynamic size of a VLA). If it uses function-like syntax, fine. But omitting the brackets as C unwisely allows lets people write things like this example of Torvald's: sizeof(*p)->member -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-12 17:21 +0100 |
| Message-ID | <87eg6yu8s8.fsf@bsb.me.uk> |
| In reply to | #90273 |
BartC <bc@freeuk.com> writes: > On 12/07/2016 13:18, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 12/07/2016 11:24, Ben Bacarisse wrote: >>>> Udyant Wig <udyant.wig@gmail.com> writes: >>> >>>>> But "sizeof()" really *is* a function. It acts exactly like a function >>>>> of it's argument. There is no reason to not treat it that way. Sure, the >>>>> C standard *allows* you to not have parenthesis around an expression >>>>> argument, but you should treat that as the parsing oddity it is, nothing >>>>> more. There is zero reason not to have the parenthesis there. >>>> >>>> No one ever made a splash by being moderate! >>>> >>>> It's true that sizeof acts like a mathematical function -- albeit one >>>> with a very peculiar domain (pieces of C syntax) -- but it does not act >>>> like a C function. Adding ()s will make it look like a C function and >>>> that is as likely to look as odd to some as leaving it looking like an >>>> operator will look odd to others. >>> >>> It will also look like a C macro invocation, which are used >>> everywhere. >> >> I don't see what your point is. > > Deliberately trying not to see it? > > Just writing an identifier can look like >> a macro invocation. > > Obviously I mean a macro that takes arguments. > > That's why is usual to recommend that macros be >> named in ALL_CAPS. >> >>> It can also look like a variable declaration: >>> >>> typedef int F; >>> >>> F(a); >> >> What's that got to do with ()s in uses of sizeof? > > You said that adding () to sizeof will make it look like a function. I > pointed out a couple of other constructs in C syntax that also look > like functions but aren't. Yes, I got that. But surely it wasn't just a random observation was it? Are you suggesting that because some other things look like function calls but are not, there is no reason not to add another one and use the unnecessary ()s? > sizeof is just a very odd exception: the only operator that is > alphanumeric rather than a symbol, and it's not really a proper > operator as it is usually expected to yield a compile-time-value, > /and/ it can work on types too. Right. So I prefer not make it look like something it is not. Keep it looking like the exception it is. > If it wasn't for the quirk that sometimes (either for types or > expressions, whichever one it is) parentheses are mandatory, then the > language would just have insisted on them and there wouldn't be all > this fuss. It could have anyway. It once did for return. But at that early stage the only syntax was sizeof expression so it would have been very odd to require parentheses. > (FWIW, if someone wants a quick way of getting the length of a static > array, then might use a macro like this: > > #define LEN(a) (sizeof(a)/sizeof(a[0])) > > but when LEN is invoked, the parentheses are needed!) One set isn't and you are missing one that is: #define LEN(a) (sizeof (a) / sizeof (a)[0]) (Here there is a general rule that you should always parenthesise macro arguments when the appear in an expression, even if cases where it goes wrong are vanishing rare.) >>> (And I suspect most don't even know >>> whether it is types or expressions that don't require the parentheses, >>> so add them just in case!) >> >> Yes, a lot of people do that. Surely the question though is what's the >> clearest way to show what's going on? I my view, if you like extra ()s >> then use them by try to show that sizeof is not a function. > > Does that matter so much? No, only a little. > It's a device for getting the static size of > type or an object or that type (or possibly the dynamic size of a > VLA). If it uses function-like syntax, fine. But omitting the brackets > as C unwisely allows lets people write things like this example of > Torvald's: > > sizeof(*p)->member That's why sizeof (*p)->member is better. If you like the extra ()s, by all means add them, but I'd still keep the space: sizeof ((*p)->member). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-12 09:35 -0700 |
| Message-ID | <ln7fcqizl9.fsf@kst-u.example.com> |
| In reply to | #90273 |
BartC <bc@freeuk.com> writes:
[...]
> If it wasn't for the quirk that sometimes (either for types or
> expressions, whichever one it is) parentheses are mandatory, then the
> language would just have insisted on them and there wouldn't be all this
> fuss.
It's for expressions that the parentheses are not required.
The operand of the sizeof operator is either a unary-expression
or a parenthesized type name. (You can use parentheses with the
expression, but then they're part of the operand, not part of the
syntax of sizeof.)
You appear to have tremendous difficulty learning things like this,
even after they're explained multiple times. I don't believe you
really have such difficulty. I think you're just pretending for
the sake of making a strawman argument. It's getting old.
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-12 18:08 +0100 |
| Message-ID | <nm387e$ojp$1@dont-email.me> |
| In reply to | #90286 |
On 12/07/2016 17:35, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> If it wasn't for the quirk that sometimes (either for types or >> expressions, whichever one it is) parentheses are mandatory, then the >> language would just have insisted on them and there wouldn't be all this >> fuss. > > It's for expressions that the parentheses are not required. > The operand of the sizeof operator is either a unary-expression > or a parenthesized type name. (You can use parentheses with the > expression, but then they're part of the operand, not part of the > syntax of sizeof.) > > You appear to have tremendous difficulty learning things like this, > even after they're explained multiple times. I don't believe you > really have such difficulty. I think you're just pretending for > the sake of making a strawman argument. It's getting old. No, I genuinely can't remember the special case where sizeof needs parentheses and the special case where it doesn't. I don't want to waste time remembering stuff like that, and I believe that lots of C coders have the same problem. There is a very easy workaround which is to just add parentheses anyway which has the added bonus of being clearer. Are you suggesting that every C programmer ought to know the precedence levels of all ten binary operators? Even the minority that might do so, need to consider the readers of their codes that don't! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-12 18:14 +0100 |
| Message-ID | <nm38ig$pto$1@dont-email.me> |
| In reply to | #90292 |
On 12/07/16 18:08, BartC wrote: > On 12/07/2016 17:35, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >> [...] >>> If it wasn't for the quirk that sometimes (either for types or >>> expressions, whichever one it is) parentheses are mandatory, then the >>> language would just have insisted on them and there wouldn't be all this >>> fuss. >> >> It's for expressions that the parentheses are not required. >> The operand of the sizeof operator is either a unary-expression >> or a parenthesized type name. (You can use parentheses with the >> expression, but then they're part of the operand, not part of the >> syntax of sizeof.) >> >> You appear to have tremendous difficulty learning things like this, >> even after they're explained multiple times. I don't believe you >> really have such difficulty. I think you're just pretending for >> the sake of making a strawman argument. It's getting old. > > No, I genuinely can't remember the special case where sizeof needs > parentheses and the special case where it doesn't. Then assume it /never/ does. In the (generally rare) cases where you're wrong, the compiler will be delighted to correct you. > I don't want to waste time remembering stuff like that, and I believe > that lots of C coders have the same problem. I don't want to waste time remembering stuff like that either, which is why I never bother to use parentheses for sizeof. It's been a very long time since the compiler last objected. > There is a very easy > workaround which is to just add parentheses anyway which has the added > bonus of being clearer. Or just leave them off, which has the added bonus of being clearer. > Are you suggesting that every C programmer ought to know the precedence > levels of all ten binary operators? They darn well ought to (but of course almost none actually do, myself included). > Even the minority that might do so, need to consider the readers of > their codes that don't! Sure, but the best way to consider your reader is to refrain from adding code that does nothing good and stops nothing bad happening. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-18 10:01 -0700 |
| Message-ID | <kfneg6qyj72.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90292 |
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.)
[toc] | [prev] | [next] | [standalone]
Page 6 of 18 — ← Prev page 1 … 4 5 [6] 7 8 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web