Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90631 > unrolled thread
| Started by | Keith Thompson <kst-u@mib.org> |
|---|---|
| First post | 2016-07-19 15:30 -0700 |
| Last post | 2016-07-28 11:40 -0700 |
| Articles | 20 on this page of 303 — 28 participants |
Back to article view | Back to comp.lang.c
A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-19 15:30 -0700
Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-20 09:51 +0530
Re: A glitch regarding the usual malloc() idiom "Charles Richmond" <numerist@aquaporin4.com> - 2016-07-20 00:07 -0500
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 01:11 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 10:09 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 02:27 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 10:44 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 03:01 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 11:17 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 04:19 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 12:29 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 04:51 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 13:01 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 05:43 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 15:48 +0100
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-20 08:20 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 16:31 +0100
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-20 08:49 -0700
Re: A glitch regarding the usual malloc() idiom "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-20 13:00 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 18:23 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-20 14:17 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 06:29 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 15:51 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 01:41 +0100
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-21 02:05 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 19:57 -0700
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 10:14 +0100
Re: A glitch regarding the usual malloc() idiom Rosario19 <Ros@invalid.invalid> - 2016-07-21 11:20 +0200
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-21 02:32 -0700
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 11:09 +0100
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 16:08 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 17:04 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 19:19 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-21 09:44 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 09:05 -0700
Size augments for legacy code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-20 07:22 -0700
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-20 11:10 +0100
Re: A glitch regarding the usual malloc() idiom John Bode <jfbode1029@gmail.com> - 2016-08-04 13:07 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-04 14:02 -0700
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-08-04 22:14 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-04 14:28 -0700
Re: A glitch regarding the usual malloc() idiom John Bode <jfbode1029@gmail.com> - 2016-08-04 15:58 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:29 -0700
Re: A glitch regarding the usual malloc() idiom John Bode <jfbode1029@gmail.com> - 2016-08-05 08:21 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-05 08:38 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 09:32 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-05 10:30 -0700
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-08-05 19:01 +0100
Re: A glitch regarding the usual malloc() idiom crisd <crisdunbar@gmail.com> - 2016-08-05 11:33 -0700
Re: A glitch regarding the usual malloc() idiom John Bode <jfbode1029@gmail.com> - 2016-08-05 12:01 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-05 12:07 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 09:09 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 12:00 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 20:25 +0100
Re: A glitch regarding the usual malloc() idiom Gareth Owen <gwowen@gmail.com> - 2016-07-20 20:38 +0100
Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-20 20:03 +0000
Re: A glitch regarding the usual malloc() idiom Gareth Owen <gwowen@gmail.com> - 2016-07-20 22:31 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 14:42 -0700
Re: A glitch regarding the usual malloc() idiom Gareth Owen <gwowen@gmail.com> - 2016-07-20 23:21 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-20 20:49 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 12:29 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 13:03 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 16:55 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 21:40 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-21 07:16 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-21 09:47 -0700
Re: A glitch regarding the usual malloc() idiom raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:37 +0000
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 03:23 -0700
Re: A glitch regarding the usual malloc() idiom raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:47 +0000
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 13:38 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-23 17:53 -0400
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-24 01:52 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 11:06 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 16:32 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 17:27 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 22:58 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 18:19 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:44 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 20:57 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:11 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:12 -0400
Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 17:28 -0600
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 00:37 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 16:59 -0700
Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 19:32 -0600
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:35 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:14 -0400
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:13 -0400
Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 21:54 -0600
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:08 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 13:09 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:22 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 13:50 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 11:48 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 17:32 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:41 -0400
Re: A glitch regarding the usual malloc() idiom cross@spitfire.i.gajendra.net (Dan Cross) - 2016-07-25 16:35 +0000
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 17:50 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 14:57 -0400
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 19:01 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:14 -0400
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 20:58 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:14 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:16 -0400
Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 19:35 -0600
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-24 09:38 -0700
Re: A glitch regarding the usual malloc() idiom "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-24 12:58 -0400
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 17:28 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:01 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 15:13 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 18:20 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:46 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 20:59 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:21 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:17 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 03:34 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:09 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 13:21 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 11:50 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 17:38 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 14:59 -0400
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 05:28 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 11:52 -0400
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 08:59 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:29 -0400
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 09:39 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 15:00 -0400
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 19:09 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:19 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 03:31 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 21:20 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:10 -0400
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:12 -0400
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-27 09:09 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 09:57 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 11:15 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-28 15:18 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-30 11:59 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-28 21:02 -0400
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-30 12:09 -0700
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-31 14:07 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 16:56 -0700
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-08-01 08:57 -0700
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-27 11:41 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 11:25 -0700
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-24 15:28 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 21:00 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:31 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:21 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-24 19:38 -0700
Re: A glitch regarding the usual malloc() idiom Siri Cruise <chine.bleu@yahoo.com> - 2016-07-24 20:18 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:15 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 07:31 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 11:59 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 10:31 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 18:57 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 15:04 -0400
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 19:14 -0700
Re: A glitch regarding the usual malloc() idiom James Kuyper <jameskuyper@verizon.net> - 2016-07-24 22:49 -0400
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 21:12 -0700
Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 21:58 -0600
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:19 -0400
Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-25 08:34 -0600
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:01 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 08:32 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:03 -0400
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-25 00:24 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 21:01 -0400
Re: A glitch regarding the usual malloc() idiom Ian Collins <ian-news@hotmail.com> - 2016-07-25 17:08 +1200
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:19 -0400
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-25 17:07 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:36 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 10:34 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 15:05 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 12:18 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 16:05 -0400
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-26 01:08 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 12:29 -0400
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-26 09:41 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-26 10:50 -0700
Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-26 18:09 +0000
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 14:43 -0400
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-26 20:25 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 15:33 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-26 21:05 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 16:37 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-26 13:23 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 16:39 -0400
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-26 14:07 -0700
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-26 14:51 -0700
Re: A glitch regarding the usual malloc() idiom Öö Tiib <ootiib@hot.ee> - 2016-07-26 15:17 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 23:26 -0400
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-26 20:46 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 07:52 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 08:47 -0400
Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-27 17:13 +0200
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 12:03 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-27 09:57 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 16:18 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-27 07:58 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 12:05 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 17:18 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 16:20 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-28 07:14 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-28 08:59 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-28 13:37 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-27 09:42 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 16:20 -0400
Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-26 15:31 -0700
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 23:32 -0400
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 07:58 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 08:52 -0400
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-27 11:21 +0100
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 13:34 +0100
Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-27 16:31 +0200
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-27 16:20 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-27 23:36 +0100
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-28 14:51 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 09:26 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 10:54 -0700
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-27 03:12 +0100
Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 23:35 -0400
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-26 20:41 -0700
Re: A glitch regarding the usual malloc() idiom raltbos@xs4all.nl (Richard Bos) - 2016-07-27 15:04 +0000
Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-27 16:05 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-27 08:17 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 09:21 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-27 09:37 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 10:11 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-27 10:21 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 11:34 -0700
Re: A glitch regarding the usual malloc() idiom luser droog <luser.droog@gmail.com> - 2016-07-27 14:46 -0700
Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-27 22:29 +0200
Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-27 20:32 +0200
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 00:22 -0700
Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-28 13:01 +0200
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 04:46 -0700
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-26 12:57 -0700
Re: A glitch regarding the usual malloc() idiom "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-26 16:00 -0400
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 00:08 -0700
Re: A glitch regarding the usual malloc() idiom raltbos@xs4all.nl (Richard Bos) - 2016-07-27 14:58 +0000
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 09:14 -0700
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-27 11:55 -0700
Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-20 19:47 +0000
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 13:09 -0700
Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-20 20:49 +0000
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 14:35 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 09:01 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 08:59 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-20 09:24 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 11:28 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 18:38 -0700
Re: A glitch regarding the usual malloc() idiom Rosario19 <Ros@invalid.invalid> - 2016-07-20 22:10 +0200
Re: A glitch regarding the usual malloc() idiom Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-07-20 16:16 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 19:56 -0700
Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 18:46 +0530
Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-21 17:20 +0000
Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 18:03 +0530
Re: A glitch regarding the usual malloc() idiom James Kuyper <jameskuyper@verizon.net> - 2016-07-21 15:39 -0400
Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 18:04 +0530
Re: A glitch regarding the usual malloc() idiom James Kuyper <jameskuyper@verizon.net> - 2016-07-22 13:44 -0400
Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-23 15:38 +0530
Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-23 15:36 +0530
Re: A glitch regarding the usual malloc() idiom "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-23 13:08 -0400
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-23 13:23 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-23 19:57 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-23 13:03 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 08:06 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 14:17 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 19:45 -0700
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 13:13 +0100
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 19:23 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-21 20:02 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 07:57 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 00:18 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 08:20 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 00:49 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 09:31 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 10:22 +0100
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 12:21 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 17:15 +0100
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-23 19:46 +0100
Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-22 16:43 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-22 09:17 -0700
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 18:21 +0100
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-22 11:05 -0700
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 22:38 +0100
Re: A glitch regarding the usual malloc() idiom James Kuyper <jameskuyper@verizon.net> - 2016-07-22 13:58 -0400
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-22 11:14 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 02:23 -0700
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 12:23 +0100
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 06:44 -0700
Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-22 09:18 -0700
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 17:00 +0100
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-23 19:48 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 10:08 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 10:26 +0100
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 12:12 +0100
Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 12:35 +0100
Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 14:47 +0100
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:37 -0700
Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 09:50 -0700
Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 11:40 -0700
Page 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-04 14:28 -0700 |
| Message-ID | <lnvazgz0k3.fsf@kst-u.example.com> |
| In reply to | #91683 |
BartC <bc@freeuk.com> writes:
> On 04/08/2016 21:07, John Bode wrote:
>> On Wednesday, July 20, 2016 at 4:28:00 AM UTC-5, Malcolm McLean wrote:
>
>>> * does not dereference a pointer when preceded by a sizeof.
>>>
>>
>> With the sole exception of VLAs, sizeof doesn't evaluate its operand
>> *at all*:
>>
>> sizeof a[i]
>>
>> does not perform the subscript operation;
>>
>> sizeof a+b
>>
>> does not perform the addition;
>
> I think it does.
>
>
>> sizeof a&&b
>>
>> does not perform the logical AND operation.
>
> And it does here too. Because they are parsed as (sizeof a)+b and
> (sizeof a)&&b.
Good catch.
Of course
sizeof (a+b)
doesn't perform the addition, which was John's point. (Here the
parentheses are used because they're necessary to get the desired
grouping.)
And I can imagine that such an expression could be useful if you don't
necessarily know the types or sizes of a and b, but you want to know the
size of the common type determined by the usual arithmetic conversions.
--
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 | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-08-04 15:58 -0700 |
| Message-ID | <d2d94a57-5951-4683-844f-ed6bd2899269@googlegroups.com> |
| In reply to | #91683 |
On Thursday, August 4, 2016 at 4:14:19 PM UTC-5, Bart wrote: > On 04/08/2016 21:07, John Bode wrote: > > On Wednesday, July 20, 2016 at 4:28:00 AM UTC-5, Malcolm McLean wrote: > > >> * does not dereference a pointer when preceded by a sizeof. > >> > > > > With the sole exception of VLAs, sizeof doesn't evaluate its operand > > *at all*: > > > > sizeof a[i] > > > > does not perform the subscript operation; > > > > sizeof a+b > > > > does not perform the addition; > > I think it does. > > > > sizeof a&&b > > > > does not perform the logical AND operation. > > And it does here too. Because they are parsed as (sizeof a)+b and > (sizeof a)&&b. > > > -- > Bartc Derp. Par for the course today.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-04 23:29 -0700 |
| Message-ID | <592d7153-ee57-414e-b340-04027edd4098@googlegroups.com> |
| In reply to | #91674 |
On Thursday, August 4, 2016 at 9:08:15 PM UTC+1, John Bode wrote:
> On Wednesday, July 20, 2016 at 4:28:00 AM UTC-5, Malcolm McLean wrote:
>
> > * does not dereference a pointer when preceded by a sizeof.
>
> > That seems to me sufficiently undesirable that it has no place in
> > release-quality C code.
>
> The issue is that using the type name introduces a maintenance burden that
> using the expression doesn't. Imagine you're supporting code on a C89
> implementation that doesn't allow mixed declarations and code, so you have
> to separate the declaration of a pointer from its use in a malloc call:
>
> T *p = NULL;
> int n = 0;
> printf( "Gimme a size: " );
> if ( scanf( "%d", &n ) == 1 )
> {
> p = malloc( sizeof *p * n );
> if ( !p )
> {
> ...
> }
> }
>
OK let's try to maintain this.
We've been instructed to change T to S.
S *p = NULL;
int n = 0;
printf( "Gimme a size: " );
if ( scanf( "%d", &n ) == 1 )
{
p = malloc( sizeof *p * n );
if ( !p )
{
}
for(i=0;i<n;i++)
p[i] = delta_Vroot(a, i, n);
}
So is the code robust or not?
Are you satisfied if it compiles cleanly and without warning?
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-08-05 08:21 -0700 |
| Message-ID | <04805ea3-0f6f-46f5-9579-68f9cf897513@googlegroups.com> |
| In reply to | #91702 |
On Friday, August 5, 2016 at 1:29:52 AM UTC-5, Malcolm McLean wrote:
> On Thursday, August 4, 2016 at 9:08:15 PM UTC+1, John Bode wrote:
> > On Wednesday, July 20, 2016 at 4:28:00 AM UTC-5, Malcolm McLean wrote:
> >
> > > * does not dereference a pointer when preceded by a sizeof.
> >
> > > That seems to me sufficiently undesirable that it has no place in
> > > release-quality C code.
> >
> > The issue is that using the type name introduces a maintenance burden that
> > using the expression doesn't. Imagine you're supporting code on a C89
> > implementation that doesn't allow mixed declarations and code, so you have
> > to separate the declaration of a pointer from its use in a malloc call:
> >
> > T *p = NULL;
> > int n = 0;
> > printf( "Gimme a size: " );
> > if ( scanf( "%d", &n ) == 1 )
> > {
> > p = malloc( sizeof *p * n );
> > if ( !p )
> > {
> > ...
> > }
> > }
> >
> OK let's try to maintain this.
>
> We've been instructed to change T to S.
>
> S *p = NULL;
> int n = 0;
> printf( "Gimme a size: " );
> if ( scanf( "%d", &n ) == 1 )
> {
> p = malloc( sizeof *p * n );
> if ( !p )
> {
> }
>
> for(i=0;i<n;i++)
> p[i] = delta_Vroot(a, i, n);
> }
>
> So is the code robust or not?
> Are you satisfied if it compiles cleanly and without warning?
As far as the *malloc* call is concerned, yes.
Obviously, any code that reads or writes *p will need to be updated if the
type of p changes. It's just that you don't ever need to worry about the
malloc call; it will always allocate enough space for n instances of
T (or S, or Q, or int, or struct omgwtfbbq) without you ever having to
touch it again. It's one less thing to worry about.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-05 08:38 -0700 |
| Message-ID | <lna8grz0n7.fsf@kst-u.example.com> |
| In reply to | #91702 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, August 4, 2016 at 9:08:15 PM UTC+1, John Bode wrote:
>> On Wednesday, July 20, 2016 at 4:28:00 AM UTC-5, Malcolm McLean wrote:
>>
>> > * does not dereference a pointer when preceded by a sizeof.
>>
>> > That seems to me sufficiently undesirable that it has no place in
>> > release-quality C code.
>>
>> The issue is that using the type name introduces a maintenance burden that
>> using the expression doesn't. Imagine you're supporting code on a C89
>> implementation that doesn't allow mixed declarations and code, so you have
>> to separate the declaration of a pointer from its use in a malloc call:
>>
>> T *p = NULL;
>> int n = 0;
>> printf( "Gimme a size: " );
>> if ( scanf( "%d", &n ) == 1 )
>> {
>> p = malloc( sizeof *p * n );
>> if ( !p )
>> {
>> ...
>> }
>> }
>>
> OK let's try to maintain this.
>
> We've been instructed to change T to S.
>
> S *p = NULL;
> int n = 0;
> printf( "Gimme a size: " );
> if ( scanf( "%d", &n ) == 1 )
> {
> p = malloc( sizeof *p * n );
> if ( !p )
> {
> }
>
> for(i=0;i<n;i++)
> p[i] = delta_Vroot(a, i, n);
> }
>
> So is the code robust or not?
> Are you satisfied if it compiles cleanly and without warning?
You'll have to make your point more clearly.
You've changed the type of `p` from `T*` to `S*`, and you've added a for
loop:
for(i=0;i<n;i++)
p[i] = delta_Vroot(a, i, n);
The type of `p[i]` has changed from `T` to `S`. The `delta_Vroot`
function must return a result of type `S` (or a type implicitly
convertible to `S`). If `T` and `S` are not implicitly convertible,
then the compiler will let you know very quickly that the assignment has
become invalid. If they are (say, if they're both numeric types), then
it won't (unless it happens to produce a "possible loss of precision"
warning, but you can't depend on that in general).
The recommended
p = malloc( sizeof *p * n );
idiom doesn't help you to detect the error in the assignment or alert
you that you might need to change it (perhaps to call some function
other than delta_Vroot).
*Nobody ever claimed that it did.*
Using an expression rather than a type name as the operand of sizeof
is not a panacea. If you change the type of a pointer, you still
have to go through any code that uses it to either verify that it's
still correct or change it. The compiler may or may not flag the
places in the code that you need to look at.
If you still want to allocate an array of n objects (now of a
different type), then the recommended idiom just means you don't
have to change the line of code that does the allocation.
What was your point?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-05 09:32 -0700 |
| Message-ID | <43e2dbcd-4759-4e2c-ad08-20d7a29556f1@googlegroups.com> |
| In reply to | #91735 |
On Friday, August 5, 2016 at 4:38:44 PM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > We've been instructed to change T to S.
> >
> > S *p = NULL;
> > int n = 0;
> > printf( "Gimme a size: " );
> > if ( scanf( "%d", &n ) == 1 )
> > {
> > p = malloc( sizeof *p * n );
> > if ( !p )
> > {
> > }
> >
> > for(i=0;i<n;i++)
> > p[i] = delta_Vroot(a, i, n);
> > }
> >
> > So is the code robust or not?
> > Are you satisfied if it compiles cleanly and without warning?
>
> You'll have to make your point more clearly.
>
> You've changed the type of `p` from `T*` to `S*`, and you've added a for
> loop:
>
> for(i=0;i<n;i++)
> p[i] = delta_Vroot(a, i, n);
>
> The type of `p[i]` has changed from `T` to `S`. The `delta_Vroot`
> function must return a result of type `S` (or a type implicitly
> convertible to `S`). If `T` and `S` are not implicitly convertible,
> then the compiler will let you know very quickly that the assignment has
> become invalid. If they are (say, if they're both numeric types), then
> it won't (unless it happens to produce a "possible loss of precision"
> warning, but you can't depend on that in general).
>
I've expanded John's ... ellipsis to put in a "typical bit of code".
We know that we were instructed to change T to S and the compile is clean.
My question is, would that satisfy you? Would you say "job done" or not?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-05 10:30 -0700 |
| Message-ID | <ln60rfyvgd.fsf@kst-u.example.com> |
| In reply to | #91742 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, August 5, 2016 at 4:38:44 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > We've been instructed to change T to S.
>> >
>> > S *p = NULL;
>> > int n = 0;
>> > printf( "Gimme a size: " );
>> > if ( scanf( "%d", &n ) == 1 )
>> > {
>> > p = malloc( sizeof *p * n );
>> > if ( !p )
>> > {
>> > }
>> >
>> > for(i=0;i<n;i++)
>> > p[i] = delta_Vroot(a, i, n);
>> > }
>> >
>> > So is the code robust or not?
>> > Are you satisfied if it compiles cleanly and without warning?
>>
>> You'll have to make your point more clearly.
>>
>> You've changed the type of `p` from `T*` to `S*`, and you've added a for
>> loop:
>>
>> for(i=0;i<n;i++)
>> p[i] = delta_Vroot(a, i, n);
>>
>> The type of `p[i]` has changed from `T` to `S`. The `delta_Vroot`
>> function must return a result of type `S` (or a type implicitly
>> convertible to `S`). If `T` and `S` are not implicitly convertible,
>> then the compiler will let you know very quickly that the assignment has
>> become invalid. If they are (say, if they're both numeric types), then
>> it won't (unless it happens to produce a "possible loss of precision"
>> warning, but you can't depend on that in general).
>>
> I've expanded John's ... ellipsis to put in a "typical bit of code".
>
> We know that we were instructed to change T to S and the compile is clean.
> My question is, would that satisfy you? Would you say "job done" or not?
No. If you change the type of something, you still have to examine the
code that uses it.
If this is meant to be an argument against the recommended malloc idiom
(using an expression rather than a type name as the operand of sizeof),
I don't see how it applies. I think you're making a strawman argument.
Again, nobody has claimed that using `sizeof *p` is a panacea.
The advantages of writing, for example,
p = malloc(N * sizeof *p);
rather than
p = malloc(N * sizeof (type_that_p_points_to));
are that (a) when you read that line, you can see that it
correctly allocates an array of N elements without having to look
up the definition of p (and possibly count the "*"s if it's a
pointer-to-pointer), and (b) *that line* remains correct if the
type of p changes during later maintenance.
I actually consider the first point to be more important, but
opinion can differ on that.
You've argued for some alleged advantages of using the type name.
I found those arguments unconvincing and insufficient to override
the advantages of using an expression.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-05 19:01 +0100 |
| Message-ID | <no2kah$smt$1@dont-email.me> |
| In reply to | #91746 |
On 05/08/2016 18:30, Keith Thompson wrote: > The advantages of writing, for example, > p = malloc(N * sizeof *p); > rather than > p = malloc(N * sizeof (type_that_p_points_to)); > are that (a) when you read that line, you can see that it > correctly allocates an array of N elements without having to look > up the definition of p (and possibly count the "*"s if it's a > pointer-to-pointer), and (b) *that line* remains correct if the > type of p changes during later maintenance. > > I actually consider the first point to be more important, but > opinion can differ on that. > > You've argued for some alleged advantages of using the type name. > I found those arguments unconvincing and insufficient to override > the advantages of using an expression. I've listed the advantages of using the type elsewhere, but I can't find it (I can't remember what thread it was). They're more obvious when the variable name is longer: int* arrayptr = malloc(N * sizeof(*arrayptr)); // (1) int* arrayptr = malloc(N * sizeof(int)); // (2) Both styles require you to write something on the rhs that matches something on the lhs. You're implying that it is easier if this is the variable name, than the name of its type. However there are likely to be many more different variable names than there are types (especially as often the type will be a standard type like in my example). These increase the chances of inadvertently using the wrong variable name with (1). If a line like (1) is copied and pasted elsewhere, then edited to create a new pointer, you have to remember to change both names: int* arrayptr2 = malloc(N * sizeof(*arrayptr)); This may still work by chance, but it's wrong. Doing it with (2): int* arrayptr2 = malloc(N * sizeof(int)); only requires one change when the type is the same as it often is. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | crisd <crisdunbar@gmail.com> |
|---|---|
| Date | 2016-08-05 11:33 -0700 |
| Message-ID | <596ae8fe-0173-4653-a6f3-347f1e266a85@googlegroups.com> |
| In reply to | #91751 |
On Friday, August 5, 2016 at 11:02:02 AM UTC-7, Bart wrote: > On 05/08/2016 18:30, Keith Thompson wrote: > > > The advantages of writing, for example, > > p = malloc(N * sizeof *p); > > rather than > > p = malloc(N * sizeof (type_that_p_points_to)); > > > are that (a) when you read that line, you can see that it > > correctly allocates an array of N elements without having to look > > up the definition of p (and possibly count the "*"s if it's a > > pointer-to-pointer), and (b) *that line* remains correct if the > > type of p changes during later maintenance. > > > > I actually consider the first point to be more important, but > > opinion can differ on that. > > > > You've argued for some alleged advantages of using the type name. > > I found those arguments unconvincing and insufficient to override > > the advantages of using an expression. > > I've listed the advantages of using the type elsewhere, but I can't find > it (I can't remember what thread it was). > > They're more obvious when the variable name is longer: > > int* arrayptr = malloc(N * sizeof(*arrayptr)); // (1) > > int* arrayptr = malloc(N * sizeof(int)); // (2) > > Both styles require you to write something on the rhs that matches > something on the lhs. > > You're implying that it is easier if this is the variable name, than the > name of its type. > > However there are likely to be many more different variable names than > there are types (especially as often the type will be a standard type > like in my example). > > These increase the chances of inadvertently using the wrong variable > name with (1). So you like (2) because it increases your chances of _accidentally_ getting the code correct?? (And yet, of course, not being able to tell by looking at the line of code whether you did indeed get it correct).
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-08-05 12:01 -0700 |
| Message-ID | <822198d6-d406-4022-a652-43bde16f64a0@googlegroups.com> |
| In reply to | #91751 |
On Friday, August 5, 2016 at 1:02:02 PM UTC-5, Bart wrote:
> On 05/08/2016 18:30, Keith Thompson wrote:
>
> > The advantages of writing, for example,
> > p = malloc(N * sizeof *p);
> > rather than
> > p = malloc(N * sizeof (type_that_p_points_to));
>
> > are that (a) when you read that line, you can see that it
> > correctly allocates an array of N elements without having to look
> > up the definition of p (and possibly count the "*"s if it's a
> > pointer-to-pointer), and (b) *that line* remains correct if the
> > type of p changes during later maintenance.
> >
> > I actually consider the first point to be more important, but
> > opinion can differ on that.
> >
> > You've argued for some alleged advantages of using the type name.
> > I found those arguments unconvincing and insufficient to override
> > the advantages of using an expression.
>
> I've listed the advantages of using the type elsewhere, but I can't find
> it (I can't remember what thread it was).
>
> They're more obvious when the variable name is longer:
>
> int* arrayptr = malloc(N * sizeof(*arrayptr)); // (1)
>
> int* arrayptr = malloc(N * sizeof(int)); // (2)
>
> Both styles require you to write something on the rhs that matches
> something on the lhs.
>
> You're implying that it is easier if this is the variable name, than the
> name of its type.
>
> However there are likely to be many more different variable names than
> there are types (especially as often the type will be a standard type
> like in my example).
>
> These increase the chances of inadvertently using the wrong variable
> name with (1).
>
> If a line like (1) is copied and pasted elsewhere, then edited to create
> a new pointer, you have to remember to change both names:
>
> int* arrayptr2 = malloc(N * sizeof(*arrayptr));
>
> This may still work by chance, but it's wrong. Doing it with (2):
>
> int* arrayptr2 = malloc(N * sizeof(int));
>
> only requires one change when the type is the same as it often is.
>
> --
> Bartc
You and Malcolm are introducing all kinds of conditions and situations that
have nothing to do with my original point. I'm not talking about code that
reads or writes *p. I'm not talking about cutting and pasting existing
malloc calls for different variables.
I'm talking about a very specific situation. Once you write
p = malloc( sizeof *p * N );
you are done with *that particular line of code*. It will always do the
right thing as far as allocating enough space for N elements of the
pointed-to type and assigning it to the appropriate pointer, *and* you need
never touch it again in the (admittedly unlikely) event that the type of *p
ever changes.
It's the same reason (well, one of the reasons) we tell people not to cast
the result of malloc; again, you're creating work for yourself that you
don't need to and potentially introducing bugs in the process.
Obviously, if you have code that reads or writes *p, or if you're cutting
and pasting malloc calls for different objects, then OF COURSE you have to
make sure that you change types and names appropriately. I'm not claiming
anything to the contrary.
In my own experience (which may or may not be typical), I have been bitten
multiple times by not keeping types in sync between the declaration of a
pointer and a malloc (or memcpy, or memset, or whatever) call. I find that
using sizeof *p instead of sizeof (T) in those situations causes me less
heartburn overall, and I've recommended that style to others on that basis.
You're free to disagree, just don't argue against claims that I'm not
making.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-05 12:07 -0700 |
| Message-ID | <lnwpjvxcf0.fsf@kst-u.example.com> |
| In reply to | #91751 |
BartC <bc@freeuk.com> writes:
> On 05/08/2016 18:30, Keith Thompson wrote:
>
>> The advantages of writing, for example,
>> p = malloc(N * sizeof *p);
>> rather than
>> p = malloc(N * sizeof (type_that_p_points_to));
>
>> are that (a) when you read that line, you can see that it
>> correctly allocates an array of N elements without having to look
>> up the definition of p (and possibly count the "*"s if it's a
>> pointer-to-pointer), and (b) *that line* remains correct if the
>> type of p changes during later maintenance.
>>
>> I actually consider the first point to be more important, but
>> opinion can differ on that.
>>
>> You've argued for some alleged advantages of using the type name.
>> I found those arguments unconvincing and insufficient to override
>> the advantages of using an expression.
>
> I've listed the advantages of using the type elsewhere, but I can't
> find it (I can't remember what thread it was).
>
> They're more obvious when the variable name is longer:
>
> int* arrayptr = malloc(N * sizeof(*arrayptr)); // (1)
>
> int* arrayptr = malloc(N * sizeof(int)); // (2)
>
> Both styles require you to write something on the rhs that matches
> something on the lhs.
You've moved the goalposts. The original example was a *statement* that
allocates memory for an existing pointer; the declaration of the pointer
might not be immediately visible. (IDEs and smart editors can make it
easier to find the declaration, but not having to find it at all is even
easier.) Your new example is a *declaration* that initializes a newly
defined pointer. That's preferable when it's possible, but sometimes it
isn't.
Here's another example:
int **ptr = malloc(N * sizeof (int*));
For a pointer-to-pointer (for however many levels), the type operand
of the sizeof has to have exactly one fewer "*"s than the type of
the pointer. That's not too hard to get right, but writing
int **ptr = malloc(N * sizeof *ptr);
is simpler and more consistent.
> You're implying that it is easier if this is the variable name, than
> the name of its type.
Yes.
> However there are likely to be many more different variable names than
> there are types (especially as often the type will be a standard type
> like in my example).
>
> These increase the chances of inadvertently using the wrong variable
> name with (1).
That's never been a problem for me. Has it ever been a problem for you,
or are you just reaching for ways it *might* go wrong?
> If a line like (1) is copied and pasted elsewhere, then edited to
> create a new pointer, you have to remember to change both names:
>
> int* arrayptr2 = malloc(N * sizeof(*arrayptr));
Yes. Hopefully you'll be using meaningful names that are easily
distinguishable rather than something artificial like "arrayptr" and
"arrayptr2". (And of course the compiler will catch it if "arrayptr"
doesn't happen to be visible at that point.)
> This may still work by chance, but it's wrong. Doing it with (2):
>
> int* arrayptr2 = malloc(N * sizeof(int));
>
> only requires one change when the type is the same as it often is.
And when the type isn't the same, the compiler won't tell you you've
made a mistake; you'll just allocate the wrong size *and it won't be
obvious by reading the line of code that does the allocation*.
I don't want the correctness of my code to rely on the type "usually"
being the same.
No programming idiom will prevent all possible errors.
If writing the same expression twice is too much of a burden, you can
always write a macro. (Personally I wouldn't bother.)
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-20 09:09 -0700 |
| Message-ID | <lna8hcmgux.fsf@kst-u.example.com> |
| In reply to | #90640 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, July 20, 2016 at 6:07:50 AM UTC+1, Charles Richmond wrote:
>> IMHO, a better choice for the standard would have been... to *forbid* any
>> variable length array type name to be used in sizeof().
>>
> Only types should be passed to sizeof().
> In particular, uninitialised pointers should not be dereferenced
> in a sizeof expression. By a quirk of the language, that happens
> to be legal. But it's very obviously undesirable.
Are you serious about this, or are you just trolling (or, as you
called it downthread, "teasing Richard")?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-20 12:00 -0700 |
| Message-ID | <7d995799-5f23-4784-a62e-ea423de00650@googlegroups.com> |
| In reply to | #90669 |
On Wednesday, July 20, 2016 at 5:09:16 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > On Wednesday, July 20, 2016 at 6:07:50 AM UTC+1, Charles Richmond wrote: > >> IMHO, a better choice for the standard would have been... to *forbid* any > >> variable length array type name to be used in sizeof(). > >> > > Only types should be passed to sizeof(). > > In particular, uninitialised pointers should not be dereferenced > > in a sizeof expression. By a quirk of the language, that happens > > to be legal. But it's very obviously undesirable. > > Are you serious about this, or are you just trolling (or, as you > called it downthread, "teasing Richard")? > It's the double abstraction problem magptr = malloc(40 * sizeof(float)); tells us that we are asking for 160 bytes of memory. In a context where memory take is important, it's helpful to have that information. magptr = malloc(40 * sizeof *magptr); doesn't tell us how many bytes we're asking for, we can't glance at it and translate, because we've put an additional layer of wrapping over it. magptr = malloc(160); has the opposite problem. We know that we're asking for 160 bytes of memory, but we don't know why.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-20 20:25 +0100 |
| Message-ID | <nmoj6s$lm4$1@dont-email.me> |
| In reply to | #90681 |
On 20/07/16 20:00, Malcolm McLean wrote: > On Wednesday, July 20, 2016 at 5:09:16 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> On Wednesday, July 20, 2016 at 6:07:50 AM UTC+1, Charles Richmond wrote: >>>> IMHO, a better choice for the standard would have been... to *forbid* any >>>> variable length array type name to be used in sizeof(). >>>> >>> Only types should be passed to sizeof(). >>> In particular, uninitialised pointers should not be dereferenced >>> in a sizeof expression. By a quirk of the language, that happens >>> to be legal. But it's very obviously undesirable. >> >> Are you serious about this, or are you just trolling (or, as you >> called it downthread, "teasing Richard")? >> > It's the double abstraction problem > > magptr = malloc(40 * sizeof(float)); > > tells us that we are asking for 160 bytes of memory. No, it doesn't. It tells us we're asking for 40 * sizeof(float) bytes of memory. > In a context > where memory take is important, it's helpful to have that information. > > magptr = malloc(40 * sizeof *magptr); > > doesn't tell us how many bytes we're asking for, Yes, it does. It tells us we're asking for 40 * sizeof *magptr bytes of memory. > we can't glance at > it and translate, because we've put an additional layer of wrapping > over it. Now try this: float *magptr = malloc(40 * sizeof *magptr); This gives precisely the same information as your example, and has the added benefit of being robust in the face of changes to magptr's type. -- 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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-07-20 20:38 +0100 |
| Message-ID | <87k2gg2j8c.fsf@gmail.com> |
| In reply to | #90683 |
Richard Heathfield <rjh@cpax.org.uk> writes: >> It's the double abstraction problem >> >> magptr = malloc(40 * sizeof(float)); >> >> tells us that we are asking for 160 bytes of memory. > > No, it doesn't. It tells us we're asking for 40 * sizeof(float) bytes > of memory. Supremely confident idiot.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-07-20 20:03 +0000 |
| Message-ID | <slrn3vfsnovm8l.c9q.ike@iceland.freeshell.org> |
| In reply to | #90687 |
On 2016-07-20, Gareth Owen <gwowen@gmail.com> wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >>> It's the double abstraction problem >>> >>> magptr = malloc(40 * sizeof(float)); >>> >>> tells us that we are asking for 160 bytes of memory. >> >> No, it doesn't. It tells us we're asking for 40 * sizeof(float) bytes >> of memory. > > Supremely confident idiot. Your suggestion that RH's an idiot tells us more about you than it tells us about RH. Can you explain what's wrong with RH's remark?
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-07-20 22:31 +0100 |
| Message-ID | <87inw0vvwk.fsf@gmail.com> |
| In reply to | #90690 |
Ike Naar <ike@iceland.freeshell.org> writes: > On 2016-07-20, Gareth Owen <gwowen@gmail.com> wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >>>> It's the double abstraction problem >>>> >>>> magptr = malloc(40 * sizeof(float)); >>>> >>>> tells us that we are asking for 160 bytes of memory. >>> >>> No, it doesn't. It tells us we're asking for 40 * sizeof(float) bytes >>> of memory. >> >> Supremely confident idiot. > > Your suggestion that RH's an idiot tells us more about you than it > tells us about RH. Can you explain what's wrong with RH's remark? I wasn't suggesting that RH is an idiot.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-20 14:42 -0700 |
| Message-ID | <lnbn1skmu6.fsf@kst-u.example.com> |
| In reply to | #90687 |
Gareth Owen <gwowen@gmail.com> writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> It's the double abstraction problem
>>>
>>> magptr = malloc(40 * sizeof(float));
>>>
>>> tells us that we are asking for 160 bytes of memory.
>>
>> No, it doesn't. It tells us we're asking for 40 * sizeof(float) bytes
>> of memory.
>
> Supremely confident idiot.
Gareth, you're not helping.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-07-20 23:21 +0100 |
| Message-ID | <87k2ggkl19.fsf@gmail.com> |
| In reply to | #90700 |
Keith Thompson <kst-u@mib.org> writes:
> Gareth Owen <gwowen@gmail.com> writes:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>> It's the double abstraction problem
>>>>
>>>> magptr = malloc(40 * sizeof(float));
>>>>
>>>> tells us that we are asking for 160 bytes of memory.
>>>
>>> No, it doesn't. It tells us we're asking for 40 * sizeof(float) bytes
>>> of memory.
>>
>> Supremely confident idiot.
>
> Gareth, you're not helping.
Well, if you keep treating Malcolm's ridiculous rules, ground less
assertions and self-serving ever-mutating redefinitions of standard
terms as the starting point for debate (and bear in mind he never never
never admits that his rules are anything other than totally correct)
well ... you're not helping either.
At least I have brevity on my side.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-20 20:49 +0100 |
| Message-ID | <nmokk8$r6e$1@dont-email.me> |
| In reply to | #90683 |
On 20/07/2016 20:25, Richard Heathfield wrote: > Now try this: > > float *magptr = malloc(40 * sizeof *magptr); > > This gives precisely the same information as your example, and has the > added benefit of being robust in the face of changes to magptr's type. You've just exchanged one dependency between left and right sides of the assignment for another: the variable name 'magptr' must be the same. And if the bit of code is copy&pasted, and modified so as to use the same pattern for a different variable, you have to make sure both variable names are updated. In general, there will be a larger number of possible incorrect variable names that will be accepted on the right, than of incorrect type names. In the case of using this pattern to allocate arrays of primitive types, the number of such types is even more limited. You only need to change one thing between two similar lines here: float *magptr = malloc(40 * sizeof (float)); float *magptr2 = malloc(40 * sizeof (float)); instead of two using your style: float *magptr = malloc(40 * sizeof *magptr); float *magptr2 = malloc(40 * sizeof *magptr2); (In this particular example, writing float *magptr2 = malloc(40 * sizeof *magptr); by mistake will still work. However it would be wrong.) (And part of the type, using your style, still has to appear on the right: the "*" bit. It would be rare - when used as a malloc argument - for the "*" not to be needed. But it can happen that both sides still need updating when the type changes.) -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web