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 1 of 16 [1] 2 3 … 16 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-19 15:30 -0700 |
| Subject | A glitch regarding the usual malloc() idiom |
| Message-ID | <lnr3apmfbl.fsf@kst-u.example.com> |
The widely (but not universally) accepted idiom for calling malloc() in
C is:
some_type *ptr = malloc(sizeof *ptr);
or, if you want to allocate an array:
some_type *ptr = malloc(N * sizeof *ptr);
The expression `*ptr` dereferences an uninitialized pointer, but it's
safe because the operand of `sizeof` is not evaluated.
Well, almost. As I've just realized while following up to a post in
another thread by BartC, the operand *is* evaluated if it's of a
variably modified type.
A simple example:
#include <stdlib.h>
int main(void) {
int n = 10;
int (*p)[n] = malloc(sizeof *p);
}
Here `p` is a pointer to a variable length array (VLA), so `*p`
is of a variably modified type, so it's evaluated -- which causes
undefined behavior.
(I started a thread a while ago suggesting that it shouldn't actually
be necessary to evaluate the operand, since all you need is the size.
I don't intend to re-argue that. The standard says it's evaluated,
so it's evaluated.)
This is a fairly obscure corner case where the commonly recommended
malloc() idiom causes undefined behavior. I've never seen real-world
code that runs into this; if you're allocating dynamically-sized
arrays using malloc(), you'll usually use a pointer to the element
type. This is just a mildly interesting observation.
(One not particularly relevant data point: When I compile and run the
above using gcc, it appears to work "correctly". This is of course a
valid consequence of undefined behavior.)
To avoid the UB, you could write something like:
#include <stdlib.h>
int main(void) {
int n = 10;
typedef int vla[n];
vla *p = malloc(sizeof (vla));
}
--
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] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-20 09:51 +0530 |
| Message-ID | <nmmu85$c1p$1@dont-email.me> |
| In reply to | #90631 |
On 07/20/2016 04:00 AM, Keith Thompson wrote: > [intriguing observation] Thanks for the intriguing observation. I read up Harbison and Steele on sizeof where they have one paragraph on this that makes for interesting reading: If a variable length array type name appears in a sizeof expression and the value of the array size affects the value of the sizeof expression, then the array size expression is always fully evaluated, including side effects. If the value of the array size does not affect the result of the sizeof, then it is undefined whether the size expression is evaluated. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2016-07-20 00:07 -0500 |
| Message-ID | <nmn0uu$i8g$1@dont-email.me> |
| In reply to | #90635 |
"Udyant Wig" <udyant.wig@gmail.com> wrote in message news:nmmu85$c1p$1@dont-email.me... > On 07/20/2016 04:00 AM, Keith Thompson wrote: >> [intriguing observation] > > Thanks for the intriguing observation. I read up Harbison and Steele > on sizeof where they have one paragraph on this that makes for > interesting reading: > > If a variable length array type name appears in a sizeof expression and > the value of the array size affects the value of the sizeof expression, > then the array size expression is always fully evaluated, including side > effects. If the value of the array size does not affect the result of > the sizeof, then it is undefined whether the size expression is > evaluated. > Ah, for the "good old days", when sizeof() expressions were dead and unevaluated, like the $Diety meant them to be!!! IMHO, a better choice for the standard would have been... to *forbid* any variable length array type name to be used in sizeof(). -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-20 01:11 -0700 |
| Message-ID | <4cd22745-22ad-4ac7-bdba-39ffa1c75e13@googlegroups.com> |
| In reply to | #90638 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-20 10:09 +0100 |
| Message-ID | <nmnf45$o4f$1@dont-email.me> |
| In reply to | #90640 |
On 20/07/16 09:11, Malcolm McLean wrote: > 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(). Firstly, the verb is wrong. Operands aren't "passed" to operators. Secondly, the claim is wrong. Whilst it is true that C supports parenthesised types as legitimate operands to sizeof, it also supports expressions. In general, I have found that it's a good idea to use expressions wherever possible, and parenthesised types only when necessary. > In particular, uninitialised pointers should not be dereferenced > in a sizeof expression. They aren't. T *new = malloc(n * sizeof *new); DOES NOT dereference 'new'. The code is perfectly fine. > By a quirk of the language, that happens > to be legal. But it's very obviously undesirable. Since this dereferencing /doesn't happen/, the question of its desirability doesn't arise. -- 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-20 02:27 -0700 |
| Message-ID | <48bfec8e-1f8b-4a7d-9de9-2f4b203efa88@googlegroups.com> |
| In reply to | #90641 |
On Wednesday, July 20, 2016 at 10:09:34 AM UTC+1, Richard Heathfield wrote: > On 20/07/16 09:11, Malcolm McLean wrote: > > 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(). > > Firstly, the verb is wrong. Operands aren't "passed" to operators. > Secondly, the claim is wrong. Whilst it is true that C supports > parenthesised types as legitimate operands to sizeof, it also supports > expressions. In general, I have found that it's a good idea to use > expressions wherever possible, and parenthesised types only when necessary. > > > In particular, uninitialised pointers should not be dereferenced > > in a sizeof expression. > > They aren't. > > T *new = malloc(n * sizeof *new); > > DOES NOT dereference 'new'. The code is perfectly fine. > > > By a quirk of the language, that happens > > to be legal. But it's very obviously undesirable. > > Since this dereferencing /doesn't happen/, the question of its > desirability doesn't arise. > Ok, so we've got a special rule. * 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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-20 10:44 +0100 |
| Message-ID | <nmnh6f$u3r$1@dont-email.me> |
| In reply to | #90642 |
On 20/07/16 10:27, Malcolm McLean wrote: > On Wednesday, July 20, 2016 at 10:09:34 AM UTC+1, Richard Heathfield wrote: >> On 20/07/16 09:11, Malcolm McLean wrote: >>> 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(). >> >> Firstly, the verb is wrong. Operands aren't "passed" to operators. >> Secondly, the claim is wrong. Whilst it is true that C supports >> parenthesised types as legitimate operands to sizeof, it also supports >> expressions. In general, I have found that it's a good idea to use >> expressions wherever possible, and parenthesised types only when necessary. >> >>> In particular, uninitialised pointers should not be dereferenced >>> in a sizeof expression. >> >> They aren't. >> >> T *new = malloc(n * sizeof *new); >> >> DOES NOT dereference 'new'. The code is perfectly fine. >> >>> By a quirk of the language, that happens >>> to be legal. But it's very obviously undesirable. >> >> Since this dereferencing /doesn't happen/, the question of its >> desirability doesn't arise. >> > Ok, so we've got a special rule. > > * does not dereference a pointer when preceded by a sizeof. No, it's nothing to do with *. It's to do with sizeof. We've got an operator, sizeof, that doesn't evaluate its operand. (VLAs muddy the water, and that's just one of the reasons I don't like them.) Every operator is different, because every operator has a different job to do. So every operator is special, and has a special rule - the rule that says what that particular operator does. In this case, the operator is sizeof, which yields the size of its operand, which it doesn't evaluate. > That seems to me sufficiently undesirable that it has no place in > release-quality C code. But the thing you find undesirable (a special extra rule for *) doesn't exist. -- 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-20 03:01 -0700 |
| Message-ID | <706cdd84-add9-4c8d-8210-10a5cf8e5b25@googlegroups.com> |
| In reply to | #90643 |
On Wednesday, July 20, 2016 at 10:44:55 AM UTC+1, Richard Heathfield wrote: > On 20/07/16 10:27, Malcolm McLean wrote: > > On Wednesday, July 20, 2016 at 10:09:34 AM UTC+1, Richard Heathfield wrote: > >> On 20/07/16 09:11, Malcolm McLean wrote: > >>> 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(). > >> > >> Firstly, the verb is wrong. Operands aren't "passed" to operators. > >> Secondly, the claim is wrong. Whilst it is true that C supports > >> parenthesised types as legitimate operands to sizeof, it also supports > >> expressions. In general, I have found that it's a good idea to use > >> expressions wherever possible, and parenthesised types only when necessary. > >> > >>> In particular, uninitialised pointers should not be dereferenced > >>> in a sizeof expression. > >> > >> They aren't. > >> > >> T *new = malloc(n * sizeof *new); > >> > >> DOES NOT dereference 'new'. The code is perfectly fine. > >> > >>> By a quirk of the language, that happens > >>> to be legal. But it's very obviously undesirable. > >> > >> Since this dereferencing /doesn't happen/, the question of its > >> desirability doesn't arise. > >> > > Ok, so we've got a special rule. > > > > * does not dereference a pointer when preceded by a sizeof. > > No, it's nothing to do with *. It's to do with sizeof. We've got an > operator, sizeof, that doesn't evaluate its operand. (VLAs muddy the > water, and that's just one of the reasons I don't like them.) Every > operator is different, because every operator has a different job to do. > So every operator is special, and has a special rule - the rule that > says what that particular operator does. In this case, the operator is > sizeof, which yields the size of its operand, which it doesn't evaluate. > > > That seems to me sufficiently undesirable that it has no place in > > release-quality C code. > > But the thing you find undesirable (a special extra rule for *) doesn't > exist. > OK, so my attitude is we don't need all these complications, which give us no functionality or support for expressing algorithms, just so that we can support processors which have either 2-byte or 4-byte ints. So junk it.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-20 11:17 +0100 |
| Message-ID | <nmnj34$3u8$1@dont-email.me> |
| In reply to | #90645 |
On 20/07/16 11:01, Malcolm McLean wrote: > On Wednesday, July 20, 2016 at 10:44:55 AM UTC+1, Richard Heathfield wrote: >> On 20/07/16 10:27, Malcolm McLean wrote: >>> On Wednesday, July 20, 2016 at 10:09:34 AM UTC+1, Richard Heathfield wrote: >>>> On 20/07/16 09:11, Malcolm McLean wrote: >>>>> 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(). >>>> >>>> Firstly, the verb is wrong. Operands aren't "passed" to operators. >>>> Secondly, the claim is wrong. Whilst it is true that C supports >>>> parenthesised types as legitimate operands to sizeof, it also supports >>>> expressions. In general, I have found that it's a good idea to use >>>> expressions wherever possible, and parenthesised types only when necessary. >>>> >>>>> In particular, uninitialised pointers should not be dereferenced >>>>> in a sizeof expression. >>>> >>>> They aren't. >>>> >>>> T *new = malloc(n * sizeof *new); >>>> >>>> DOES NOT dereference 'new'. The code is perfectly fine. >>>> >>>>> By a quirk of the language, that happens >>>>> to be legal. But it's very obviously undesirable. >>>> >>>> Since this dereferencing /doesn't happen/, the question of its >>>> desirability doesn't arise. >>>> >>> Ok, so we've got a special rule. >>> >>> * does not dereference a pointer when preceded by a sizeof. >> >> No, it's nothing to do with *. It's to do with sizeof. We've got an >> operator, sizeof, that doesn't evaluate its operand. (VLAs muddy the >> water, and that's just one of the reasons I don't like them.) Every >> operator is different, because every operator has a different job to do. >> So every operator is special, and has a special rule - the rule that >> says what that particular operator does. In this case, the operator is >> sizeof, which yields the size of its operand, which it doesn't evaluate. >> >>> That seems to me sufficiently undesirable that it has no place in >>> release-quality C code. >> >> But the thing you find undesirable (a special extra rule for *) doesn't >> exist. >> > OK, so my attitude is we don't need all these complications, which give us > no functionality or support for expressing algorithms, just so that we can > support processors which have either 2-byte or 4-byte ints. You lost me. The only complication here is the extra parentheses that some people consider desirable around sizeof's operand. > So junk it. Junk what? C? Why? -- 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-20 04:19 -0700 |
| Message-ID | <e4e4668e-dd00-47bc-9038-616f9ae52114@googlegroups.com> |
| In reply to | #90649 |
On Wednesday, July 20, 2016 at 11:17:15 AM UTC+1, Richard Heathfield wrote: > On 20/07/16 11:01, Malcolm McLean wrote: > > So junk it. > > Junk what? C? Why? > Junk sizeof. What is it achieving? On some machines int is two bytes, on others four. So sizeof() allows code to work portably on both architectures. That's all we're getting out of it. It adds no further functionality.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-20 12:29 +0100 |
| Message-ID | <nmnnao$ibs$1@dont-email.me> |
| In reply to | #90650 |
On 20/07/16 12:19, Malcolm McLean wrote: > On Wednesday, July 20, 2016 at 11:17:15 AM UTC+1, Richard Heathfield wrote: >> On 20/07/16 11:01, Malcolm McLean wrote: > >>> So junk it. >> >> Junk what? C? Why? >> > Junk sizeof. I hope you won't. I kind of need it. > What is it achieving? It gives me the size of its operand. That's quite handy to know. > On some machines int is two bytes, on others four. So sizeof() allows code to work > portably on both architectures. I need to know how much memory to allocate for a structure. How am I going to find out, if not by sizeof? What do you want me to do, add up the fields and hard-code the answer into malloc? > That's all we're getting out of it. It adds no further functionality. All I ask of it is that it gives me the size of its operand. Which it does very nicely. -- 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-20 04:51 -0700 |
| Message-ID | <9e61b520-6ce1-4eb8-a075-5927e126c3bb@googlegroups.com> |
| In reply to | #90651 |
On Wednesday, July 20, 2016 at 12:29:38 PM UTC+1, Richard Heathfield wrote: > On 20/07/16 12:19, Malcolm McLean wrote: > > I need to know how much memory to allocate for a structure. How am I > going to find out, if not by sizeof? What do you want me to do, add up > the fields and hard-code the answer into malloc? > Use the method every other language uses Create an array of N structures of type Employee and, because it's C, somehow tag how you want the memory allocated.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-20 13:01 +0100 |
| Message-ID | <nmnp6q$omh$1@dont-email.me> |
| In reply to | #90652 |
On 20/07/16 12:51, Malcolm McLean wrote: > On Wednesday, July 20, 2016 at 12:29:38 PM UTC+1, Richard Heathfield wrote: >> On 20/07/16 12:19, Malcolm McLean wrote: >> >> I need to know how much memory to allocate for a structure. How am I >> going to find out, if not by sizeof? What do you want me to do, add up >> the fields and hard-code the answer into malloc? >> > Use the method every other language uses > > Create an array of N structures of type Employee and, because it's C, > somehow tag how you want the memory allocated. But perhaps I don't want an array of N structures. Maybe I want an array of structures that, *for now*, has N elements. Later on, I'll want it to have more. The easiest way to do that in C is to tell malloc how much storage I want for now, and later on tell realloc about my revised memory requirement. I looked up 6.7.2.3, and saw no way of using a structure tag to indicate how I want memory to be allocated. Nor do I know of such a way. Clearly I don't know C as well as I thought I did. Do you have a more specific reference to the section in the Standard where this functionality is documented? -- 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-20 05:43 -0700 |
| Message-ID | <7fad4026-953b-447d-8bb3-818518154f20@googlegroups.com> |
| In reply to | #90653 |
On Wednesday, July 20, 2016 at 1:01:39 PM UTC+1, Richard Heathfield wrote: > On 20/07/16 12:51, Malcolm McLean wrote: > I looked up 6.7.2.3, and saw no way of using a structure tag to indicate > how I want memory to be allocated. Nor do I know of such a way. Clearly > I don't know C as well as I thought I did. Do you have a more specific > reference to the section in the Standard where this functionality is > documented? > employee. h typedef struct employee_tag EMPLOYEE; EMPLOYEE *makeemployee(char *name, int payrollid, float salary); void killemployee(EMPLOYEE *emp); /* love that convention for naming a destructor */ float employee_getsalary(EMPLOYEE *emp); Now employees have to be on the heap, until they are put on the scrap-heap. And you don't need sizeof(EMPLOYEE), it' irrelevant and might not even be consistent from employee to employee.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-20 15:48 +0100 |
| Message-ID | <nmo30d$qd1$1@dont-email.me> |
| In reply to | #90654 |
On 20/07/16 13:43, Malcolm McLean wrote: > On Wednesday, July 20, 2016 at 1:01:39 PM UTC+1, Richard Heathfield wrote: >> On 20/07/16 12:51, Malcolm McLean wrote: > >> I looked up 6.7.2.3, and saw no way of using a structure tag to indicate >> how I want memory to be allocated. Nor do I know of such a way. Clearly >> I don't know C as well as I thought I did. Do you have a more specific >> reference to the section in the Standard where this functionality is >> documented? >> > employee. h > > typedef struct employee_tag EMPLOYEE; Unfortunately, EMPLOYEE is a reserved name. See 7.31(3). > EMPLOYEE *makeemployee(char *name, int payrollid, float salary); > void killemployee(EMPLOYEE *emp); /* love that convention for naming a destructor */ > float employee_getsalary(EMPLOYEE *emp); > > Now employees have to be on the heap, until they are put on the scrap-heap. > And you don't need sizeof(EMPLOYEE), it' irrelevant and might not even be consistent > from employee to employee. The method you recommended was: "Create an array of N structures of type Employee and, because it's C, somehow tag how you want the memory allocated." Now, I'd like to see the specific details of how you create a correctly-sized array of N structures (that can later be resized if required) without using sizeof - the first step in your recommended process. A function prototype does not count as specific details. -- 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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-20 08:20 -0700 |
| Message-ID | <2d5fde43-05ed-402b-ab35-53d1cebc53dc@googlegroups.com> |
| In reply to | #90658 |
On Wednesday, July 20, 2016 at 9:48:55 AM UTC-5, Richard Heathfield wrote: > Unfortunately, EMPLOYEE is a reserved name. See 7.31(3). By my reading, that merely says that names which starts with an E and another uppercase letter may be considered for use as a macro in future versions of errno.h; I would expect that people defining future macro names would try to avoid using names that would likely be used in existing code, so names like "EMPOYEE", "topic", "isolation", "strum", etc. should be safe unless people in charge of future standards want to be deliberately obtuse.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-20 16:31 +0100 |
| Message-ID | <nmo5g3$37j$2@dont-email.me> |
| In reply to | #90660 |
On 20/07/16 16:20, supercat@casperkitty.com wrote: > On Wednesday, July 20, 2016 at 9:48:55 AM UTC-5, Richard Heathfield wrote: >> Unfortunately, EMPLOYEE is a reserved name. See 7.31(3). > > By my reading, that merely says that names which starts with an E and > another uppercase letter may be considered for use as a macro in future > versions of errno.h; You have to read it in the context of 7.31, which reads: "The following names are grouped under individual headers for convenience. All external names described below are reserved no matter what headers are included by the program." -- 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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-20 08:49 -0700 |
| Message-ID | <69c65e87-4a95-4e66-916d-5fa5fc887563@googlegroups.com> |
| In reply to | #90661 |
On Wednesday, July 20, 2016 at 10:31:23 AM UTC-5, Richard Heathfield wrote: > On 20/07/16 16:20, supercat wrote: > > On Wednesday, July 20, 2016 at 9:48:55 AM UTC-5, Richard Heathfield wrote: > >> Unfortunately, EMPLOYEE is a reserved name. See 7.31(3). > > > > By my reading, that merely says that names which starts with an E and > > another uppercase letter may be considered for use as a macro in future > > versions of errno.h; > > You have to read it in the context of 7.31, which reads: "The following > names are grouped under individual headers for convenience. All external > names described below are reserved no matter what headers are included > by the program." There are no external names described in section 7.31(3)--just macros.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-20 13:00 -0400 |
| Message-ID | <87590012-ed36-8c58-e6e5-56abfd091528@verizon.net> |
| In reply to | #90661 |
On 07/20/2016 11:31 AM, Richard Heathfield wrote: > On 20/07/16 16:20, supercat@casperkitty.com wrote: >> On Wednesday, July 20, 2016 at 9:48:55 AM UTC-5, Richard Heathfield wrote: >>> Unfortunately, EMPLOYEE is a reserved name. See 7.31(3). >> >> By my reading, that merely says that names which starts with an E and >> another uppercase letter may be considered for use as a macro in future >> versions of errno.h; > > You have to read it in the context of 7.31, which reads: "The following > names are grouped under individual headers for convenience. All external > names described below are reserved no matter what headers are included > by the program." "... an external name (an identifier that has external linkage)..." (6.4.2.1p5) The term "external name" is italicized, indicating that this sentence constitutes the official definition of that term. "The following identifiers have no linkage: an identifier declared to be anything other than an object or a function; ..." (6.2.2p6) Macros are therefore not external names, so names that start with E followed by another uppercase letter need only be avoided after #including <errno.h>.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-20 18:23 +0100 |
| Message-ID | <nmoc33$rfv$1@dont-email.me> |
| In reply to | #90674 |
On 20/07/16 18:00, James R. Kuyper wrote: > On 07/20/2016 11:31 AM, Richard Heathfield wrote: >> On 20/07/16 16:20, supercat@casperkitty.com wrote: >>> On Wednesday, July 20, 2016 at 9:48:55 AM UTC-5, Richard Heathfield >>> wrote: >>>> Unfortunately, EMPLOYEE is a reserved name. See 7.31(3). >>> >>> By my reading, that merely says that names which starts with an E and >>> another uppercase letter may be considered for use as a macro in future >>> versions of errno.h; >> >> You have to read it in the context of 7.31, which reads: "The following >> names are grouped under individual headers for convenience. All external >> names described below are reserved no matter what headers are included >> by the program." > > "... an external name (an identifier that has external > linkage)..." (6.4.2.1p5) > > The term "external name" is italicized, indicating that this sentence > constitutes the official definition of that term. > > "The following identifiers have no linkage: an identifier declared to be > anything other than an object or a function; ..." (6.2.2p6) > > Macros are therefore not external names, so names that start with E > followed by another uppercase letter need only be avoided after > #including <errno.h>. <clutch, reverse> Ah, quite right. Mea wossname. <clutch, first gear> It is, of course, always wise to avoid such names even if /not/ including <errno.h> - <clutch, second gear> otherwise, later on, deciding that you do after all need to add <errno.h> can land you with a tedious renaming task. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 1 of 16 [1] 2 3 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web