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 17 of 18 — ← Prev page 1 … 15 16 [17] 18 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-11 10:53 -0700 |
| Message-ID | <lnbn24kqne.fsf@kst-u.example.com> |
| In reply to | #90205 |
BartC <bc@freeuk.com> writes:
> 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.
sizeof is an operator, not a function. Always using parentheses makes
it look like a function, which is misleading.
A "*" following a "sizeof" operator can't be a multiply anyway.
It can only be part of the operand of the "sizeof".
C is perhaps unusual in that almost all of its operators are
spelled with punctation symbols. "sizeof", being a keyword, is
(almost) the sole exception. (_Alignof is the other, but it's a bit
unusual in that its operand can only be a parenthesized type name.)
In languages with more operators whose names are keywords, it might
be less confusing.
> 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.
Don't write it as name*name*name. Write it as n * sizeof *p. The
spacing around the second "*" suggests an asymmetry. And the use of the
sizeof operator (remember, sizeof is an operator) also suggests that the
second "*" can't be a multiplication.
> Using "*" for dereference also gives rise to this:
>
> b * * * * p
Which any sane C programmer would write as
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.
If p needs to be a pointer to a pointer to a pointer, then that's what
it should be. It's complicated, but it's a complication that arises
only when the underlying problem is inherently complicated. (Depending
on the context, the code might be easier to understand with some
well-chosen typedefs -- though typedef'ing pointer types can cause more
problems that it solves.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-11 21:20 +0100 |
| Message-ID | <nm0v3c$li6$1@dont-email.me> |
| In reply to | #90216 |
On 11/07/2016 18:53, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> 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. > > sizeof is an operator, not a function. Always using parentheses makes > it look like a function, which is misleading. And not using parentheses makes it look like a multiply. Which is worse? And Richard would say neither would be a problem if you see that it is 'sizeof' and not any other identifier. >> Using "*" for dereference also gives rise to this: >> >> b * * * * p > > Which any sane C programmer would write as > > b * ***p I would use parentheses here as well. But the point is that some aspects of C syntax are unusually sensitive to white space. So this probably doesn't mean what it looks like at first: int* p,q,r; but this probably does: int *p,q,r; And this doesn't do what it looks like either: y = x**2; While this: y = x / *p; means something different from: y = x/*p; Like I said, the syntax was poorly thought out. All these examples involve * used to do things with pointers. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-11 13:56 -0700 |
| Message-ID | <lnfurfki5w.fsf@kst-u.example.com> |
| In reply to | #90229 |
BartC <bc@freeuk.com> writes:
> On 11/07/2016 18:53, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> 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.
>>
>> sizeof is an operator, not a function. Always using parentheses makes
>> it look like a function, which is misleading.
>
> And not using parentheses makes it look like a multiply. Which is worse?
>
> And Richard would say neither would be a problem if you see that it is
> 'sizeof' and not any other identifier.
>
>>> Using "*" for dereference also gives rise to this:
>>>
>>> b * * * * p
>>
>> Which any sane C programmer would write as
>>
>> b * ***p
>
> I would use parentheses here as well. But the point is that some aspects
> of C syntax are unusually sensitive to white space. So this probably
> doesn't mean what it looks like at first:
>
> int* p,q,r;
>
> but this probably does:
>
> int *p,q,r;
>
> And this doesn't do what it looks like either:
>
> y = x**2;
>
> While this:
>
> y = x / *p;
>
> means something different from:
>
> y = x/*p;
>
> Like I said, the syntax was poorly thought out. All these examples
> involve * used to do things with pointers.
You've demonstrated that, by judicious misuse of white space, it's
possible to write C code that's difficult to read.
I hope you're not under the impression that this is news to anyone here.
"Doctor, my code is hard to read when I do this!"
...
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-11 22:39 +0100 |
| Message-ID | <nm13n8$68u$1@dont-email.me> |
| In reply to | #90233 |
On 11/07/2016 21:56, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> Like I said, the syntax was poorly thought out. All these examples >> involve * used to do things with pointers. > > You've demonstrated that, by judicious misuse of white space, it's > possible to write C code that's difficult to read. Misleading is more apt in my examples. And completely wrong when it's the space between / and *. C is free-format where white space is not supposed to be significant except to separate identifiers. (Or sometimes, to distinguish symbols such as "++" from "+ +".) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-12 10:57 +0200 |
| Message-ID | <nm2bdh$esa$1@dont-email.me> |
| In reply to | #90236 |
On 11/07/16 23:39, BartC wrote: > On 11/07/2016 21:56, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: > >>> Like I said, the syntax was poorly thought out. All these examples >>> involve * used to do things with pointers. >> >> You've demonstrated that, by judicious misuse of white space, it's >> possible to write C code that's difficult to read. > > Misleading is more apt in my examples. And completely wrong when it's > the space between / and *. > > C is free-format where white space is not supposed to be significant > except to separate identifiers. (Or sometimes, to distinguish symbols > such as "++" from "+ +".) > White space is significant to the language and a compiler as a separator in many contexts - but the number and type of the white space is not significant. However, white space is very significant to humans, and how they interpret the code. So you use spaces in a way that makes sense to human readers. But the same applies to comments, identifier names, and many other aspects of programming - there is nothing special about white space here, nor anything special about C. int nameOfCountry; // The number of trees const char* population; // A floating point counter if (p) doThis(*p); doThat(*p); You can write code where the actual effect or meaning of the code is different from the apparent effect. You can do that in any language. Writing "int* p, q;" is just one more (easily avoided) way of doing it.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-11 21:58 +0100 |
| Message-ID | <nm118q$t4o$1@dont-email.me> |
| In reply to | #90229 |
On 11/07/16 21:20, BartC wrote: > On 11/07/2016 18:53, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: > >>> 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. >> >> sizeof is an operator, not a function. Always using parentheses makes >> it look like a function, which is misleading. > > And not using parentheses makes it look like a multiply. Not to me. -- 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:23 +0100 |
| Message-ID | <nm034i$9bm$1@dont-email.me> |
| In reply to | #90199 |
On 11/07/2016 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. > malloc ten times sizeof times array? Ten times the size of the array? > Code like that is a potential source of error and confusion. The name 'array' is misleading here. Yet the idiom 'T* A;' to declare a dynamic array of type T is common, so it is tempting to name A after some sort of array, list or table rather than base it on the element type. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-11 13:00 +0000 |
| Message-ID | <5783983e.16916640@news.xs4all.nl> |
| In reply to | #90199 |
Malcolm McLean <malcolm.mclean5@btinternet.com> 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. > malloc ten times sizeof times array? Ten times the size of the array? > Code like that is a potential source of error and confusion. What anti-intellectual, BASIC-level nonsense. I should be disappointed in you, but really, I can't be arsed anymore. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-11 10:44 -0700 |
| Message-ID | <lnfurgkr1y.fsf@kst-u.example.com> |
| In reply to | #90199 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 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.
Gibberish. (I'm referring to what you just wrote, not to the code.)
All that's necessary to understand that code is a reasonable
knowledge of C and/or familiarity with that particular idiom.
I presume *you* understand it, Malcolm, even if you don't like it.
Are you assuming that other C programmers lack your understanding?
Sure, someone who doesn't know that sizeof is an operator, and that
* is both a binary operator (multiplication) and a unary operator
(dereferencing) would have difficulty understanding that line.
The cure is to learn.
If you wanted to add parentheses to make it clearer:
int *array = malloc(10 * sizeof (*array));
I wouldn't object strongly (though I wouldn't bother to do so
myself).
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-07-11 19:10 +0100 |
| Message-ID | <87furggi5b.fsf@gmail.com> |
| In reply to | #90215 |
Keith Thompson <kst-u@mib.org> writes: >> 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. > > Gibberish. (I'm referring to what you just wrote, not to the code.) Have you really not yet spotted that Malcolm is a supremely confident idiot?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-11 20:22 +0100 |
| Message-ID | <nm0rl3$89g$1@dont-email.me> |
| In reply to | #90222 |
On 11/07/16 19:10, Gareth Owen wrote: > Keith Thompson <kst-u@mib.org> writes: > >>> 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. >> >> Gibberish. (I'm referring to what you just wrote, not to the code.) > > Have you really not yet spotted that Malcolm is a supremely confident idiot? I was about to leap to Malcolm's defence. I know that he's a bit wossname, but I was very impressed by the simplicity of his JPEG interface: unsigned char *loadjpeg(const char *path, int *width, int *height); int savejpeg(char *path, unsigned char *rgb, int width, int height); This is *exactly* right for almost all the stuff I want to do with JPEGs, and hardly the sign of an idiot. Now, I've long wanted a decent JPEG codec. Write one myself? I looked at the spec, and thought "no". Use one off-the-peg? No, it turns out they're all written by Martians. But Malcolm had this much simpler version. He was kind enough to let me have the code months and months (possibly a year or two) ago. What with one thing and another, I never quite got around to testing it, but when I saw that "supremely confident idiot" jibe, I thought "okay, time to do the white knight thing - I'll test that code, and then praise it for doing such a fine job on such a fiddly task, and that'll be one in the eye for the doing-people-down brigade" (and I'd be able to tick that job off as done, too, and get on with doing all the things I've wanted to do with JPEGs over the years). Unfortunately, Gareth (and this may raise a wry smile in your wizened heart), I cannot tell a lie: the code Doesn't Work. It took me longer than it should have done to find out /why/ it doesn't work, because Malcolm's coding style is custom-designed to set my teeth on edge, but I eventually tracked it down to this: return -1; I trust that Malcolm will be able to use that valuable debugging information to find out what went wrong. -- 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 21:11 +0100 |
| Message-ID | <nm0ugv$jao$1@dont-email.me> |
| In reply to | #90226 |
On 11/07/2016 20:22, Richard Heathfield wrote:
> On 11/07/16 19:10, Gareth Owen wrote:
> I was about to leap to Malcolm's defence. I know that he's a bit
> wossname, but I was very impressed by the simplicity of his JPEG interface:
>
> unsigned char *loadjpeg(const char *path, int *width, int *height);
> int savejpeg(char *path, unsigned char *rgb, int width, int height);
> Unfortunately, Gareth (and this may raise a wry smile in your wizened
> heart), I cannot tell a lie: the code Doesn't Work.
>
> It took me longer than it should have done to find out /why/ it doesn't
> work, because Malcolm's coding style is custom-designed to set my teeth
> on edge, but I eventually tracked it down to this:
>
> return -1;
I tried the same library a year ago or whenever it was.
I don't recall any problems (although I mainly worked with loadjpeg()).
The only issue I found was minor: two source lines were in the wrong
order, causing chroma artefacts on some images.
Also, although this is one of specification, it only deals with 1x1 or
2x2 chroma sub-sampling, not the 2x1 you get from digital camera images
(which I fixed on a derived version).
So for my purposes it was pretty much perfect, and with a very simple
interface as you say, and only a single module for loading an image
(compared with dozens with some more elaborate libraries).
(I haven't worked with the original C for a while, but a first time test
seemed to go something like this:
int main (void) {
char* image;
int width=0, height=0;
image = loadjpeg("card2.jpg", &width, &height);
printf("Image=%p W=%d H=%d\n", image, width, height);
}
Provided the right dimensions are shown, then it's probably working
along the right lines and it's worth trying to display the decoded image
data.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-07-11 21:49 +0100 |
| Message-ID | <87mvln6gt1.fsf@gmail.com> |
| In reply to | #90226 |
Richard Heathfield <rjh@cpax.org.uk> writes: > Unfortunately, Gareth (and this may raise a wry smile in your wizened > heart), I cannot tell a lie: the code Doesn't Work. That's the nicest thing anyone's said about my heart in a long time. But it doesn't raise a smile. I'm quite fond of being right (almost certainly too fond, and probably much too fond) but its not dependent on other people being wrong.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-11 22:01 +0100 |
| Message-ID | <nm11f7$uau$1@dont-email.me> |
| In reply to | #90232 |
On 11/07/16 21:49, Gareth Owen wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> Unfortunately, Gareth (and this may raise a wry smile in your wizened >> heart), I cannot tell a lie: the code Doesn't Work. > > That's the nicest thing anyone's said about my heart in a long time. Oh dear. :-) > But it doesn't raise a smile. I'm quite fond of being right (almost > certainly too fond, and probably much too fond) but its not dependent on > other people being wrong. Hence "wry". It's a darn shame that the code doesn't work, actually. BartC says it works fine for him, which is odd, but he also says that it fails to cope with digital camera images, which is most of them nowadays. I still don't think Malcolm's an idiot, though. I think he has an odd way of looking at the world, and his code definitely needs a good kicking, but very often I can kind of see where he's coming from even though I don't agree with him. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-11 09:09 -0400 |
| Message-ID | <nm05qp$ivp$1@dont-email.me> |
| In reply to | #90197 |
On 07/11/2016 07:01 AM, Richard Bos wrote: ... > And a call to malloc() is _not_ something unusual, nor does it play fast > and loose with the type system. Sorry, but Stroustrup is just _wrong_ > here: malloc() is _not_ risky. It's been specifically designed not to > be. That C++ requirer a cast on it is a result of Bjarne's failure to > understand malloc(), nothing else. I don't think that's correct. The 'new' operator in C++ is the proper replacement for malloc(), and it is safer to use precisely because it is type-specific. Where I think Stroustrup got it wrong was in assuming that requiring explicit casts to convert pointers to void into pointers to object types does anything to increase the safety of the code. malloc() is unsafe - it you assign it's value to a pointer of the wrong type, things will go bad, but casting it's value to that same type does nothing to prevent the problem, and making sure that you allocate the correct size does everything that needs to be done to prevent the problem.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-11 14:16 +0100 |
| Message-ID | <nm067q$kil$1@dont-email.me> |
| In reply to | #90207 |
On 11/07/16 14:09, James Kuyper wrote: > On 07/11/2016 07:01 AM, Richard Bos wrote: > ... >> And a call to malloc() is _not_ something unusual, nor does it play fast >> and loose with the type system. Sorry, but Stroustrup is just _wrong_ >> here: malloc() is _not_ risky. It's been specifically designed not to >> be. That C++ requirer a cast on it is a result of Bjarne's failure to >> understand malloc(), nothing else. > > I don't think that's correct. The 'new' operator in C++ is the proper > replacement for malloc(), and it is safer to use precisely because it is > type-specific. One might argue that new is a replacement for malloc(sizeof *p), perhaps, but it's a lousy replacement for malloc(n * sizeof *p) because we can't realloc it. People should use std::vector instead (and take it over to clc++ while they're at it!). > Where I think Stroustrup got it wrong was in assuming that requiring > explicit casts to convert pointers to void into pointers to object types > does anything to increase the safety of the code. You're right. All it does is increase the amount of thoughtless typing (pun intended) that someone has to do in order to break the code. I suppose it slows down the rate at which people can write bad code, which is /something/, but tools like auto-completion bring the rate right back up again. > malloc() is unsafe - In about the same way that a circular saw is unsafe, yes. Very powerful, very useful, very important - but mind your fingers. > it you assign it's value to a pointer of the wrong type, things will go > bad, but casting it's value to that same type does nothing to prevent > the problem, and making sure that you allocate the correct size does > everything that needs to be done to prevent the problem. Quite so. -- 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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-15 13:51 +0000 |
| Message-ID | <5788e9c9.22177734@news.xs4all.nl> |
| In reply to | #90207 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 07/11/2016 07:01 AM, Richard Bos wrote: > ... > > And a call to malloc() is _not_ something unusual, nor does it play fast > > and loose with the type system. Sorry, but Stroustrup is just _wrong_ > > here: malloc() is _not_ risky. It's been specifically designed not to > > be. That C++ requirer a cast on it is a result of Bjarne's failure to > > understand malloc(), nothing else. > > I don't think that's correct. The 'new' operator in C++ is the proper > replacement for malloc(), and it is safer to use precisely because it is > type-specific. That's still not my point - my point was... > Where I think Stroustrup got it wrong was in assuming that requiring > explicit casts to convert pointers to void into pointers to object types > does anything to increase the safety of the code. ...this. The cast is useless, and therefore, since it diminishes the warning value of useful casts, worse than useless. Therefore, that C++ demands this cast is bad _regardless that_ it also supplies alternatives. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-15 12:04 -0400 |
| Message-ID | <nmb1ih$lpf$1@dont-email.me> |
| In reply to | #90395 |
On 07/15/2016 09:51 AM, Richard Bos wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > >> On 07/11/2016 07:01 AM, Richard Bos wrote: >> ... >>> And a call to malloc() is _not_ something unusual, nor does it play fast >>> and loose with the type system. Sorry, but Stroustrup is just _wrong_ >>> here: malloc() is _not_ risky. It's been specifically designed not to >>> be. That C++ requirer a cast on it is a result of Bjarne's failure to >>> understand malloc(), nothing else. >> >> I don't think that's correct. The 'new' operator in C++ is the proper >> replacement for malloc(), and it is safer to use precisely because it is >> type-specific. > > That's still not my point - my point was... True, that wasn't your point. It was a new point, made by me in response to your claim that "malloc() is not risky". It is risky - in my experience, problems related to malloc() are among the most common code defects in C, and among the hardest to debug. The fact that C++ requires malloc() to be prefixed by a cast doesn't make it any less risky; but replacing it in C++ code with the new operator (either directly, or preferably hidden inside smart pointers or containers) does improve safety.
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-07-11 17:51 +0200 |
| Message-ID | <87r3b0dvfp.fsf@news.bourguet.org> |
| In reply to | #90197 |
raltbos@xs4all.nl (Richard Bos) writes:
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 09/07/16 16:16, James R. Kuyper wrote:
>
>> > True - but the case under discussion is one of those reasons. In pure
>> > C++ code, calls to malloc() should almost always be replaced by more
>> > type-safe approaches such as direct or indirect use of the 'new'
>> > operator. But in code meant to be usable in both C and C++, it's
>> > annoying that casting the value returned by malloc() is mandatory in
>> > C++, and a bad idea in C.
>>
>> Casting the return value from malloc is not "a bad idea". It is no more
>> and no less than an extra repetition of types you are already using:
>>
>> int* array = (int*) malloc(10 * sizeof(int));
>
> int *array = malloc(10 * sizeof *array);
>
>> Yes, you need to write the same type three times if you want to express
>> your allocation in this manner.
>
> I need to write the same type once. And the object name twice, but it's
> still more solid than the C++ way.
The C++ way is
std::vector<int> array{10};
or, less often, a variation on
auto array{std::make_unique<int>(10)};
or, even more rarely,
auto array = new int[10];
or if you are old fashioned,
std::vector<int> array(10);
std::unique_ptr<int> array(new int[10]);
int* array = new int[10];
But variations on
int* array = (int*) malloc(10 * sizeof(int));
are no more the C++ way than it is the C way. It is the "C/C++" way,
usefull when you need something acceptable in both languages but it is
idiomatic in neither.
Yours,
--
Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-11 10:19 +0000 |
| Message-ID | <57837211.7144593@news.xs4all.nl> |
| In reply to | #90144 |
"James R. Kuyper" <jameskuyper@verizon.net> wrote: > On 07/09/2016 01:13 AM, Nobody wrote: > > On Wed, 06 Jul 2016 15:22:51 -0400, James R. Kuyper wrote: > > > >>> Casting is /less/ common in C++ than in C -- there's nothing to lament! > >>> Unless you compile C code with a C++ compiler, which is generally a bad > >>> idea. > >> > >> Casting (preferably by using static_cast<>) is required by C++ to convert > >> a void* to a pointer to object type (C++ 2011 C.1.3, cross-referencing > >> 4.10). Such conversions do not occur implicitly the way they do in C. > > > > OTOH, C++ code typically has fewer reasons to use void* in the first place. > > > > True - but the case under discussion is one of those reasons. In pure > C++ code, calls to malloc() should almost always be replaced by more > type-safe approaches such as direct or indirect use of the 'new' > operator. But in code meant to be usable in both C and C++, it's > annoying that casting the value returned by malloc() is mandatory in > C++, and a bad idea in C. Exactly. Because it's _still_ a bad idea in C++, but there, it's a mandatory bad idea. C++'s idea about void * type safety is exactly backwards: casting _to_ void * is more dangerous than casting void * to other kinds of pointers (even if only slightly), but C++ demands the cast on the latter, not the former. Richard
[toc] | [prev] | [next] | [standalone]
Page 17 of 18 — ← Prev page 1 … 15 16 [17] 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web