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 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-11 04:07 -0700 |
| Message-ID | <481f30b4-acb3-4445-92b3-c403dc3e51f7@googlegroups.com> |
| In reply to | #90197 |
On Monday, July 11, 2016 at 12:01:28 PM UTC+1, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > > > int* array = (int*) malloc(10 * sizeof(int)); > Comprehensible. malloc 10 times the size of an int. > > int *array = malloc(10 * sizeof *array); > Gibberish. malloc ten times sizeof times array? Ten times the size of the array? Code like that is a potential source of error and confusion.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-11 12:17 +0100 |
| Message-ID | <nlvv8j$qcs$1@dont-email.me> |
| In reply to | #90199 |
On 11/07/16 12:07, Malcolm McLean wrote: > On Monday, July 11, 2016 at 12:01:28 PM UTC+1, Richard Bos wrote: >> David Brown <david.brown@hesbynett.no> wrote: >> >>> int* array = (int*) malloc(10 * sizeof(int)); >> > Comprehensible. malloc 10 times the size of an int. >> >> int *array = malloc(10 * sizeof *array); >> > Gibberish. No, it's not gibberish. It's idiomatic. > malloc ten times sizeof times array? Ten times the size of the array? No, malloc ten elements, each of size *array. Note the *. > Code like that is a potential source of error and confusion. /All/ code is a potential source of error and confusion, but that isn't always the fault of the code. The T *p = malloc(n * sizeof *p) idiom is well-established in C, and it works well, which is /why/ it's well-established. It is so common, and so well-constructed, that it would be a really good idea for all C programmers to get the hang of it. It's not difficult. -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-11 04:59 -0700 |
| Message-ID | <d488ce9f-4bc2-40a2-8ba9-7912d08bf368@googlegroups.com> |
| In reply to | #90200 |
On Monday, July 11, 2016 at 12:17:47 PM UTC+1, Richard Heathfield wrote: > On 11/07/16 12:07, Malcolm McLean wrote: > > The T *p = malloc(n * sizeof *p) idiom is well-established in C, and it > works well, which is /why/ it's well-established. It is so common, and > so well-constructed, that it would be a really good idea for all C > programmers to get the hang of it. It's not difficult. > I've rarely seen it. It's the sort of thing that gives C a bad name - cryptic, hard to interpret symbols, with two apparently syntactically identical asterisks in fact having unrelated meanings, and the one of the left hand side of the equals sign having a related but different meaning.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-11 13:07 +0100 |
| Message-ID | <nm0266$5tu$1@dont-email.me> |
| In reply to | #90201 |
On 11/07/16 12:59, Malcolm McLean wrote: > On Monday, July 11, 2016 at 12:17:47 PM UTC+1, Richard Heathfield wrote: >> On 11/07/16 12:07, Malcolm McLean wrote: >> >> The T *p = malloc(n * sizeof *p) idiom is well-established in C, and it >> works well, which is /why/ it's well-established. It is so common, and >> so well-constructed, that it would be a really good idea for all C >> programmers to get the hang of it. It's not difficult. >> > I've rarely seen it. Surely you've seen it a thousand times in clc? > It's the sort of thing that gives C a bad name - cryptic, hard to interpret > symbols, with two apparently syntactically identical asterisks in fact > having unrelated meanings, and the one of the left hand side of the equals > sign having a related but different meaning. I don't find it cryptic. Nor do I find that * is hard to interpret. If you find the use of * in two different ways confusing, how do you cope with ordinary C code such as: a = b * *p ? -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-11 13:38 +0100 |
| Message-ID | <nm03vc$c83$1@dont-email.me> |
| In reply to | #90202 |
On 11/07/2016 13:07, Richard Heathfield wrote: > On 11/07/16 12:59, Malcolm McLean wrote: >> On Monday, July 11, 2016 at 12:17:47 PM UTC+1, Richard Heathfield wrote: >>> On 11/07/16 12:07, Malcolm McLean wrote: >>> >>> The T *p = malloc(n * sizeof *p) idiom is well-established in C, and it >>> works well, which is /why/ it's well-established. It is so common, and >>> so well-constructed, that it would be a really good idea for all C >>> programmers to get the hang of it. It's not difficult. >>> >> I've rarely seen it. > > Surely you've seen it a thousand times in clc? > >> It's the sort of thing that gives C a bad name - cryptic, hard to >> interpret >> symbols, with two apparently syntactically identical asterisks in fact >> having unrelated meanings, and the one of the left hand side of the >> equals >> sign having a related but different meaning. > > I don't find it cryptic. Nor do I find that * is hard to interpret. If > you find the use of * in two different ways confusing, how do you cope > with ordinary C code such as: a = b * *p ? The use of "*" here is unfortunate. But the way around it is to always follow 'sizeof' with parentheses so that a following * can't be a multiply. One problem is that when parsing name*name*name, before those names have been looked up, then it does look just like three things multiplied together. The same thing happens when a reader quickly glances at a bit of code, and sees the 'shape' of the code before it processes the names. Using "*" for dereference also gives rise to this: b * * * * p where the first * is multiply, and the other three are dereference. That's very poor design I think, especially since this can also mean that you're declaring p as a pointer to pointer to pointer to pointer to type b! 2/10. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-11 14:11 +0100 |
| Message-ID | <nm05tf$ihb$1@dont-email.me> |
| In reply to | #90205 |
On 11/07/16 13:38, BartC wrote: > On 11/07/2016 13:07, Richard Heathfield wrote: >> On 11/07/16 12:59, Malcolm McLean wrote: >>> On Monday, July 11, 2016 at 12:17:47 PM UTC+1, Richard Heathfield wrote: >>>> On 11/07/16 12:07, Malcolm McLean wrote: >>>> >>>> The T *p = malloc(n * sizeof *p) idiom is well-established in C, and it >>>> works well, which is /why/ it's well-established. It is so common, and >>>> so well-constructed, that it would be a really good idea for all C >>>> programmers to get the hang of it. It's not difficult. >>>> >>> I've rarely seen it. >> >> Surely you've seen it a thousand times in clc? >> >>> It's the sort of thing that gives C a bad name - cryptic, hard to >>> interpret >>> symbols, with two apparently syntactically identical asterisks in fact >>> having unrelated meanings, and the one of the left hand side of the >>> equals >>> sign having a related but different meaning. >> >> I don't find it cryptic. Nor do I find that * is hard to interpret. If >> you find the use of * in two different ways confusing, how do you cope >> with ordinary C code such as: a = b * *p ? > > The use of "*" here is unfortunate. I don't see why. > But the way around it is to always There's nothing to get around. > follow 'sizeof' with parentheses so that a following * can't be a multiply. Why add spurious parentheses? The * that follows sizeof can /never/ be a multiplication symbol, because sizeof is not a valid operand for multiplication. The /result/ that sizeof yields can be, but sizeof itself is a keyword, not a value. <sorry, BartC, but the rest is just nonsense, so I've snipped it> -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-11 18:54 +0100 |
| Message-ID | <nm0mgp$jmb$1@dont-email.me> |
| In reply to | #90208 |
On 11/07/2016 14:11, Richard Heathfield wrote: > On 11/07/16 13:38, BartC wrote: >> But the way around it is to always > > There's nothing to get around. > >> follow 'sizeof' with parentheses so that a following * can't be a >> multiply. > > Why add spurious parentheses? The * that follows sizeof can /never/ be a > multiplication symbol, because sizeof is not a valid operand for > multiplication. The /result/ that sizeof yields can be, but sizeof > itself is a keyword, not a value. Spot the line with only one multiply in it rather than two: array = malloc(seoizf*soeizf*seiozf); array = malloc(sizoef*siozef*szoief); array = malloc(siozef*szoeif*soezif); array = malloc(szeiof*szioef*sezoif); array = malloc(szeiof*soeizf*szoief); array = malloc(sezoif*szeoif*seiozf); array = malloc(szeiof*szeiof*sioezf); array = malloc(szeiof*szoief*seziof); array = malloc(szoeif*szoief*sieozf); array = malloc(soiezf*sozief*soiezf); array = malloc(sieozf*seziof*soiezf); array = malloc(sioezf*soezif*szeiof); array = malloc(seziof*sozief*seoizf); array = malloc(seozif*siozef*siezof); array = malloc(soezif*sioezf*siozef); array = malloc(szeiof*sizeof*siozef); array = malloc(szeoif*soiezf*sizoef); array = malloc(sozief*soizef*sozeif); array = malloc(sieozf*sizoef*sizoef); array = malloc(szeoif*seizof*sozeif); This is the kind of problem I mean. The syntax for sizeof operating on an expression such as *x isn't distinct enough from a normal multiply. That's I suggested putting in parentheses: array = malloc(seoizf*soeizf*seiozf); array = malloc(sizoef*siozef*szoief); array = malloc(siozef*szoeif*soezif); array = malloc(szeiof*szioef*sezoif); array = malloc(szeiof*soeizf*szoief); array = malloc(sezoif*szeoif*seiozf); array = malloc(szeiof*szeiof*sioezf); array = malloc(szeiof*szoief*seziof); array = malloc(szoeif*szoief*sieozf); array = malloc(soiezf*sozief*soiezf); array = malloc(sieozf*seziof*soiezf); array = malloc(sioezf*soezif*szeiof); array = malloc(seziof*sozief*seoizf); array = malloc(seozif*siozef*siezof); array = malloc(soezif*sioezf*siozef); array = malloc(szeiof*sizeof(*siozef)); array = malloc(szeoif*soiezf*sizoef); array = malloc(sozief*soizef*sozeif); array = malloc(sieozf*sizoef*sizoef); array = malloc(szeoif*seizof*sozeif); The * in "...of(*xyz..." can never mean multiply, but in ...of(*xyz..." it could. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-11 11:09 -0700 |
| Message-ID | <lntwfwjbc4.fsf@kst-u.example.com> |
| In reply to | #90217 |
BartC <bc@freeuk.com> writes:
> On 11/07/2016 14:11, Richard Heathfield wrote:
>> On 11/07/16 13:38, BartC wrote:
>>> But the way around it is to always
>>
>> There's nothing to get around.
>>
>>> follow 'sizeof' with parentheses so that a following * can't be a
>>> multiply.
>>
>> Why add spurious parentheses? The * that follows sizeof can /never/ be a
>> multiplication symbol, because sizeof is not a valid operand for
>> multiplication. The /result/ that sizeof yields can be, but sizeof
>> itself is a keyword, not a value.
>
> Spot the line with only one multiply in it rather than two:
>
> array = malloc(seoizf*soeizf*seiozf);
> array = malloc(sizoef*siozef*szoief);
> array = malloc(siozef*szoeif*soezif);
> array = malloc(szeiof*szioef*sezoif);
> array = malloc(szeiof*soeizf*szoief);
> array = malloc(sezoif*szeoif*seiozf);
> array = malloc(szeiof*szeiof*sioezf);
> array = malloc(szeiof*szoief*seziof);
> array = malloc(szoeif*szoief*sieozf);
> array = malloc(soiezf*sozief*soiezf);
> array = malloc(sieozf*seziof*soiezf);
> array = malloc(sioezf*soezif*szeiof);
> array = malloc(seziof*sozief*seoizf);
> array = malloc(seozif*siozef*siezof);
> array = malloc(soezif*sioezf*siozef);
> array = malloc(szeiof*sizeof*siozef);
> array = malloc(szeoif*soiezf*sizoef);
> array = malloc(sozief*soizef*sozeif);
> array = malloc(sieozf*sizoef*sizoef);
> array = malloc(szeoif*seizof*sozeif);
No.
That's a problem that's solved by not using identifiers that look
like misspellings of a keyword, and by reasonable use of white space
within expressions. Show me something like that in real-world code,
then we can talk.
https://en.wikipedia.org/wiki/Straw_man
[...]
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-11 19:47 +0100 |
| Message-ID | <nm0pku$v3o$2@dont-email.me> |
| In reply to | #90217 |
On 11/07/16 18:54, BartC wrote: > On 11/07/2016 14:11, Richard Heathfield wrote: >> On 11/07/16 13:38, BartC wrote: > >>> But the way around it is to always >> >> There's nothing to get around. >> >>> follow 'sizeof' with parentheses so that a following * can't be a >>> multiply. >> >> Why add spurious parentheses? The * that follows sizeof can /never/ be a >> multiplication symbol, because sizeof is not a valid operand for >> multiplication. The /result/ that sizeof yields can be, but sizeof >> itself is a keyword, not a value. > > Spot the line with only one multiply in it rather than two: > > array = malloc(seoizf*soeizf*seiozf); > array = malloc(sizoef*siozef*szoief); > array = malloc(siozef*szoeif*soezif); By this point, I don't /need/ to spot the line with only one multiplication in it. I just need to hand the specification to your replacement, saying "write this from scratch - don't bother looking at the code of the guy we fired, because it's Just Stupid". -- 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 | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-07-11 19:08 +0000 |
| Message-ID | <slrn3vfsno7rkq.h5m.ike@iceland.freeshell.org> |
| In reply to | #90217 |
On 2016-07-11, BartC <bc@freeuk.com> wrote: > Spot the line with only one multiply in it rather than two: > > array = malloc(seoizf*soeizf*seiozf); > array = malloc(sizoef*siozef*szoief); > array = malloc(siozef*szoeif*soezif); > array = malloc(szeiof*szioef*sezoif); > array = malloc(szeiof*soeizf*szoief); > array = malloc(sezoif*szeoif*seiozf); > array = malloc(szeiof*szeiof*sioezf); > array = malloc(szeiof*szoief*seziof); > array = malloc(szoeif*szoief*sieozf); > array = malloc(soiezf*sozief*soiezf); > array = malloc(sieozf*seziof*soiezf); > array = malloc(sioezf*soezif*szeiof); > array = malloc(seziof*sozief*seoizf); > array = malloc(seozif*siozef*siezof); > array = malloc(soezif*sioezf*siozef); > array = malloc(szeiof*sizeof*siozef); It's the line above. Using the search function of my editor (searching for 'sizeof') it took approximately two seconds to find it. > array = malloc(szeoif*soiezf*sizoef); > array = malloc(sozief*soizef*sozeif); > array = malloc(sieozf*sizoef*sizoef); > array = malloc(szeoif*seizof*sozeif); > > This is the kind of problem I mean. The syntax for sizeof operating on > an expression such as *x isn't distinct enough from a normal multiply. > That's I suggested putting in parentheses: > > array = malloc(seoizf*soeizf*seiozf); > array = malloc(sizoef*siozef*szoief); > array = malloc(siozef*szoeif*soezif); > array = malloc(szeiof*szioef*sezoif); > array = malloc(szeiof*soeizf*szoief); > array = malloc(sezoif*szeoif*seiozf); > array = malloc(szeiof*szeiof*sioezf); > array = malloc(szeiof*szoief*seziof); > array = malloc(szoeif*szoief*sieozf); > array = malloc(soiezf*sozief*soiezf); > array = malloc(sieozf*seziof*soiezf); > array = malloc(sioezf*soezif*szeiof); > array = malloc(seziof*sozief*seoizf); > array = malloc(seozif*siozef*siezof); > array = malloc(soezif*sioezf*siozef); > array = malloc(szeiof*sizeof(*siozef)); > array = malloc(szeoif*soiezf*sizoef); > array = malloc(sozief*soizef*sozeif); > array = malloc(sieozf*sizoef*sizoef); > array = malloc(szeoif*seizof*sozeif); But what if you would have written it like this: array = malloc(seoizf * soeizf * seiozf); array = malloc(sizoef * siozef * szoief); array = malloc(siozef * szoeif * soezif); array = malloc(szeiof * szioef * sezoif); array = malloc(szeiof * soeizf * szoief); array = malloc(sezoif * szeoif * seiozf); array = malloc(szeiof * szeiof * sioezf); array = malloc(szeiof * szoief * seziof); array = malloc(szoeif * szoief * sieozf); array = malloc(soiezf * sozief * soiezf); array = malloc(sieozf * seziof * soiezf); array = malloc(sioezf * soezif * szeiof); array = malloc(seziof * sozief * seoizf); array = malloc(seozif * siozef * siezof); array = malloc(soezif * sioezf * siozef); array = malloc(szeiof * sizeof *siozef); array = malloc(szeoif * soiezf * sizoef); array = malloc(sozief * soizef * sozeif); array = malloc(sieozf * sizoef * sizoef); array = malloc(szeoif * seizof * sozeif); Wouldn't that have made it just as easy to spot the special case?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-11 21:19 +0100 |
| Message-ID | <8760sc2aiz.fsf@bsb.me.uk> |
| In reply to | #90217 |
BartC <bc@freeuk.com> writes: > On 11/07/2016 14:11, Richard Heathfield wrote: >> On 11/07/16 13:38, BartC wrote: > >>> But the way around it is to always >> >> There's nothing to get around. >> >>> follow 'sizeof' with parentheses so that a following * can't be a >>> multiply. >> >> Why add spurious parentheses? The * that follows sizeof can /never/ be a >> multiplication symbol, because sizeof is not a valid operand for >> multiplication. The /result/ that sizeof yields can be, but sizeof >> itself is a keyword, not a value. > > Spot the line with only one multiply in it rather than two: > > array = malloc(seoizf*soeizf*seiozf); > array = malloc(sizoef*siozef*szoief); > array = malloc(siozef*szoeif*soezif); > array = malloc(szeiof*szioef*sezoif); > array = malloc(szeiof*soeizf*szoief); > array = malloc(sezoif*szeoif*seiozf); > array = malloc(szeiof*szeiof*sioezf); > array = malloc(szeiof*szoief*seziof); > array = malloc(szoeif*szoief*sieozf); > array = malloc(soiezf*sozief*soiezf); > array = malloc(sieozf*seziof*soiezf); > array = malloc(sioezf*soezif*szeiof); > array = malloc(seziof*sozief*seoizf); > array = malloc(seozif*siozef*siezof); > array = malloc(soezif*sioezf*siozef); > array = malloc(szeiof*sizeof*siozef); > array = malloc(szeoif*soiezf*sizoef); > array = malloc(sozief*soizef*sozeif); > array = malloc(sieozf*sizoef*sizoef); > array = malloc(szeoif*seizof*sozeif); Putting aside the absurd example, I'd make two remarks: 1. In my editor the sizeof is bright blue so it stands out very clearly despite your best attempts to hide it. 2. Any resaonble compiler will say something like "invalid operands to binary *" or "invalid type argument of unary *" depending on how you declare siozef. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-11 21:34 +0100 |
| Message-ID | <nm0vt6$ogf$1@dont-email.me> |
| In reply to | #90228 |
On 11/07/2016 21:19, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> array = malloc(soezif*sioezf*siozef); >> array = malloc(szeiof*sizeof*siozef); >> array = malloc(szeoif*soiezf*sizoef); >> array = malloc(sozief*soizef*sozeif); >> array = malloc(sieozf*sizoef*sizoef); >> array = malloc(szeoif*seizof*sozeif); > > Putting aside the absurd example, I'd make two remarks: > > 1. In my editor the sizeof is bright blue so it stands out very clearly > despite your best attempts to hide it. (I hope there was only one? I was in a hurry to go out and forgot to check!) My point still stands but few are seeing it, that it just looks very odd that on one line you have A*B*Cm multiplying three names, yet in another lexically identical line, it means something quite different. (In fact, if A and B represent any names not yet resolved in a symbol table, then A*B could mean multiply, it could mean sizeof(*B) (obviously only when A is 'sizeof') or it could mean declare B as type pointer to A. I'm still looking for a fourth possibility, that doesn't involve A or B being macros as that would be too easy.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-11 13:48 -0700 |
| Message-ID | <lnmvlnkiit.fsf@kst-u.example.com> |
| In reply to | #90230 |
BartC <bc@freeuk.com> writes:
> On 11/07/2016 21:19, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> array = malloc(soezif*sioezf*siozef);
>>> array = malloc(szeiof*sizeof*siozef);
>>> array = malloc(szeoif*soiezf*sizoef);
>>> array = malloc(sozief*soizef*sozeif);
>>> array = malloc(sieozf*sizoef*sizoef);
>>> array = malloc(szeoif*seizof*sozeif);
>>
>> Putting aside the absurd example, I'd make two remarks:
>>
>> 1. In my editor the sizeof is bright blue so it stands out very clearly
>> despite your best attempts to hide it.
>
> (I hope there was only one? I was in a hurry to go out and forgot to check!)
>
> My point still stands but few are seeing it, that it just looks very odd
> that on one line you have A*B*Cm multiplying three names, yet in another
> lexically identical line, it means something quite different.
I don't think anyone is failing to see your point. We just don't think
it's significant.
You can write horribly obfuscated code in C, and it's easier in C than
in most other languages.
So don't do 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-11 22:49 +0100 |
| Message-ID | <87twfv26cv.fsf@bsb.me.uk> |
| In reply to | #90230 |
BartC <bc@freeuk.com> writes: > On 11/07/2016 21:19, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> array = malloc(soezif*sioezf*siozef); >>> array = malloc(szeiof*sizeof*siozef); >>> array = malloc(szeoif*soiezf*sizoef); >>> array = malloc(sozief*soizef*sozeif); >>> array = malloc(sieozf*sizoef*sizoef); >>> array = malloc(szeoif*seizof*sozeif); >> >> Putting aside the absurd example, I'd make two remarks: >> >> 1. In my editor the sizeof is bright blue so it stands out very clearly >> despite your best attempts to hide it. > > (I hope there was only one? I was in a hurry to go out and forgot to check!) > > My point still stands but few are seeing it, that it just looks very > odd that on one line you have A*B*Cm multiplying three names, yet in > another lexically identical line, it means something quite different. As far as I can see everyone gets your point. In this specific reply I was objecting to how you made it. And here there's a detail I object to as well -- lexical analysis usually identifies keywords (like sizeof) so A*B*C and A*sizeof*C are not really "lexically identical". <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-11 23:20 +0100 |
| Message-ID | <nm1636$h7q$1@dont-email.me> |
| In reply to | #90237 |
On 11/07/2016 22:49, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 11/07/2016 21:19, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >> My point still stands but few are seeing it, that it just looks very >> odd that on one line you have A*B*Cm multiplying three names, yet in >> another lexically identical line, it means something quite different. > > As far as I can see everyone gets your point. In this specific reply I > was objecting to how you made it. And here there's a detail I object to > as well -- lexical analysis usually identifies keywords (like sizeof) so > A*B*C and A*sizeof*C are not really "lexically identical". In my tokenisers looking up names to turn them into possible reserved works can be a separate step. For a low-level tokeniser that doesn't do that step, then A*B*C is no different from A*sizeof*C. 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. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-12 10:26 +0530 |
| Message-ID | <nm1t9l$94u$1@dont-email.me> |
| In reply to | #90240 |
[Multipart message — attachments visible in raw view] — view raw
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. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-11 22:34 -0700 |
| Message-ID | <2cfb31aa-11dd-422c-a5ea-07f44bee0deb@googlegroups.com> |
| In reply to | #90246 |
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. If we see something like sizeof *x * N does that mean sizeof(*x) *N or sizeof(*x *N)? You can of course tell people, but the parentheses make more sense. 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.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-07-12 06:39 +0000 |
| Message-ID | <slrn3vfsno944c.njq.ike@iceland.freeshell.org> |
| In reply to | #90247 |
On 2016-07-12, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > Yes, it's undesireable that C's syntax permits sizeof without the > parentheses. If we see something like sizeof *x * N does that mean > sizeof(*x) *N or sizeof(*x *N)? You can of course tell people, but > the parentheses make more sense. If you find that sizeof *x * N is ambiguous for the reason mentioned above, then sizeof(*x) *N would be ambiguous for the same reason, it makes you wonder whether (sizeof(*x)) * N or sizeof((*x) * N) was intended.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-12 00:41 -0700 |
| Message-ID | <e88c7f79-65f7-4bbc-b407-b68204e48fd1@googlegroups.com> |
| In reply to | #90249 |
On Tuesday, July 12, 2016 at 7:39:23 AM UTC+1, Ike Naar wrote: > On 2016-07-12, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > Yes, it's undesireable that C's syntax permits sizeof without the > > parentheses. If we see something like sizeof *x * N does that mean > > sizeof(*x) *N or sizeof(*x *N)? You can of course tell people, but > > the parentheses make more sense. > > If you find that > > sizeof *x * N > > is ambiguous for the reason mentioned above, then > > sizeof(*x) *N > > would be ambiguous for the same reason, it makes you wonder whether > > (sizeof(*x)) * N > > or > > sizeof((*x) * N) > > was intended. > sizeof is an operator, therefore it has precedence. But there is no convention for the precedence of the sizeof operator, because even most other computer languages don't have an equivalent. So you just have to know.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-12 08:57 +0100 |
| Message-ID | <nm27su$4f3$1@dont-email.me> |
| In reply to | #90250 |
On 12/07/16 08:41, Malcolm McLean wrote: > On Tuesday, July 12, 2016 at 7:39:23 AM UTC+1, Ike Naar wrote: >> On 2016-07-12, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >>> Yes, it's undesireable that C's syntax permits sizeof without the >>> parentheses. If we see something like sizeof *x * N does that mean >>> sizeof(*x) *N or sizeof(*x *N)? You can of course tell people, but >>> the parentheses make more sense. >> >> If you find that >> >> sizeof *x * N >> >> is ambiguous for the reason mentioned above, then >> >> sizeof(*x) *N >> >> would be ambiguous for the same reason, it makes you wonder whether >> >> (sizeof(*x)) * N >> >> or >> >> sizeof((*x) * N) >> >> was intended. >> > sizeof is an operator, therefore it has precedence. > But there is no convention for the precedence of the sizeof operator, 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. > because even most other computer languages don't have an equivalent. That doesn't mean C doesn't have a convention. > So you just have to know. Yes, you do, but the good news is that it isn't difficult. -- 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]
Page 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web