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 5 of 18 — ← Prev page 1 … 3 4 [5] 6 7 … 18 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-12 01:16 -0700 |
| Message-ID | <a1624186-397d-4a10-bc52-12c8f6f9ddcc@googlegroups.com> |
| In reply to | #90253 |
On Tuesday, July 12, 2016 at 8:57:28 AM UTC+1, Richard Heathfield wrote: > Yes, there is a convention for the precedence of sizeof (and it /is/ > only a convention, since the Standard doesn't even mention precedence as > far as I can recall), and it's this: sizeof associates left to right > with () [] and -> and precedes everything else. > A convention isn't the same thing as a rule. Conventionally, in a debate remarks are address to the chairman. Now most debating societies follow that convention, and so, in the context of the debate, it's a "rule". Speaker must address the chair. However some debating societies don't follow that convention. It's a human thing, not a law of nature. Speaker might introduce his remarks "ladies and gentlemen", addressing the floor. That could be the rule of that particular society. If there's more than one or two societies which do that, then of course it becomes an alternative convention. There was no convention for sizeof when Ritchie introduced it, as far as I'm aware. It was a C special. There was a convention for the mathematical operators (BODMAS), which Ritchie followed. There is a convention for function syntax. It would have been better all round had that been used.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-12 09:27 +0100 |
| Message-ID | <nm29mc$811$3@dont-email.me> |
| In reply to | #90254 |
On 12/07/16 09:16, Malcolm McLean wrote: > On Tuesday, July 12, 2016 at 8:57:28 AM UTC+1, Richard Heathfield wrote: > >> Yes, there is a convention for the precedence of sizeof (and it /is/ >> only a convention, since the Standard doesn't even mention precedence as >> far as I can recall), and it's this: sizeof associates left to right >> with () [] and -> and precedes everything else. >> > A convention isn't the same thing as a rule. That's right. The rule is grammatical in nature, and doesn't involve precedence by that name. -- 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:48 +0100 |
| Message-ID | <8760sb169v.fsf@bsb.me.uk> |
| In reply to | #90253 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 12/07/16 08:41, Malcolm McLean wrote: <snip> >> sizeof is an operator, therefore it has precedence. >> But there is no convention for the precedence of the sizeof operator, There is. It is, to a first approximation, a unary prefix operator and these, conventionally, have very high precedence. All of C's unary prefix operators have the same high precedence so it follows both the convention within the language as well as that from other languages. > Yes, there is a convention for the precedence of sizeof (and it /is/ > only a convention, since the Standard doesn't even mention precedence > as far as I can recall), and it's this: sizeof associates left to > right with () [] and -> and precedes everything else. That's, at best, confusing. Unary operators are not usually though of as having associativity and even then the term only applies when operators have the same precedence, and sizeof does not have the same precedence as (), [] and ->. The syntax given for C implies a precedence and sizeof (along with all the other unary prefix operators) and it comes just below that of the postfix operators. As you say, these are really just implied rules, but they do give a simple way to talk about how expressions are parsed (despite the problem that long threads can ensue when [], ., -> and () are called operators!). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-12 08:46 +0100 |
| Message-ID | <nm278j$2ke$1@dont-email.me> |
| In reply to | #90247 |
On 12/07/16 06:34, Malcolm McLean wrote: > On Tuesday, July 12, 2016 at 5:56:30 AM UTC+1, Udyant Wig wrote: >> On 07/12/2016 03:50 AM, BartC wrote: >> >> 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. >> > Yes, it's undesireable that C's syntax permits sizeof without the > parentheses. No, it isn't, any more than it's undesirable that C's syntax permits addition without the parentheses. > If we see something like sizeof *x * N does that mean > sizeof(*x) *N or sizeof(*x *N)? It means N times the size of the object pointed to by x. > You can of course tell people, but the parentheses make more sense. N * sizeof *x is clearer still. > Then whilst sizeof isn't a subroutine and can't be implemented as > a subroutine, it is a function, and conventional function syntax > makes sense. It isn't a function, and conventional function syntax doesn't make sense because functions can't take type names as parameters, which sizeof has to be able to do if it's to make spec. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-12 10:42 +0200 |
| Message-ID | <nm2agu$c70$1@dont-email.me> |
| In reply to | #90252 |
On 12/07/16 09:46, Richard Heathfield wrote: > On 12/07/16 06:34, Malcolm McLean wrote: >> On Tuesday, July 12, 2016 at 5:56:30 AM UTC+1, Udyant Wig wrote: >>> On 07/12/2016 03:50 AM, BartC wrote: >>> >>> 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. >>> >> Yes, it's undesireable that C's syntax permits sizeof without the >> parentheses. > > No, it isn't, any more than it's undesirable that C's syntax permits > addition without the parentheses. > >> If we see something like sizeof *x * N does that mean >> sizeof(*x) *N or sizeof(*x *N)? > > It means N times the size of the object pointed to by x. > >> You can of course tell people, but the parentheses make more sense. > > N * sizeof *x is clearer still. Agreed. But "N * sizeof(*x)" is even clearer - IMHO. > >> Then whilst sizeof isn't a subroutine and can't be implemented as >> a subroutine, it is a function, and conventional function syntax >> makes sense. > > It isn't a function, and conventional function syntax doesn't make sense > because functions can't take type names as parameters, which sizeof has > to be able to do if it's to make spec. > sizeof is not a function - it is an operator. But it is an odd sort of operator - it does not look like or work like other operators, such as "+" or "--". It looks more like a function than another operator. And while sizeof can take a type as its operand, ironically in that usage you /must/ use parenthesis - you have to write "sizeof(int)" rather than "sizeof int". It seems to me that it is clearer, simpler and more consistent, as well as avoiding possible confusion, if you simply always use parenthesis for the operand of sizeof. For non-type operands, a key difference between sizeof and a function call that returned the size of its argument type is that the function call will evaluate the argument for side-effects, while the sizeof operator will not. But if that is likely to cause confusion, then (IMHO, as always) the code is already confusing - just don't use sizeof on expressions with side-effects. "sizeof(x++)" is asking for trouble (in the minds of the reader - the compiler will be happy), whether or not you have the parenthesis.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-12 09:59 +0100 |
| Message-ID | <nm2bi8$f8d$1@dont-email.me> |
| In reply to | #90256 |
On 12/07/16 09:42, David Brown wrote: > On 12/07/16 09:46, Richard Heathfield wrote: >> On 12/07/16 06:34, Malcolm McLean wrote: >>> On Tuesday, July 12, 2016 at 5:56:30 AM UTC+1, Udyant Wig wrote: >>>> On 07/12/2016 03:50 AM, BartC wrote: >>>> >>>> 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. >>>> >>> Yes, it's undesireable that C's syntax permits sizeof without the >>> parentheses. >> >> No, it isn't, any more than it's undesirable that C's syntax permits >> addition without the parentheses. >> >>> If we see something like sizeof *x * N does that mean >>> sizeof(*x) *N or sizeof(*x *N)? >> >> It means N times the size of the object pointed to by x. >> >>> You can of course tell people, but the parentheses make more sense. >> >> N * sizeof *x is clearer still. > > Agreed. > > But "N * sizeof(*x)" is even clearer - IMHO. But David, that's a /string/! :-) Seriously, what makes you think the parentheses add clarity? >>> Then whilst sizeof isn't a subroutine and can't be implemented as >>> a subroutine, it is a function, and conventional function syntax >>> makes sense. >> >> It isn't a function, and conventional function syntax doesn't make sense >> because functions can't take type names as parameters, which sizeof has >> to be able to do if it's to make spec. >> > > sizeof is not a function - it is an operator. But it is an odd sort of > operator - it does not look like or work like other operators, such as > "+" or "--". It looks more like a function than another operator. Only because you add parentheses, thus muddying the waters. Take them away, and it looks no different to ++ or <<= - that is, it's a sequence of one or more non-space characters. Those characters happen to be alphabetic, but that's a minor detail. > And > while sizeof can take a type as its operand, ironically in that usage > you /must/ use parenthesis - you have to write "sizeof(int)" rather than > "sizeof int". Yes, but it turns out not to matter, since it is almost always preferable to take the size of an object rather than that of a type. > It seems to me that it is clearer, simpler and more consistent, as well > as avoiding possible confusion, if you simply always use parenthesis for > the operand of sizeof. Or just avoid taking the size of types except when you really have no choice, which is hardly ever. > For non-type operands, a key difference between sizeof and a function > call that returned the size of its argument type is that the function > call will evaluate the argument for side-effects, while the sizeof > operator will not. And that's a difference worth pointing up by using operator syntax rather than pseudo-function syntax. > But if that is likely to cause confusion, then > (IMHO, as always) the code is already confusing - just don't use sizeof > on expressions with side-effects. "sizeof(x++)" is asking for trouble > (in the minds of the reader - the compiler will be happy), whether or > not you have the parenthesis. On that, at least, we can agree. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-12 12:46 +0200 |
| Message-ID | <nm2hpt$49j$1@dont-email.me> |
| In reply to | #90258 |
On 12/07/16 10:59, Richard Heathfield wrote:
> On 12/07/16 09:42, David Brown wrote:
>> On 12/07/16 09:46, Richard Heathfield wrote:
>>> On 12/07/16 06:34, Malcolm McLean wrote:
>>>> On Tuesday, July 12, 2016 at 5:56:30 AM UTC+1, Udyant Wig wrote:
>>>>> On 07/12/2016 03:50 AM, BartC wrote:
>>>>>
>>>>> 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.
>>>>>
>>>> Yes, it's undesireable that C's syntax permits sizeof without the
>>>> parentheses.
>>>
>>> No, it isn't, any more than it's undesirable that C's syntax permits
>>> addition without the parentheses.
>>>
>>>> If we see something like sizeof *x * N does that mean
>>>> sizeof(*x) *N or sizeof(*x *N)?
>>>
>>> It means N times the size of the object pointed to by x.
>>>
>>>> You can of course tell people, but the parentheses make more sense.
>>>
>>> N * sizeof *x is clearer still.
>>
>> Agreed.
>>
>> But "N * sizeof(*x)" is even clearer - IMHO.
>
> But David, that's a /string/! :-)
>
> Seriously, what makes you think the parentheses add clarity?
I think it makes it clearer that you are taking a particular operation,
"sizeof", and applying it to the thing inside the brackets.
I will happily admit that this is a matter of personal taste or
preference (hence the "IMHO") - unfortunately that also makes it
difficult to explain. But it feels "natural" to have parenthesis here.
On the other hand, in some places where C insists on parenthesis, such
as "if (x)", the parenthesis feel unnecessary.
But I don't see it as a big issue. I consistently use the parenthesis
for sizeof in my own code, but I won't complain about missing
parenthesis in other people's code (in the way that I /would/ complain
about "int* p, q;", for example).
>
>>>> Then whilst sizeof isn't a subroutine and can't be implemented as
>>>> a subroutine, it is a function, and conventional function syntax
>>>> makes sense.
>>>
>>> It isn't a function, and conventional function syntax doesn't make sense
>>> because functions can't take type names as parameters, which sizeof has
>>> to be able to do if it's to make spec.
>>>
>>
>> sizeof is not a function - it is an operator. But it is an odd sort of
>> operator - it does not look like or work like other operators, such as
>> "+" or "--". It looks more like a function than another operator.
>
> Only because you add parentheses, thus muddying the waters. Take them
> away, and it looks no different to ++ or <<= - that is, it's a sequence
> of one or more non-space characters. Those characters happen to be
> alphabetic, but that's a minor detail.
It is a major detail to the human brain. I am not sure that this is the
only reason why it makes a difference when reading and mentally parsing
sizeof code, but I do think it is significant.
>
>> And
>> while sizeof can take a type as its operand, ironically in that usage
>> you /must/ use parenthesis - you have to write "sizeof(int)" rather than
>> "sizeof int".
>
> Yes, but it turns out not to matter, since it is almost always
> preferable to take the size of an object rather than that of a type.
>
It turns out that I use sizeof a good deal on types. In particular, I
regularly want to check that the size of a structure of some sort
matches the expected size, because the structure is modelling hardware
registers, a communication block, or something else that has to have a
fixed format. So I will have code like this:
typedef struct {
uint32_t header;
uint16_t data[6];
} sampleBlock_t;
static_assert(sizeof(sampleBlock_t) == 16,
"Bad size for sampleBlock_t");
The check here, and therefore the sizeof, is at the earliest spot in the
code, as soon as the type is defined, long before the type is used.
But maybe that's just an oddity in the type of code I write, or the way
I write my code - I am generous in my typedef'ing and my static_assert'ing.
Most other uses of sizeof in my code are for objects rather than types,
but I don't have a particular objection or dislike for applying it to
types. I usually know exactly what types my objects are, and don't
change them much, so I would pick whatever is most convenient and best
indicates the purpose of the code.
>> It seems to me that it is clearer, simpler and more consistent, as well
>> as avoiding possible confusion, if you simply always use parenthesis for
>> the operand of sizeof.
>
> Or just avoid taking the size of types except when you really have no
> choice, which is hardly ever.
>
>> For non-type operands, a key difference between sizeof and a function
>> call that returned the size of its argument type is that the function
>> call will evaluate the argument for side-effects, while the sizeof
>> operator will not.
>
> And that's a difference worth pointing up by using operator syntax
> rather than pseudo-function syntax.
Not really (see below).
>
>> But if that is likely to cause confusion, then
>> (IMHO, as always) the code is already confusing - just don't use sizeof
>> on expressions with side-effects. "sizeof(x++)" is asking for trouble
>> (in the minds of the reader - the compiler will be happy), whether or
>> not you have the parenthesis.
>
> On that, at least, we can agree.
>
We probably agree on a great many things - but there is no fun in
discussing them!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-12 09:08 -0700 |
| Message-ID | <lnshvej0uh.fsf@kst-u.example.com> |
| In reply to | #90262 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> I think it makes it clearer that you are taking a particular operation,
> "sizeof", and applying it to the thing inside the brackets.
Do you use parentheses on a return statement with an expression?
`return expr;` is a statement, not an expression, but I think the
same considerations apply.
Writing `sizeof(n)` rather than `sizeof n` makes it look too much
like a function call, which it isn't.
Writing `return(n);` rather than `return n;` makes it look too much
like a function call, which it isn't.
Both sizeof and return are keywords, not ordinary identifiers. For C or
just about any other language, I find it easier to read and understand
code if I think of keywords as distinct syntactic entities, not as
identifiers.
Given these symbols:
foo
sizeof
&
I personally find `sizeof` more similar to `&` than to `foo`, because
`sizeof` and `&` are both special symbols whose meaning is defined by
the language, while `foo` is an identifier whose meaning is defined by
an explicit declaration.
> I will happily admit that this is a matter of personal taste or
> preference (hence the "IMHO") - unfortunately that also makes it
> difficult to explain. But it feels "natural" to have parenthesis here.
> On the other hand, in some places where C insists on parenthesis, such
> as "if (x)", the parenthesis feel unnecessary.
Actually the parentheses are necessary in that case to avoid ambiguity.
If the grammar required `{` and `}`, they wouldn't be. But in C, you need
to distinguish between
if (x) -1;
and
if x-1;
(There are probably more realistic examples.)
In most languages, you have to have something to delimit the end of the
condition in an if statement. C-like languages use parentheses; some
other languages use a `then` keyword or an end-of-line.
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-12 18:51 +0200 |
| Message-ID | <nm376o$k6h$1@dont-email.me> |
| In reply to | #90276 |
On 12/07/16 18:08, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> I think it makes it clearer that you are taking a particular operation,
>> "sizeof", and applying it to the thing inside the brackets.
>
> Do you use parentheses on a return statement with an expression?
No.
>
> `return expr;` is a statement, not an expression, but I think the
> same considerations apply.
I don't see it as being the same (although I know that some people do).
"return" is a statement - it is significantly different from either
function calls or using an operand like sizeof.
>
> Writing `sizeof(n)` rather than `sizeof n` makes it look too much
> like a function call, which it isn't.
"if (x)" is not a function call either, but it has brackets. (I always
have a space after if, while, do, etc., but some people don't.)
"sizeof(int)" is not a function call, but it needs the brackets.
>
> Writing `return(n);` rather than `return n;` makes it look too much
> like a function call, which it isn't.
I don't use brackets for return statements.
>
> Both sizeof and return are keywords, not ordinary identifiers. For C or
> just about any other language, I find it easier to read and understand
> code if I think of keywords as distinct syntactic entities, not as
> identifiers.
Agreed.
But there are only a limited number of ways you can write code in
distinguishable ways. I feel that the use of sizeof is not dissimilar
to some uses of function calls, and thus it writing it in a similar
manner makes sense.
>
> Given these symbols:
> foo
> sizeof
> &
> I personally find `sizeof` more similar to `&` than to `foo`, because
> `sizeof` and `&` are both special symbols whose meaning is defined by
> the language, while `foo` is an identifier whose meaning is defined by
> an explicit declaration.
I agree, when considering the symbols themselves. But considering their
usage, I think sizeof is more like a function. It's just a matter of
perspective.
>
>> I will happily admit that this is a matter of personal taste or
>> preference (hence the "IMHO") - unfortunately that also makes it
>> difficult to explain. But it feels "natural" to have parenthesis here.
>> On the other hand, in some places where C insists on parenthesis, such
>> as "if (x)", the parenthesis feel unnecessary.
>
> Actually the parentheses are necessary in that case to avoid ambiguity.
> If the grammar required `{` and `}`, they wouldn't be. But in C, you need
> to distinguish between
> if (x) -1;
> and
> if x-1;
> (There are probably more realistic examples.)
I'd vote to make the parenthesis optional, and the brackets mandatory -
but I suspect the C standards committee will not be moved on this issue :-(
>
> In most languages, you have to have something to delimit the end of the
> condition in an if statement. C-like languages use parentheses; some
> other languages use a `then` keyword or an end-of-line.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-12 11:28 -0700 |
| Message-ID | <lny456hfse.fsf@kst-u.example.com> |
| In reply to | #90289 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> But there are only a limited number of ways you can write code in
> distinguishable ways. I feel that the use of sizeof is not dissimilar
> to some uses of function calls, and thus it writing it in a similar
> manner makes sense.
[...]
The use of sizeof is visually not dissimilar to some uses of function
calls, but because sizeof is semantically very different, writing it in
a distinct manner makes sense.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-12 19:53 +0100 |
| Message-ID | <8737neu1rm.fsf@bsb.me.uk> |
| In reply to | #90289 |
David Brown <david.brown@hesbynett.no> writes:
> On 12/07/16 18:08, Keith Thompson wrote:
<snip>
>> Actually the parentheses are necessary in that case to avoid ambiguity.
>> If the grammar required `{` and `}`, they wouldn't be. But in C, you need
>> to distinguish between
>> if (x) -1;
>> and
>> if x-1;
>> (There are probably more realistic examples.)
>
> I'd vote to make the parenthesis optional, and the brackets mandatory -
> but I suspect the C standards committee will not be moved on this
> issue :-(
That's the way Go went. Interesting, since one of the designers was Ken
Thompson who's if () ... syntax from B went over into C. And lot's of
people have since copied the keyword () syntax.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-12 12:19 -0700 |
| Message-ID | <24cbec48-21e3-41c9-acf5-35315c26b482@googlegroups.com> |
| In reply to | #90276 |
On Tuesday, July 12, 2016 at 11:08:35 AM UTC-5, Keith Thompson wrote:
> Actually the parentheses are necessary in that case to avoid ambiguity.
> If the grammar required `{` and `}`, they wouldn't be. But in C, you need
> to distinguish between
> if (x) -1;
> and
> if x-1;
> (There are probably more realistic examples.)
Parentheses may be necessary for general expressions, but the syntax could
helpfully have allowed, without ambiguity, "if !(x) statement;" as an
allowable form for cases where one wants a cascaded if/else chain which
acts upon the first false condition.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-12 14:26 -0700 |
| Message-ID | <lnpoqih7j7.fsf@kst-u.example.com> |
| In reply to | #90300 |
supercat@casperkitty.com writes:
> On Tuesday, July 12, 2016 at 11:08:35 AM UTC-5, Keith Thompson wrote:
>> Actually the parentheses are necessary in that case to avoid ambiguity.
>> If the grammar required `{` and `}`, they wouldn't be. But in C, you need
>> to distinguish between
>> if (x) -1;
>> and
>> if x-1;
>> (There are probably more realistic examples.)
>
> Parentheses may be necessary for general expressions, but the syntax could
> helpfully have allowed, without ambiguity, "if !(x) statement;" as an
> allowable form for cases where one wants a cascaded if/else chain which
> acts upon the first false condition.
There are a lot of special cases that could have been added. I don't
agree that that particular one would have been worth the complexity.
`if (!(x)) statement;` (or `if (!x) statement;` if x happens to be
a cast-expression) isn't much of a burden.
On the [off-]topic of other languages, Perl 5 requires parentheses on
conditions and braces on controlled statements:
if (cond) {
statement;
}
while Perl 6 doesn't require the parentheses:
if cond {
statement;
}
(My guess is that Larry Wall realized the required braces make the
parentheses redundant.)
--
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 | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2016-07-12 11:00 -0400 |
| Message-ID | <nm30n3$qga$1@dont-email.me> |
| In reply to | #90252 |
On 7/12/2016 3:46 AM, Richard Heathfield wrote: > On 12/07/16 06:34, Malcolm McLean wrote: [...] >> Then whilst sizeof isn't a subroutine and can't be implemented as >> a subroutine, it is a function, and conventional function syntax >> makes sense. > > It isn't a function, and conventional function syntax doesn't make sense > because functions can't take type names as parameters, which sizeof has to > be able to do if it's to make spec. I think he's saying it's a "function" in the sense that "you pass it a parameter -- a type or an expression -- and it 'returns' a value". That may make sense at first glance, but you wouldn't say the same thing for the unary "*" operator -- that it gets "passed a parameter -- a pointer -- and it 'returns' what that pointer points to". Of course, if you want to write it as "*(pointer)", you're welcome to do so. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-12 16:18 +0100 |
| Message-ID | <nm31oi$uhe$1@dont-email.me> |
| In reply to | #90270 |
On 12/07/16 16:00, Ken Brody wrote: > On 7/12/2016 3:46 AM, Richard Heathfield wrote: >> On 12/07/16 06:34, Malcolm McLean wrote: > [...] >>> Then whilst sizeof isn't a subroutine and can't be implemented as >>> a subroutine, it is a function, and conventional function syntax >>> makes sense. >> >> It isn't a function, and conventional function syntax doesn't make sense >> because functions can't take type names as parameters, which sizeof >> has to >> be able to do if it's to make spec. > > I think he's saying it's a "function" in the sense that "you pass it a > parameter -- a type or an expression -- and it 'returns' a value". In that case, here are some more functions: + - * / % ++ -- << >> except that they aren't functions in the C sense of the word (which is the sense that's relevant here in comp.lang.c). And neither is sizeof. They take operands, not parameters. And they don't return values. They yield values. But apart from being 100% wrong, he's exactly right. > That > may make sense at first glance, but you wouldn't say the same thing for > the unary "*" operator -- that it gets "passed a parameter -- a pointer > -- and it 'returns' what that pointer points to". Of course, if you > want to write it as "*(pointer)", you're welcome to do so. Thanks! :-) (But no, thanks.) -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-12 08:44 -0700 |
| Message-ID | <lnwpkqj1yq.fsf@kst-u.example.com> |
| In reply to | #90247 |
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?
There are three minor syntactic differences:
- There's a second form, `sizeof ( type-name )`, where the operand is
not an expression. (I wouldn't have called it a "unary operator"
in that form, but I accept the standard's terminology);
- sizeof takes a unary-expression rather than a cast-expression
(to avoid ambiguity with the `sizeof ( type-name )` form); and
- sizeof happens to be a keyword rather than a punctuation symbol.
None of those, in my opinion, justifies pretending that sizeof is
a function rather than an operator, or using unnecessary parentheses.
I have no problem using `sizeof ( expression )` when the parentheses
are necessary to avoid syntactic or visual ambiguity. But those
are grouping parentheses, not like the parentheses used in a
function call.
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?
--
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-12 09:24 -0700 |
| Message-ID | <8ba2b99f-4afe-42ce-9789-1c3c1792a5b2@googlegroups.com> |
| In reply to | #90274 |
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. 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) If you use a name rather than symbol, then it makes sense to use the same syntax as other functions. Especially if you use names as variables as well. It keeps things visually distinct.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-12 17:34 +0100 |
| Message-ID | <878tx6u86k.fsf@bsb.me.uk> |
| In reply to | #90279 |
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. > 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) > > If you use a name rather than symbol, then it makes sense to use the > same syntax as other functions. Especially if you use names as variables > as well. It keeps things visually distinct. That seems backwards to me. Those people arguing for extra spaces or no extra parentheses or both are doing so precisely to keep things visually distinct. Making an operator (one that is particularly un-function like) look like a function is not keeping things visually distinct. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-12 09:52 -0700 |
| Message-ID | <16c94544-c68a-49fe-a8f8-787ea14edd2d@googlegroups.com> |
| In reply to | #90285 |
On Tuesday, July 12, 2016 at 5:34:36 PM UTC+1, Ben Bacarisse wrote: > > That seems backwards to me. Those people arguing for extra spaces or no > extra parentheses or both are doing so precisely to keep things visually > distinct. Making an operator (one that is particularly un-function > like) look like a function is not keeping things visually distinct. > There's a point at which highlighting becomes counter-productive. You can highlight important points in yellow and dubious material in green. But if you then decide that quotations need to be highlighted in blue and section headers in orange, it starts to detract from the other highlights. sizeof is logically a function, that's going to tend to be embedded in expressions. We don't need to keep it distinct from other functions which happen to be subroutines or macros. However we don't want it mixed up with identifiers size * N and sizeof * N mean different things, but you'll often see both in non-contrived code. In sizeof(N) * abs(N) both halves essentially mean the same thing - take two values associated with N. The name gives you the details - its size in memory or its absolute value.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-12 09:40 -0700 |
| Message-ID | <ln37neizd6.fsf@kst-u.example.com> |
| In reply to | #90279 |
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.
> If you use a name rather than symbol, then it makes sense to use the
> same syntax as other functions. Especially if you use names as variables
> as well. It keeps things visually distinct.
`sizeof` is a keyword. Apart from a superficial visual resemblance,
it's more similar to operator symbols than to identifiers.
--
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]
Page 5 of 18 — ← Prev page 1 … 3 4 [5] 6 7 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web