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 3 of 18 — ← Prev page 1 2 [3] 4 5 … 18 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-11 11:01 -0700 |
| Message-ID | <ln37ngkqaj.fsf@kst-u.example.com> |
| In reply to | #90213 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
[...]
> 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.
That can easily be taken to extremes. *Some* verbosity can make code
less error-prone. I'm thinking in particular of using { and } even
where they aren't strictly required, but there are other examples.
> If they had
> any numeric constants other than -1, 0, or 1 that weren't #defined they
> could expect to lose a point.
Again, I wouldn't go quite that far -- but I would say that if you're
using a numeric constant other than 0 or 1 (even -1), you should pause
for a moment to think about whether it should be given a name.
Sometimes the answer will be no.
--
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 | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-11 13:03 -0600 |
| Message-ID | <1by458hua9.fsf@pfeifferfamily.net> |
| In reply to | #90219 |
Keith Thompson <kst-u@mib.org> writes:
> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> [...]
>> 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.
>
> That can easily be taken to extremes. *Some* verbosity can make code
> less error-prone. I'm thinking in particular of using { and } even
> where they aren't strictly required, but there are other examples.
True, and I'm not quite as dogmatic about keystrokes as that saying
makes it sound. I say it when I see programs written by
copy-and-pasting ten lines of code to three different places instead of
writing a function.
>> If they had
>> any numeric constants other than -1, 0, or 1 that weren't #defined they
>> could expect to lose a point.
>
> Again, I wouldn't go quite that far -- but I would say that if you're
> using a numeric constant other than 0 or 1 (even -1), you should pause
> for a moment to think about whether it should be given a name.
> Sometimes the answer will be no.
It's a *lot* easier to get a student who's formed the habit of always
giving a constant a name to maybe lay off a bit than to give one who
never uses a #define to start.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-11 10:57 -0700 |
| Message-ID | <ln7fcskqfw.fsf@kst-u.example.com> |
| 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.
Say you change a type from integer to floating-point, or vice versa.
Among other things, you'll probably need to check all division
operators on that type, since the semantics are different. There are
probably no casts to help you find them.
If you change a type, you'll probably have to change all the
affected code anyway. Using casts on malloc() calls to remind you
to check those particular calls is a trick with a very low payoff,
and a non-zero cost both in added complexity and in making casts
(which *should* be a warning that something odd is going on) seem
normal and harmless.
And if you're dealing with any code written by other people,
you'll probably have to deal with castless malloc() calls anyway,
so I suggest you get used to 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 | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-27 13:29 +0100 |
| Message-ID | <o1ejje$fsv$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #90183 |
In article <nlu9j4$1v8$1@dont-email.me>, James Kuyper <jameskuyper@verizon.net> 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. Strangely enough many environments have "coding conventions" that stimulate the use of casts, in particular by requiring that code should pass the compiler without warnings, which entices juniors to sprinkle code with casts without understanding what the warning was all about. Instead the code conventions should state that any code that contains casts should be separated out in an "unsafe" library (or include file for macro's). Only senior programmers (in small teams, say less than a dozen, only the master programmer) are allowed to make changes to the unsafe library. malloc is also a candidate for such restriction. With respect to warnings, it should state that warnings must be accounted for in a separate section appendix or document, with the explicit condition that the use of casts to suppress warnings is forbidden. This prevents the dangerous situation that a senior introduces a cast hiding a dangerous situation for a junior that is later to maintain the code. This "warning summary" could become the single most important documents for later maintainers. It also stimulates way to code without the casts, which is almost always possible. > >>> 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. I couldn't agree more. The important notion is that you overrule the compiler. That shouldn't be taken lightly. > >> 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. > Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-11-27 14:07 +0100 |
| Message-ID | <20161127140729.6eb586ca@maxa-pc> |
| In reply to | #97560 |
On Sun, 27 Nov 2016 13:29:34 +0100 (CET) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote: > In article <nlu9j4$1v8$1@dont-email.me>, > James Kuyper <jameskuyper@verizon.net> 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. > > Strangely enough many environments have "coding conventions" that > stimulate the use of casts, in particular by requiring that code > should pass the compiler without warnings, which entices juniors to > sprinkle code with casts without understanding what the warning was > all about. Instead the code conventions should state that any code > that contains casts should be separated out in an "unsafe" library > (or include file for macro's). That is why I like more gcc then g++. No need for casts ;p -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-10 13:05 +0100 |
| Message-ID | <nltdln$tbv$1@dont-email.me> |
| In reply to | #90154 |
On 09/07/16 20:50, James R. Kuyper wrote:
> On 07/09/2016 02:27 PM, David Brown wrote:
<snip>
>
>> 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).
My reason for avoiding the cast is two-fold:
1) it does nothing good AND doesn't stop anything bad from happening
(and in my view ALL code should do one or the other);
2) it can, under some circumstances, make something bad happen.
I see no value in jumping through hoops to make C look non-C++-like. In
C++, you would almost never use malloc anyway; you'd use the STL
instead. It's true that I tend to use new in creation functions:
T *foo_create(int this, int that, double theother)
{
T *new = malloc(sizeof *new);
if(etc etc
and I won't deny that that choice is deliberate, and with good reason
for the choice: it has on at least one occasion warned me that I've
accidentally invoked a C++ compiler! Nevertheless, I generally choose to
try to write my C code in such a way that it is good C, without worrying
about whether or not it is good (or bad) C++.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-10 05:31 -0700 |
| Message-ID | <70f22209-8567-46e6-9425-70ffb43613bb@googlegroups.com> |
| In reply to | #90174 |
On Sunday, July 10, 2016 at 1:05:20 PM UTC+1, Richard Heathfield wrote:
>
> My reason for avoiding the cast is two-fold:
>
> 1) it does nothing good AND doesn't stop anything bad from happening
> (and in my view ALL code should do one or the other);
> 2) it can, under some circumstances, make something bad happen.
>
> I see no value in jumping through hoops to make C look non-C++-like. In
> C++, you would almost never use malloc anyway; you'd use the STL
> instead. It's true that I tend to use new in creation functions:
>
> T *foo_create(int this, int that, double theother)
> {
> T *new = malloc(sizeof *new);
> if(etc etc
>
> and I won't deny that that choice is deliberate, and with good reason
> for the choice: it has on at least one occasion warned me that I've
> accidentally invoked a C++ compiler! Nevertheless, I generally choose to
> try to write my C code in such a way that it is good C, without worrying
> about whether or not it is good (or bad) C++.
>
You can cut and paste a C function into C++ if it casts malloc().
However the way C++ has gone, the result is compileable but increasingly
unidiomatic C++. A modern C++ programmer would say that malloc()
should immediately be packaged into a unique_ptr. The unique_ptr
s tagged with free and automatically frees the memory when it goes out
of scope, which means that exceptions don't cause memory leaks.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-10 13:42 +0100 |
| Message-ID | <nltfqu$37t$2@dont-email.me> |
| In reply to | #90175 |
On 10/07/16 13:31, Malcolm McLean wrote: <snip> > You can cut and paste a C function into C++ if it casts malloc(). There are a great many ways to program badly, and that's certainly one of them. If you want to use a C function in a C++ program, build a C library. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-11 01:07 +0100 |
| Message-ID | <87r3b12g1h.fsf@bsb.me.uk> |
| In reply to | #90175 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, July 10, 2016 at 1:05:20 PM UTC+1, Richard Heathfield wrote:
>>
>> My reason for avoiding the cast is two-fold:
>>
>> 1) it does nothing good AND doesn't stop anything bad from happening
>> (and in my view ALL code should do one or the other);
>> 2) it can, under some circumstances, make something bad happen.
>>
>> I see no value in jumping through hoops to make C look non-C++-like. In
>> C++, you would almost never use malloc anyway; you'd use the STL
>> instead. It's true that I tend to use new in creation functions:
>>
>> T *foo_create(int this, int that, double theother)
>> {
>> T *new = malloc(sizeof *new);
>> if(etc etc
>>
>> and I won't deny that that choice is deliberate, and with good reason
>> for the choice: it has on at least one occasion warned me that I've
>> accidentally invoked a C++ compiler! Nevertheless, I generally choose to
>> try to write my C code in such a way that it is good C, without worrying
>> about whether or not it is good (or bad) C++.
>>
> You can cut and paste a C function into C++ if it casts malloc().
> However the way C++ has gone, the result is compileable but increasingly
> unidiomatic C++. A modern C++ programmer would say that malloc()
> should immediately be packaged into a unique_ptr.
I doubt that. The good ones might say that about a VLA but it would not
always be idiomatic for malloc, and (given the type of the function in
the post you are replying to) almost certainly wrong in this case.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-09 13:39 -0700 |
| Message-ID | <ln60semtpl.fsf@kst-u.example.com> |
| In reply to | #90150 |
David Brown <david.brown@hesbynett.no> writes:
> 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.
Your defense of the cast seems to be that it's only *slightly*
inconvenient and error-prone.
Why do the cast at all? What advantage does using the cast have over
simply *not* using the cast? Why should I write
some_type *ptr = (some_type*)malloc(sizeof (some_type));
rather than
some_type *ptr = malloc(sizeof *ptr);
? The version with the cast, writing the type name three times,
isn't terribly difficult, and I can certainly manage to do it
correctly if I choose to. But why should I when there's a simpler
and more robust alternative?
> 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();".
Not at all. My reasons for not casting the result of malloc() have
absolutely nothing to do with making my code "look like C++". I avoid
the cast because code without the cast is shorter, cleaner, and more
robust than code with the case.
> 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.
If I needed to write C code that can also be compiled as C++ then sure,
I'd cast the result of malloc(). But that's rarely necessary or
appropriate, given the excellent support C++ has for interfacing to pure
C code.
If there were some advantage to adding the cast, I'd add it. There
isn't, so I don't.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-10 11:53 +0200 |
| Message-ID | <nlt5v7$5me$1@dont-email.me> |
| In reply to | #90157 |
On 09/07/16 22:39, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> 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. > > Your defense of the cast seems to be that it's only *slightly* > inconvenient and error-prone. /I/ don't find it inconvenient or error-prone at all - indeed I think it can help avoid errors. But I think that for those that find it inconvenient or error-prone, it is at most only slightly so. I am not really trying to convince anyone that they should add the cast - people can choose that for themselves. I am trying to explain why /I/ don't think it is a bad idea, and why I use the cast. I think it is wrong to state "casting the result of malloc is a bad idea in C" as though it were a clear rule. I happily accept "many C programmers think that casting the result of malloc is a bad idea" - and there is certainly a fair argument that all else being equal, following common idioms is a good thing for your code. > > Why do the cast at all? What advantage does using the cast have over > simply *not* using the cast? Why should I write > some_type *ptr = (some_type*)malloc(sizeof (some_type)); > rather than > some_type *ptr = malloc(sizeof *ptr); > ? The version with the cast, writing the type name three times, > isn't terribly difficult, and I can certainly manage to do it > correctly if I choose to. But why should I when there's a simpler > and more robust alternative? It becomes relevant when there is a separation between the pointer declaration and the call to malloc. We can simplify by using the "sizeof *ptr" in the argument, to remove one of the differences. ptr = malloc(sizeof *ptr); vs. ptr = (some_type*) malloc(sizeof *ptr) When the type of ptr changes, the first version will continue to compile and the second version will give an error - this is what you mean by "more robust", I think. But if the type of ptr changes, then it is highly likely that a lot of the code in the function will change. An error message here is a /good/ thing - it shows that you have not yet checked that this line of code is still correct despite the major change to the function. In fact, in some cases when changing the type of "ptr" I would also change its name - precisely to force compiler errors as a way of confirming that I have checked all relevant code. (I would then change the name back again, to avoid such changes swamping real code changes when comparing code versions.) Obviously the importance or usefulness of this is going to depend a good deal on the code in question. > >> 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();". > > Not at all. My reasons for not casting the result of malloc() have > absolutely nothing to do with making my code "look like C++". I avoid > the cast because code without the cast is shorter, cleaner, and more > robust than code with the case. > >> 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. > > If I needed to write C code that can also be compiled as C++ then sure, > I'd cast the result of malloc(). But that's rarely necessary or > appropriate, given the excellent support C++ has for interfacing to pure > C code. > > If there were some advantage to adding the cast, I'd add it. There > isn't, so I don't. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-10 04:11 -0700 |
| Message-ID | <842cb86e-47ce-4afd-b45d-6c862029150d@googlegroups.com> |
| In reply to | #90172 |
On Sunday, July 10, 2016 at 10:53:51 AM UTC+1, David Brown wrote: > On 09/07/16 22:39, Keith Thompson wrote: > > It becomes relevant when there is a separation between the pointer > declaration and the call to malloc. We can simplify by using the > "sizeof *ptr" in the argument, to remove one of the differences. > > ptr = malloc(sizeof *ptr); > > vs. > > ptr = (some_type*) malloc(sizeof *ptr) > > > When the type of ptr changes, the first version will continue to compile > and the second version will give an error - this is what you mean by > "more robust", I think. But if the type of ptr changes, then it is > highly likely that a lot of the code in the function will change. An > error message here is a /good/ thing - it shows that you have not yet > checked that this line of code is still correct despite the major change > to the function. > A lot of the time you'll be converting from double to float or vice versa. So most of the code will be OK, but there could easily be subtle epsilons in there, or calls to the wrong versions of math library functions. It needs to be hand-checked. Doing an automatic conversion is dangerous.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-10 08:47 -0400 |
| Message-ID | <nltg4l$42q$1@jstuckle.eternal-september.org> |
| In reply to | #90173 |
On 7/10/2016 7:11 AM, Malcolm McLean wrote: > On Sunday, July 10, 2016 at 10:53:51 AM UTC+1, David Brown wrote: >> On 09/07/16 22:39, Keith Thompson wrote: >> >> It becomes relevant when there is a separation between the pointer >> declaration and the call to malloc. We can simplify by using the >> "sizeof *ptr" in the argument, to remove one of the differences. >> >> ptr = malloc(sizeof *ptr); >> >> vs. >> >> ptr = (some_type*) malloc(sizeof *ptr) >> >> >> When the type of ptr changes, the first version will continue to compile >> and the second version will give an error - this is what you mean by >> "more robust", I think. But if the type of ptr changes, then it is >> highly likely that a lot of the code in the function will change. An >> error message here is a /good/ thing - it shows that you have not yet >> checked that this line of code is still correct despite the major change >> to the function. >> > A lot of the time you'll be converting from double to float or vice versa. > So most of the code will be OK, but there could easily be subtle epsilons > in there, or calls to the wrong versions of math library functions. > > It needs to be hand-checked. Doing an automatic conversion is dangerous. > You can convert a double to a float and vice versa. But you cannot just replace a double * to a float * or vice versa. And yes, you need to hand check it. But it also never hurts for the compiler to help you check. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-10 16:05 -0400 |
| Message-ID | <nlu9r6$1v8$2@dont-email.me> |
| In reply to | #90172 |
On 07/10/2016 05:53 AM, David Brown wrote: .... > It becomes relevant when there is a separation between the pointer > declaration and the call to malloc. We can simplify by using the > "sizeof *ptr" in the argument, to remove one of the differences. > > ptr = malloc(sizeof *ptr); > > vs. > > ptr = (some_type*) malloc(sizeof *ptr) > > > When the type of ptr changes, the first version will continue to compile > and the second version will give an error - this is what you mean by > "more robust", I think. But if the type of ptr changes, then it is > highly likely that a lot of the code in the function will change. An > error message here is a /good/ thing - it shows that you have not yet > checked that this line of code is still correct despite the major change > to the function. But it is a line of code that does not need to be changed, or at least, that is not a reason to bother doing so. So making you waste time reviewing it is a bad thing. > ... In fact, in some cases when changing the type of "ptr" > I would also change its name - precisely to force compiler errors as a > way of confirming that I have checked all relevant code. (I would then > change the name back again, to avoid such changes swamping real code > changes when comparing code versions.) This supposed benefit of the cast would be rendered irrelevant if you're going to take that approach.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-09 17:43 -0600 |
| Message-ID | <1b60sel6mc.fsf@pfeifferfamily.net> |
| In reply to | #90150 |
David Brown <david.brown@hesbynett.no> writes: > 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. Of course, you shouldn't be using sizeof(int) either -- you should be using sizeof(*array) (I would argue that this is a case where the unnecessary parentheses make 10 * sizeof(*array) ). Now the hypothetical change in data type is automatically taken care of.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-09 17:32 -0700 |
| Message-ID | <lnshvil4e4.fsf@kst-u.example.com> |
| In reply to | #90163 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> David Brown <david.brown@hesbynett.no> writes:
[...]
>> 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.
>
> Of course, you shouldn't be using sizeof(int) either -- you should be
> using sizeof(*array) (I would argue that this is a case where the
> unnecessary parentheses make 10 * sizeof(*array) ).
>
> Now the hypothetical change in data type is automatically taken care of.
I'd also question whether an object of pointer type should be called
"array". (In real code, it should probably have a name that corresponds
to what it's used for.)
--
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 | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-09 20:34 -0600 |
| Message-ID | <1b1t32kypi.fsf@pfeifferfamily.net> |
| In reply to | #90164 |
Keith Thompson <kst-u@mib.org> writes: > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >> David Brown <david.brown@hesbynett.no> writes: > [...] >>> 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. >> >> Of course, you shouldn't be using sizeof(int) either -- you should be >> using sizeof(*array) (I would argue that this is a case where the >> unnecessary parentheses make 10 * sizeof(*array) ). >> >> Now the hypothetical change in data type is automatically taken care of. > > I'd also question whether an object of pointer type should be called > "array". (In real code, it should probably have a name that corresponds > to what it's used for.) Of course. I'm assuming the variable name was just picked for the example, not for use in a real program. When I'm teaching, I like to call all my arrays (and memory I'm going to use like an array) 'awry'.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2016-07-10 06:25 +0000 |
| Message-ID | <slrnno3qj3.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #90150 |
On Sat, 2016-07-09, 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++. I dislike that cast, but for me (who otherwise prefers C++) it has more to do with pre-ANSI C, when malloc returned int* (or char*, or whatever it was) and people regularly didn't include the right headers. I remember how nice it was to get void pointers, and how long it took until people started writing safer C using the newer features. > It is much like some C++ that get upset when someone writes "void > foo(void);", because in C++ it "should" be written "void foo();". Yeah; I dislike and avoid that, too. I agree there's an element of psychology to it: showing which group you belong to, proving you don't belong to that /other/ group ... In that way, it's nothing to be very proud of. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-11 08:02 -0700 |
| Message-ID | <b9ad4230-8bee-4630-8a4a-b1d81caad416@googlegroups.com> |
| In reply to | #90170 |
On Sunday, July 10, 2016 at 1:25:49 AM UTC-5, Jorgen Grahn wrote: > I remember how nice it was to get void pointers, and how long it took > until people started writing safer C using the newer features. Unfortunately, void* is used in two very different contexts, which have different implications with regard for how compilers should treat it: 1. It may be used as a "temporary" type to hold a pointer which will later get converted back to its own type prior to use. Casting a pointer to that kind of pointer should not compel a compiler to make any aliasing assumptions. 2. It may be used as a "pointer to raw storage" type, in which case a compiler should presume that an object whose address is cast to such a type will likely be accessed via pointers of other types before it is next accessed directly. While I doubt any such thing would ever be added to the language, it would be helpful if "void" could be used as a type qualifier so that e.g. a "void uint8_t*" could be cast to/from any type like void*, and could be used to access storage in type-agnostic fashion like character pointers. Code which actually needs to work with data of character types could then be made faster if there were a directive to indicate that all uses of character types that need to perform aliasing have been converted to void- qualified equivalents, and platforms which allow chunking optimizations (e.g. using uint64_t* to manipulate groups of eight bytes at once) could use "uint64_t*" to accept pointers to types with compatible alignments without a cast.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-11 11:01 +0000 |
| Message-ID | <57837892.8808984@news.xs4all.nl> |
| In reply to | #90150 |
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. > 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. Never mind the mistakes leaving out the cast might help catch. Those mistakes should be rare, and your compiler should alert you to them anyway, cast or not. No, what casting malloc() does is _damage casts_. A cast is an alert sign. A cast tells you "Something unusual is being done to the type system here! Pay attention!" Like all alert signs, they should only be used when necessary, or people stop paying attention to them. Why do you think people have been clamouring for the reduction in the number of road signs? 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. Now, where is a beginning C programmer most likely to encounter casts? Right, in badly written code which casts malloc(). And how will he learn to interpret the presence of a cast? Right, as "Oh, another malloc() call, or something equally innocuous. I can ignore this." _That_ is the damage casting malloc() does: it makes all _good_ casts look like they're not saying anything. And that's bad, very bad, because a cast placed where it _is_ needed says something very important indeed. And, in the end, there's the KISS principle: you may think the cast does no harm, but what's certain is that it does no _good_. So leave it out. > Casting the result of malloc is neither hard nor error-prone Indeed it isn't - it's very simple, it's wrong, and it leads to errors elsewhere. > 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. Whereas IME, that is almost always the case. Richard
[toc] | [prev] | [next] | [standalone]
Page 3 of 18 — ← Prev page 1 2 [3] 4 5 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web