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 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-11 10:41 +0000 |
| Message-ID | <578377b1.8584296@news.xs4all.nl> |
| In reply to | #90147 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, July 9, 2016 at 3:16:09 PM UTC+1, 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. > > > It's not really "a bad idea" in C. It's as bad an idea as hanging a high-voltage sign on every battery. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-09 20:27 +0200 |
| Message-ID | <nlrfm4$fgs$1@dont-email.me> |
| In reply to | #90144 |
On 09/07/16 16:16, James R. Kuyper 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. > 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)); Yes, you need to write the same type three times if you want to express your allocation in this manner. But so what? The cast does no harm to your code, and it is only really relevant if you need to change the type in some revision of the code. And if that is likely enough for the extra cast to be a risk of bugs or of extra effort, then you are probably going to have to change a lot more code anyway - and you are better off writing: typedef int elemType; ... elemType* array = (elemType*) malloc(10 * sizeof(elemType)); Or you can put the malloc inside a function or macro so you don't have to use the cast throughout the code. Casting the result of malloc is neither hard nor error-prone - it's just one of these things that some C programmers think is important to avoid because using the cast makes your code look like C++. It is much like some C++ that get upset when someone writes "void foo(void);", because in C++ it "should" be written "void foo();". Sometimes writing your C code in a C++ compatible manner involves a little extra effort, but it is rare (IME) that the result is "bad" C code.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-07-09 11:31 -0700 |
| Message-ID | <nlrfug$gbp$1@dont-email.me> |
| In reply to | #90150 |
On 7/9/2016 11:27 AM, David Brown wrote: > Casting the return value from malloc is not "a bad idea". wrt compiling C as C++, yes I totally agree!
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-07-09 20:14 +0100 |
| Message-ID | <878txaipz2.fsf@gmail.com> |
| In reply to | #90150 |
David Brown <david.brown@hesbynett.no> writes: > Casting the result of malloc is neither hard nor error-prone QFT
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-09 15:34 -0400 |
| Message-ID | <nlrjkp$skl$1@jstuckle.eternal-september.org> |
| In reply to | #90150 |
On 7/9/2016 2:27 PM, David Brown wrote: > On 09/07/16 16:16, James R. Kuyper 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. >> > > 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)); > > Yes, you need to write the same type three times if you want to express > your allocation in this manner. But so what? The cast does no harm to > your code, and it is only really relevant if you need to change the type > in some revision of the code. And if that is likely enough for the > extra cast to be a risk of bugs or of extra effort, then you are > probably going to have to change a lot more code anyway - and you are > better off writing: > > typedef int elemType; > ... > elemType* array = (elemType*) malloc(10 * sizeof(elemType)); > > Or you can put the malloc inside a function or macro so you don't have > to use the cast throughout the code. > > Casting the result of malloc is neither hard nor error-prone - it's just > one of these things that some C programmers think is important to avoid > because using the cast makes your code look like C++. It is much like > some C++ that get upset when someone writes "void foo(void);", because > in C++ it "should" be written "void foo();". > > Sometimes writing your C code in a C++ compatible manner involves a > little extra effort, but it is rare (IME) that the result is "bad" C code. > One of the advantages of casting the return value is if someone comes long later and changes the type in the declaration, you will get a compiler error, i.e. int * p; ... p = (int *) malloc(sizeof(int)); Now, if someone later changes the first line to double * p; the compiler will generate an error. If not, you end up with trying to store a double in space reserved for an int - and no compiler error. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-09 14:02 -0700 |
| Message-ID | <c99c343e-c95d-41f3-b8a0-995e27fb2c1e@googlegroups.com> |
| In reply to | #90153 |
On Saturday, July 9, 2016 at 3:34:57 PM UTC-4, Jerry Stuckle wrote: > On 7/9/2016 2:27 PM, David Brown wrote: ... > > Casting the result of malloc is neither hard nor error-prone - it's just > > one of these things that some C programmers think is important to avoid > > because using the cast makes your code look like C++. It is much like > > some C++ that get upset when someone writes "void foo(void);", because > > in C++ it "should" be written "void foo();". > > > > Sometimes writing your C code in a C++ compatible manner involves a > > little extra effort, but it is rare (IME) that the result is "bad" C code. > > > > One of the advantages of casting the return value is if someone comes > long later and changes the type in the declaration, you will get a > compiler error, i.e. > > int * p; > ... > p = (int *) malloc(sizeof(int)); > > Now, if someone later changes the first line to > > double * p; > > the compiler will generate an error. ... That's actually a disadvantage. It means that the cast needs to be changed whenever the type of p changes, in order to avoid the error message, a problem that can be removed if you remove the cast. Note, in particular, that fixing only the cast does NOT fix the real problem: p = (double*) malloc( sizeof(int)); and the cast causes an utterly unnecessary and useless error message if you add it to what is otherwise the preferred way of handling the call: p = (double*) malloc( sizeof *p); > ... If not, you end up with trying to > store a double in space reserved for an int - and no compiler error. Unless you need your code to work with C++, what advantage does that code have over: p = malloc(sizeof *p);
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-09 14:10 -0700 |
| Message-ID | <ln1t32msb8.fsf@kst-u.example.com> |
| In reply to | #90158 |
jameskuyper@verizon.net writes:
[...]
> That's actually a disadvantage. It means that the cast needs to be
> changed whenever the type of p changes, in order to avoid the error
> message, a problem that can be removed if you remove the cast. Note,
> in particular, that fixing only the cast does NOT fix the real
> problem:
>
> p = (double*) malloc( sizeof(int));
>
> and the cast causes an utterly unnecessary and useless error message
> if you add it to what is otherwise the preferred way of handling the
> call:
>
> p = (double*) malloc( sizeof *p);
I presume you didn't intend to use a cast there.
--
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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-09 17:14 -0400 |
| Message-ID | <1ad2ad44-a44e-adee-2b4e-8a4c80a881d9@verizon.net> |
| In reply to | #90159 |
On 07/09/2016 05:10 PM, Keith Thompson wrote: > jameskuyper@verizon.net writes: ... >> and the cast causes an utterly unnecessary and useless error message >> if you add it to what is otherwise the preferred way of handling the >> call: >> >> p = (double*) malloc( sizeof *p); > > I presume you didn't intend to use a cast there. Actually, I did - that code was intended to be an example of what should NOT be done, and why.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-09 14:24 -0700 |
| Message-ID | <lnwpkuld2i.fsf@kst-u.example.com> |
| In reply to | #90160 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 07/09/2016 05:10 PM, Keith Thompson wrote:
>> jameskuyper@verizon.net writes:
> ...
>>> and the cast causes an utterly unnecessary and useless error message
>>> if you add it to what is otherwise the preferred way of handling the
>>> call:
>>>
>>> p = (double*) malloc( sizeof *p);
>>
>> I presume you didn't intend to use a cast there.
>
> Actually, I did - that code was intended to be an example of what should
> NOT be done, and why.
"otherwise". Got it.
--
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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-09 17:31 -0400 |
| Message-ID | <54350036-f387-a0b9-731a-4f5a6c510017@verizon.net> |
| In reply to | #90158 |
On 07/09/2016 05:02 PM, jameskuyper@verizon.net wrote:
> On Saturday, July 9, 2016 at 3:34:57 PM UTC-4, Jerry Stuckle wrote:
...
>> int * p;
>> ...
>> p = (int *) malloc(sizeof(int));
>>
>> Now, if someone later changes the first line to
>>
>> double * p;
...
> and the cast causes an utterly unnecessary and useless error message if you add it to what is otherwise the preferred way of handling the call:
>
> p = (double*) malloc( sizeof *p);
I just realized that I should have written that as:
p = (int*)malloc(sizeof *p);
in order to provoke the error message I was talking about.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-09 20:50 -0400 |
| Message-ID | <nls656$m26$1@jstuckle.eternal-september.org> |
| In reply to | #90158 |
On 7/9/2016 5:02 PM, jameskuyper@verizon.net wrote: > On Saturday, July 9, 2016 at 3:34:57 PM UTC-4, Jerry Stuckle wrote: >> On 7/9/2016 2:27 PM, David Brown wrote: > ... >>> Casting the result of malloc is neither hard nor error-prone - it's just >>> one of these things that some C programmers think is important to avoid >>> because using the cast makes your code look like C++. It is much like >>> some C++ that get upset when someone writes "void foo(void);", because >>> in C++ it "should" be written "void foo();". >>> >>> Sometimes writing your C code in a C++ compatible manner involves a >>> little extra effort, but it is rare (IME) that the result is "bad" C code. >>> >> >> One of the advantages of casting the return value is if someone comes >> long later and changes the type in the declaration, you will get a >> compiler error, i.e. >> >> int * p; >> ... >> p = (int *) malloc(sizeof(int)); >> >> Now, if someone later changes the first line to >> >> double * p; >> >> the compiler will generate an error. ... > > That's actually a disadvantage. It means that the cast needs to be changed whenever the type of p changes, in order to avoid the error message, a problem that can be removed if you remove the cast. Note, in particular, that fixing only the cast does NOT fix the real problem: > > p = (double*) malloc( sizeof(int)); > > and the cast causes an utterly unnecessary and useless error message if you add it to what is otherwise the preferred way of handling the call: > > p = (double*) malloc( sizeof *p); > > >> ... If not, you end up with trying to >> store a double in space reserved for an int - and no compiler error. > > Unless you need your code to work with C++, what advantage does that code have over: > > p = malloc(sizeof *p); > Which can be a huge problem if you're storing/retrieving the data, i.e. in a database or binary file. Suddenly data from previous runs of the program are not compatible with runs after the change - and this can be a very difficult problem to find. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-09 15:50 -0400 |
| Message-ID | <e05fc20f-5e8f-8e6c-1f19-4e156bf337de@verizon.net> |
| In reply to | #90150 |
On 07/09/2016 02:27 PM, David Brown 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".
...
> typedef int elemType;
> ...
> elemType* array = (elemType*) malloc(10 * sizeof(elemType));
The alternative I (and others) recommend is:
elemType* array = malloc(10* sizeof *array);
It doesn't make much difference here, where the call to malloc() occurs
during the initialization of 'array'. However, it is quite common for
the declaration of the variable to be well separated from the assignment
statement; particularly if it's a member of a struct or union. In those
cases it's a big advantage to be able to confirm that the argument to
malloc() is correct, without having to find the declaration of the variable.
If there is any danger of your code being compiled in C90 mode, then the
cast can mask an error if you forgot to #include <stdlib.h>. Code can
be explicitly protected from compiling in C90 mode by testing the value
of __STDC_VERSION__, and it can be implicitly protected by making use of
features that were new in C99 or C2011, and constraint violations or
syntax errors in C90. Such protection renders that issue less important
- but that seems to me to be an excessively subtle way to avoid that
problem.
The cast serves no useful purpose in C; it specifies a conversion that
would have occurred anyway without the cast. Keeping the amount of
memory allocated consistent with the type of the pointer is the key
point, and that's dealt with completely by using sizeof *array rather
than sizeof(elemType) in the malloc() argument - the cast does nothing
to help with that issue. It's an extra thing that needs to be changed if
you change the type of 'array'. Casts should always be treated as danger
signs. Using unnecessary casts therefore has two bad consequences: it
slows down searches for the real danger points in the code, and it tends
to make people more comfortable with seeing casts than they should be.
> Casting the result of malloc is neither hard nor error-prone - it's just
> one of these things that some C programmers think is important to avoid
> because using the cast makes your code look like C++.
That issue has never played any role in my reasons for avoiding the
cast, and I've never seen any of the people who advocate avoiding that
cast give that as a reason (with the possible exception of Richard
Heathfield - such a reason would be consistent other thing's he's said,
but I don't remember him ever expressing that reason).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-10 11:32 +0200 |
| Message-ID | <nlt4ns$245$1@dont-email.me> |
| In reply to | #90154 |
On 09/07/16 21:50, James R. Kuyper wrote: > On 07/09/2016 02:27 PM, David Brown 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". > ... >> typedef int elemType; >> ... >> elemType* array = (elemType*) malloc(10 * sizeof(elemType)); > > The alternative I (and others) recommend is: > > elemType* array = malloc(10* sizeof *array); > > It doesn't make much difference here, where the call to malloc() occurs > during the initialization of 'array'. However, it is quite common for > the declaration of the variable to be well separated from the assignment > statement; particularly if it's a member of a struct or union. In those > cases it's a big advantage to be able to confirm that the argument to > malloc() is correct, without having to find the declaration of the variable. I can see, in such cases, the convenience of using "sizeof *array" rather than "sizeof elemType" in the argument to malloc. But I don't see the advantage in omitting the cast on the return of malloc. In fact, I see it as a disadvantage. Others have pointed out that if you have: int* p; p = (int*) malloc(10 * sizeof *p); and then change "int* p;" to "double* p;", then you get a compile-time error message. To some, this seems like an inconvenience. To me, it is a /good/ thing. If I am changing some code to work with doubles rather than ints, I expect to go through a good deal of that code, either changing things or at least checking things to make sure the code is still correct after such a major change. At a minimum, there is a very good chance that there will be other variables defined whose types also need to be changed. Compiler errors like this are a help in ensuring I don't forget parts of the this checking process. When making such changes, it is often handy to change the names of the key variables - precisely to force compiler errors if the code has not been checked. And if the code is written in such a way that it will work happily as is, and it is likely that the types to be allocated will be changed, then a typedef with an appropriate name handles that fine. > > If there is any danger of your code being compiled in C90 mode, then the > cast can mask an error if you forgot to #include <stdlib.h>. I sometimes have to deal with very old compilers that are C90 only (or perhaps don't even handle that). But I don't forget to include the relevant headers - and I check such code using other tools (gcc can be a very handy "linter"). Just because C90 or K&R C allows looser code, such as omitting function declarations, does not mean people should write such code even if their work will be compiled in by C90 or K&R tools. > Code can > be explicitly protected from compiling in C90 mode by testing the value > of __STDC_VERSION__, and it can be implicitly protected by making use of > features that were new in C99 or C2011, and constraint violations or > syntax errors in C90. Such protection renders that issue less important > - but that seems to me to be an excessively subtle way to avoid that > problem. Just write the code correctly, with the limitations needed for C90 - then it will work in all versions of C. Sometimes checking the standard version can be a useful thing, but it can usually be hidden in macros. I have an include file I regularly use that defines "static_assert" to be "_Static_assert" in C11 mode (and leaves it untouched for C++11 mode), and somewhat ugly but useful typedef macro for other C (or C++) standards. > > The cast serves no useful purpose in C; it specifies a conversion that > would have occurred anyway without the cast. Keeping the amount of > memory allocated consistent with the type of the pointer is the key > point, and that's dealt with completely by using sizeof *array rather > than sizeof(elemType) in the malloc() argument - the cast does nothing > to help with that issue. It's an extra thing that needs to be changed if > you change the type of 'array'. If the type of "array" changes, there are usually many things that also need to be changed - making the change in the cast is negligible. Realistically, how often do you actually /need/ to change the type of the pointer here? Types that get used for malloc are usually quite important in a piece of code - I don't think they are things that change very much. (You might be allocating structs, and change the details of those structs, but that does not affect the code here.) > Casts should always be treated as danger > signs. Using unnecessary casts therefore has two bad consequences: it > slows down searches for the real danger points in the code, and it tends > to make people more comfortable with seeing casts than they should be. Yes, casts are an indication that you are doing something odd here. And they can be a risk if the types used get changed, hiding errors or giving incorrect results. But they can also be an aid to the reader in making conversions explicit. And if there is anything that should be treated as dangerous in C programming, it is "malloc". > >> Casting the result of malloc is neither hard nor error-prone - it's just >> one of these things that some C programmers think is important to avoid >> because using the cast makes your code look like C++. > > That issue has never played any role in my reasons for avoiding the > cast, and I've never seen any of the people who advocate avoiding that > cast give that as a reason (with the possible exception of Richard > Heathfield - such a reason would be consistent other thing's he's said, > but I don't remember him ever expressing that reason). > I did not mean to imply that you were one of these "some C programmers". I know your reasons for preferring to avoid the cast here are technical and reasoned.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-10 16:01 -0400 |
| Message-ID | <nlu9j4$1v8$1@dont-email.me> |
| In reply to | #90171 |
On 07/10/2016 05:32 AM, David Brown wrote: > On 09/07/16 21:50, James R. Kuyper wrote: >> On 07/09/2016 02:27 PM, David Brown wrote: ... >>> Casting the return value from malloc is not "a bad idea". >> ... >>> typedef int elemType; >>> ... >>> elemType* array = (elemType*) malloc(10 * sizeof(elemType)); >> >> The alternative I (and others) recommend is: >> >> elemType* array = malloc(10* sizeof *array); >> >> It doesn't make much difference here, where the call to malloc() occurs >> during the initialization of 'array'. However, it is quite common for >> the declaration of the variable to be well separated from the assignment >> statement; particularly if it's a member of a struct or union. In those >> cases it's a big advantage to be able to confirm that the argument to >> malloc() is correct, without having to find the declaration of the variable. > > I can see, in such cases, the convenience of using "sizeof *array" > rather than "sizeof elemType" in the argument to malloc. > > But I don't see the advantage in omitting the cast on the return of > malloc. In fact, I see it as a disadvantage. Others have pointed out > that if you have: > > int* p; > > p = (int*) malloc(10 * sizeof *p); > > and then change "int* p;" to "double* p;", then you get a compile-time > error message. To some, this seems like an inconvenience. To me, it is > a /good/ thing. If I am changing some code to work with doubles rather > than ints, I expect to go through a good deal of that code, either > changing things or at least checking things to make sure the code is > still correct after such a major change. At a minimum, there is a very > good chance that there will be other variables defined whose types also > need to be changed. Compiler errors like this are a help in ensuring I > don't forget parts of the this checking process. ... But why go out of your way to make sure that you have to waste your time examining this piece of code, when it would otherwise be one of the few pieces of code that would not need any such attention? The cast is the only reason this line of code would need attention - without the cast, you would be free to concentrate your attention on the places where it's really needed. >> If there is any danger of your code being compiled in C90 mode, then the >> cast can mask an error if you forgot to #include <stdlib.h>. > > I sometimes have to deal with very old compilers that are C90 only (or > perhaps don't even handle that). But I don't forget to include the > relevant headers ... ... > Just write the code correctly, Personally, I can't imagine that there is anyone who is completely incapable of making mistakes, but if you honestly feel that's an accurate description of yourself, I'm not going to attempt to gainsay you. People who never make mistakes often have trouble understanding the coping mechanisms of people who have the normal human tendency to occasionally make mistakes. >> The cast serves no useful purpose in C; it specifies a conversion that >> would have occurred anyway without the cast. Keeping the amount of >> memory allocated consistent with the type of the pointer is the key >> point, and that's dealt with completely by using sizeof *array rather >> than sizeof(elemType) in the malloc() argument - the cast does nothing >> to help with that issue. It's an extra thing that needs to be changed if >> you change the type of 'array'. > > If the type of "array" changes, there are usually many things that also > need to be changed - making the change in the cast is negligible. This line of code only needs to be changed because it contains that cast. It would otherwise be completely unnecessary to pay any new attention to it when the pointed-at type changes. Therefore, the admittedly small amount of time spent fixing the cast serves only to distract you from the other lines of code that really need your attention. > Realistically, how often do you actually /need/ to change the type of > the pointer here? Not very often. However, the cast wastes small amounts of space and time, both when initially written, and whenever maintenance is needed. At the very least, competent programmers who treat casts as warning signs are going to waste their time trying to figure out what justifies marking this line with such a warning. If there were any corresponding benefit, it might be more important than those costs. But I've never heard any valid benefit claimed for it other than C++ compatibility - which I'm quite happy to concede is valid on those rare occasions when it's a relevant concern. >> Casts should always be treated as danger >> signs. Using unnecessary casts therefore has two bad consequences: it >> slows down searches for the real danger points in the code, and it tends >> to make people more comfortable with seeing casts than they should be. > > Yes, casts are an indication that you are doing something odd here. And > they can be a risk if the types used get changed, hiding errors or > giving incorrect results. But they can also be an aid to the reader in > making conversions explicit. I don't see how making the conversions explicit is a benefit - implicit conversions are implicit precisely because they are generically safe conversions, and this is a prime example. Putting up a big warning sign (which is how a cast should always be treated) gives the false impression that this is a dangerous conversion. > And if there is anything that should be treated as dangerous in C > programming, it is "malloc". Yes - which is why making sure that it's argument is correct is very important. The cast does nothing whatsoever to make malloc() any safer, and it does not warn about the actual danger associated with malloc(), which is that the size argument might be incorrect. The recommended idiom guarantees that he size is correct. >>> Casting the result of malloc is neither hard nor error-prone - it's just >>> one of these things that some C programmers think is important to avoid >>> because using the cast makes your code look like C++. >> >> That issue has never played any role in my reasons for avoiding the >> cast, and I've never seen any of the people who advocate avoiding that >> cast give that as a reason (with the possible exception of Richard >> Heathfield - such a reason would be consistent other thing's he's said, >> but I don't remember him ever expressing that reason). >> > > I did not mean to imply that you were one of these "some C programmers". But you quite clearly implied that there were some such programmers, and my comment was intended to present evidence that, as far as I can tell, there are no such programmers. I've never heard anyone advocate this policy for any reason even remotely resembling that one. They could be lying, but it's impolite to suggest so in the absence of evidence that they are lying. The reasons that have been presented for this policy are sufficiently good that there's not need to assume that anyone is promoting it for the bad reasons you suggest.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-11 10:07 +0200 |
| Message-ID | <nlvk42$m4u$1@dont-email.me> |
| In reply to | #90183 |
On 10/07/16 22:01, James Kuyper wrote: > On 07/10/2016 05:32 AM, David Brown wrote: >> On 09/07/16 21:50, James R. Kuyper wrote: >>> On 07/09/2016 02:27 PM, David Brown wrote: > ... >>>> Casting the return value from malloc is not "a bad idea". >>> ... >>>> typedef int elemType; >>>> ... >>>> elemType* array = (elemType*) malloc(10 * sizeof(elemType)); >>> >>> The alternative I (and others) recommend is: >>> >>> elemType* array = malloc(10* sizeof *array); >>> >>> It doesn't make much difference here, where the call to malloc() occurs >>> during the initialization of 'array'. However, it is quite common for >>> the declaration of the variable to be well separated from the assignment >>> statement; particularly if it's a member of a struct or union. In those >>> cases it's a big advantage to be able to confirm that the argument to >>> malloc() is correct, without having to find the declaration of the variable. >> >> I can see, in such cases, the convenience of using "sizeof *array" >> rather than "sizeof elemType" in the argument to malloc. >> >> But I don't see the advantage in omitting the cast on the return of >> malloc. In fact, I see it as a disadvantage. Others have pointed out >> that if you have: >> >> int* p; >> >> p = (int*) malloc(10 * sizeof *p); >> >> and then change "int* p;" to "double* p;", then you get a compile-time >> error message. To some, this seems like an inconvenience. To me, it is >> a /good/ thing. If I am changing some code to work with doubles rather >> than ints, I expect to go through a good deal of that code, either >> changing things or at least checking things to make sure the code is >> still correct after such a major change. At a minimum, there is a very >> good chance that there will be other variables defined whose types also >> need to be changed. Compiler errors like this are a help in ensuring I >> don't forget parts of the this checking process. ... > > But why go out of your way to make sure that you have to waste your time > examining this piece of code, when it would otherwise be one of the few > pieces of code that would not need any such attention? The cast is the > only reason this line of code would need attention - without the cast, > you would be free to concentrate your attention on the places where it's > really needed. No, the cast is the only reason this line of code would need /changed/ - but it still needs /attention/. That is the key point. > >>> If there is any danger of your code being compiled in C90 mode, then the >>> cast can mask an error if you forgot to #include <stdlib.h>. >> >> I sometimes have to deal with very old compilers that are C90 only (or >> perhaps don't even handle that). But I don't forget to include the >> relevant headers ... > ... >> Just write the code correctly, > > Personally, I can't imagine that there is anyone who is completely > incapable of making mistakes, but if you honestly feel that's an > accurate description of yourself, I'm not going to attempt to gainsay you. > People who never make mistakes often have trouble understanding the > coping mechanisms of people who have the normal human tendency to > occasionally make mistakes. Oh, I make mistakes often enough! But there are some kinds of mistakes that I don't make - and a good many kinds of mistakes that get caught by my tools if I /do/ make them. I'm a great fan of static error checking, and use whatever warning checking I can from my tools. And in cases like this, where C90 allows you to be laxer about your include files than C99, it is a simply matter to write your code in a way that is compatible with C90 and C99, then check it with a C99 compiler - even if the final delivery is for C90. So for this situation, you really can "just write the code correctly" (while leaving plenty of scope for other mistakes - after all, you want paid for that maintenance contract too!) > >>> The cast serves no useful purpose in C; it specifies a conversion that >>> would have occurred anyway without the cast. Keeping the amount of >>> memory allocated consistent with the type of the pointer is the key >>> point, and that's dealt with completely by using sizeof *array rather >>> than sizeof(elemType) in the malloc() argument - the cast does nothing >>> to help with that issue. It's an extra thing that needs to be changed if >>> you change the type of 'array'. >> >> If the type of "array" changes, there are usually many things that also >> need to be changed - making the change in the cast is negligible. > > This line of code only needs to be changed because it contains that > cast. It would otherwise be completely unnecessary to pay any new > attention to it when the pointed-at type changes. Therefore, the > admittedly small amount of time spent fixing the cast serves only to > distract you from the other lines of code that really need your attention. > >> Realistically, how often do you actually /need/ to change the type of >> the pointer here? > > Not very often. However, the cast wastes small amounts of space and > time, both when initially written, and whenever maintenance is needed. > At the very least, competent programmers who treat casts as warning > signs are going to waste their time trying to figure out what justifies > marking this line with such a warning. If there were any corresponding > benefit, it might be more important than those costs. But I've never > heard any valid benefit claimed for it other than C++ compatibility - > which I'm quite happy to concede is valid on those rare occasions when > it's a relevant concern. > >>> Casts should always be treated as danger >>> signs. Using unnecessary casts therefore has two bad consequences: it >>> slows down searches for the real danger points in the code, and it tends >>> to make people more comfortable with seeing casts than they should be. >> >> Yes, casts are an indication that you are doing something odd here. And >> they can be a risk if the types used get changed, hiding errors or >> giving incorrect results. But they can also be an aid to the reader in >> making conversions explicit. > > I don't see how making the conversions explicit is a benefit - implicit > conversions are implicit precisely because they are generically safe > conversions, and this is a prime example. Putting up a big warning sign > (which is how a cast should always be treated) gives the false > impression that this is a dangerous conversion. > I understand your position here, though I don't fully agree with it. Perhaps part of the difference of opinion is due to the type of programming I do, which is small-systems embedded development. For many C programmers, a very large proportion of your numerical types are just "int", or "double" for floating point. In my type of work, a great deal of the data has to be exact types - I use "uint8_t", "int16_t", etc., far more than "int". Casts are much more common in such code, and can be about simply making the conversions explicit for clarification, or about making sure things will work correctly on a different systems (including some annoying 8-bit compilers that don't always follow the C rules for integer promotion). >> And if there is anything that should be treated as dangerous in C >> programming, it is "malloc". > > Yes - which is why making sure that it's argument is correct is very > important. The cast does nothing whatsoever to make malloc() any safer, > and it does not warn about the actual danger associated with malloc(), > which is that the size argument might be incorrect. The recommended > idiom guarantees that he size is correct. Of course it is important that the size argument is correct. I don't see that as the biggest danger when dealing with malloc. But again, this could be coloured by my experience and work - for most of the systems I deal with, general dynamic memory is something to be avoided wherever possible. Memory leaks are often not a serious problem on short run-time PC software, but they are out of the question in embedded systems that run for years. > >>>> Casting the result of malloc is neither hard nor error-prone - it's just >>>> one of these things that some C programmers think is important to avoid >>>> because using the cast makes your code look like C++. >>> >>> That issue has never played any role in my reasons for avoiding the >>> cast, and I've never seen any of the people who advocate avoiding that >>> cast give that as a reason (with the possible exception of Richard >>> Heathfield - such a reason would be consistent other thing's he's said, >>> but I don't remember him ever expressing that reason). >>> >> >> I did not mean to imply that you were one of these "some C programmers". > > But you quite clearly implied that there were some such programmers, and > my comment was intended to present evidence that, as far as I can tell, > there are no such programmers. I've never heard anyone advocate this > policy for any reason even remotely resembling that one. They could be > lying, but it's impolite to suggest so in the absence of evidence that > they are lying. The reasons that have been presented for this policy are > sufficiently good that there's not need to assume that anyone is > promoting it for the bad reasons you suggest. > I /have/ seen such attitudes from both C and C++ programmers. But I was wrong to imply that it is a common attitude, or that it might apply to anyone here.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-11 08:15 -0400 |
| Message-ID | <nm02k9$7bq$1@dont-email.me> |
| In reply to | #90193 |
On 07/11/2016 04:07 AM, David Brown wrote: > On 10/07/16 22:01, James Kuyper wrote: >> On 07/10/2016 05:32 AM, David Brown wrote: ... >>> But I don't see the advantage in omitting the cast on the return of >>> malloc. In fact, I see it as a disadvantage. Others have pointed out >>> that if you have: >>> >>> int* p; >>> >>> p = (int*) malloc(10 * sizeof *p); >>> >>> and then change "int* p;" to "double* p;", then you get a compile-time >>> error message. To some, this seems like an inconvenience. To me, it is >>> a /good/ thing. If I am changing some code to work with doubles rather >>> than ints, I expect to go through a good deal of that code, either >>> changing things or at least checking things to make sure the code is >>> still correct after such a major change. At a minimum, there is a very >>> good chance that there will be other variables defined whose types also >>> need to be changed. Compiler errors like this are a help in ensuring I >>> don't forget parts of the this checking process. ... >> >> But why go out of your way to make sure that you have to waste your time >> examining this piece of code, when it would otherwise be one of the few >> pieces of code that would not need any such attention? The cast is the >> only reason this line of code would need attention - without the cast, >> you would be free to concentrate your attention on the places where it's >> really needed. > > No, the cast is the only reason this line of code would need /changed/ - > but it still needs /attention/. That is the key point. And it's precisely that point I'm disputing: the fact that the data type has changed provides no reason why that particular line needs any of your attention. It was deliberately written in such a way as to make the type irrelevant. Time spent checking it is wasted - you should spend that time checking the lines where the type actually matters.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-11 06:53 -0700 |
| Message-ID | <d31ce5fb-3d80-4edf-b0cb-4a3bae6a4c65@googlegroups.com> |
| In reply to | #90203 |
On Monday, July 11, 2016 at 1:15:14 PM UTC+1, James Kuyper wrote: > > And it's precisely that point I'm disputing: the fact that the data type > has changed provides no reason why that particular line needs any of > your attention. It was deliberately written in such a way as to make the > type irrelevant. Time spent checking it is wasted - you should spend > that time checking the lines where the type actually matters. > We need ten floats for some reason. We then decide to shift the calculation into double precision. So how many doubles do we need? Usually, we'll still need ten. But not always. Say they are coefficients in a series, the tenth of which is about FLT_EPSILON. Clearly, we're going to have to add a few more terms to get the value down to DBL_EPSILON. That's what David and I mean about needing to check all the code by hand.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-11 10:35 -0600 |
| Message-ID | <1b37ngjfpc.fsf@pfeifferfamily.net> |
| In reply to | #90210 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, July 11, 2016 at 1:15:14 PM UTC+1, James Kuyper wrote: >> >> And it's precisely that point I'm disputing: the fact that the data type >> has changed provides no reason why that particular line needs any of >> your attention. It was deliberately written in such a way as to make the >> type irrelevant. Time spent checking it is wasted - you should spend >> that time checking the lines where the type actually matters. >> > We need ten floats for some reason. > We then decide to shift the calculation into double precision. > So how many doubles do we need? Usually, we'll still need ten. But not always. > Say they are coefficients in a series, the tenth of which is about FLT_EPSILON. > Clearly, we're going to have to add a few more terms to get the value > down to DBL_EPSILON. > > That's what David and I mean about needing to check all the code by hand. This is moving the goalposts. You've gone from "changing the type", in which case the idiom covers you without thought, to "changing the type and the number of elements", in which case you do need to change the 10. But of course real code shouldn't have had a 10 there in the first place, since the constant is almost surely also used for things like index bounds. There should have been a #define NUM_ELEM 10 which, when you change it to 'a few more' also takes care of that line as well as any place you're checking the bounds. I used to tell my students that every keystroke is an opportunity to introduce a new bug, so make as few of them as possible. If they had any numeric constants other than -1, 0, or 1 that weren't #defined they could expect to lose a point.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-11 09:48 -0700 |
| Message-ID | <e36d885b-9144-4bef-a268-fad330b46d84@googlegroups.com> |
| In reply to | #90213 |
On Monday, July 11, 2016 at 5:35:21 PM UTC+1, Joe Pfeiffer wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Monday, July 11, 2016 at 1:15:14 PM UTC+1, James Kuyper wrote: > >> > >> And it's precisely that point I'm disputing: the fact that the data type > >> has changed provides no reason why that particular line needs any of > >> your attention. It was deliberately written in such a way as to make the > >> type irrelevant. Time spent checking it is wasted - you should spend > >> that time checking the lines where the type actually matters. > >> > > We need ten floats for some reason. > > We then decide to shift the calculation into double precision. > > So how many doubles do we need? Usually, we'll still need ten. But not always. > > Say they are coefficients in a series, the tenth of which is about FLT_EPSILON. > > Clearly, we're going to have to add a few more terms to get the value > > down to DBL_EPSILON. > > > > That's what David and I mean about needing to check all the code by hand. > > This is moving the goalposts. You've gone from "changing the type", in > which case the idiom covers you without thought, to "changing the type > and the number of elements", in which case you do need to change the 10. > When we change the precision, we also change the behaviour of code when we approach the limits. In this case, hypothetically, the result is a number scaled to be about unity, and the array contains terms of descending magnitude which are summed to achieve the result. So if our results are single precision floats, we can stop when the value goes below FLT_EPSILON or thereabout, and we might know that will happen within ten steps. If we move to double, we've got to decide whether we need more accuracy. Probably the reason for the change is that we do. So we'll need more steps. But the change is a consequence of changing the type.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-11 11:02 -0700 |
| Message-ID | <lny458jbod.fsf@kst-u.example.com> |
| In reply to | #90214 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> When we change the precision, we also change the behaviour of code
> when we approach the limits. In this case, hypothetically, the result
> is a number scaled to be about unity, and the array contains terms of
> descending magnitude which are summed to achieve the result. So if our
> results are single precision floats, we can stop when the value goes
> below FLT_EPSILON or thereabout, and we might know that will happen
> within ten steps.
> If we move to double, we've got to decide whether we need more
> accuracy. Probably the reason for the change is that we do. So we'll
> need more steps.
>
> But the change is a consequence of changing the type.
And casting the result of malloc() is your solution?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web