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 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-20 12:29 -0700 |
| Message-ID | <lnk2ggkszv.fsf@kst-u.example.com> |
| In reply to | #90681 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 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
So you're serious.
> 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.
I don't *care* that I'm asking for 160 bytes. Or if I do, I can
compute it easily enough. I care, in this case, that I'm allocating
space for 40 objects of the type magptr points to. (I'd probably use
some symbolic name rather than the constant 40, but that's not a big
deal for this example.)
And if I decide to use double rather than float, then
magptr = malloc(40 * sizeof(float));
will still compile without error or warning, and I'll allocate the wrong
size (unless float and double happen to be the same size).
I don't expect you to change your mind, but can you at least acknowledge
the advantages of using `sizeof *magptr` rather than `sizeof(float)`?
[...]
--
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 13:03 -0700 |
| Message-ID | <36f1e05e-609e-4e0e-8819-86feee1f4d8c@googlegroups.com> |
| In reply to | #90684 |
On Wednesday, July 20, 2016 at 8:30:01 PM UTC+1, Keith Thompson wrote:
>
> I don't *care* that I'm asking for 160 bytes. Or if I do, I can
> compute it easily enough. I care, in this case, that I'm allocating
> space for 40 objects of the type magptr points to. (I'd probably use
> some symbolic name rather than the constant 40, but that's not a big
> deal for this example.)
>
Sometimes it matters, most often it doesn't.
But even if there is no serious constraint on memory usage, it
helps to be able to see something concrete. It's likely we know
that a float will by 4 bytes, so sizeof(float) is meaningful, it
can mentally be replaced by "four".
>
> And if I decide to use double rather than float, then
> magptr = malloc(40 * sizeof(float));
> will still compile without error or warning, and I'll allocate the wrong
> size (unless float and double happen to be the same size).
>
> I don't expect you to change your mind, but can you at least acknowledge
> the advantages of using `sizeof *magptr` rather than `sizeof(float)`?
>
That's a genuine advantage.
But it's way overstated. If we move from float to double then we need
to manually check all code of any mathematical sophistication anyway,
because there are often hidden epsilon terms.
Then that's even more true if we move from one structure to another.
E.g. this typical code fragment
points = malloc(40 * sizeof(POINT2));
for(i=0;i<40;i++)
{
points[i].x = i;
points[i].y = 0;
}
so what happens when we move to POINT3?
It just depends why we need to start off with points evenly spaced
along the x-axis. But most likely we also need to set z to zero.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-20 16:55 -0700 |
| Message-ID | <ln7fcflv9v.fsf@kst-u.example.com> |
| In reply to | #90691 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, July 20, 2016 at 8:30:01 PM UTC+1, Keith Thompson wrote:
>>
>> I don't *care* that I'm asking for 160 bytes. Or if I do, I can
>> compute it easily enough. I care, in this case, that I'm allocating
>> space for 40 objects of the type magptr points to. (I'd probably use
>> some symbolic name rather than the constant 40, but that's not a big
>> deal for this example.)
>>
> Sometimes it matters, most often it doesn't.
> But even if there is no serious constraint on memory usage, it
> helps to be able to see something concrete. It's likely we know
> that a float will by 4 bytes, so sizeof(float) is meaningful, it
> can mentally be replaced by "four".
If you need to see something concrete, you can add a comment:
magptr = malloc(40 * sizeof *magptr); /* 160 bytes */
Keeping the comment in sync with the code is left as an exercise.
[...]
--
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 21:40 -0700 |
| Message-ID | <c2cbf93e-1479-4cde-98b2-3027299c2c8e@googlegroups.com> |
| In reply to | #90703 |
On Thursday, July 21, 2016 at 12:55:32 AM UTC+1, Keith Thompson wrote: > > > If you need to see something concrete, you can add a comment: > > magptr = malloc(40 * sizeof *magptr); /* 160 bytes */ > > Keeping the comment in sync with the code is left as an exercise. > You can. Part of the art of programming is writing code that is essentially self-documenting. The comment is useful if you are reading the code for memory issues, which is one important class of problems or issues with code. If you're reading for flow control issues, the comment is clutter and distracting. Someone did some tests on C code and found that programmers performed better on code with comments stripped. Of course the results would be highly dependent on exactly how the experiment was set up and we can't simply conclude "no comments".
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-21 07:16 +0100 |
| Message-ID | <nmppbm$so4$1@dont-email.me> |
| In reply to | #90709 |
On 21/07/16 05:40, Malcolm McLean wrote: > On Thursday, July 21, 2016 at 12:55:32 AM UTC+1, Keith Thompson wrote: >> >> >> If you need to see something concrete, you can add a comment: >> >> magptr = malloc(40 * sizeof *magptr); /* 160 bytes */ >> >> Keeping the comment in sync with the code is left as an exercise. >> > You can. > Part of the art of programming is writing code that is essentially > self-documenting. I partly agree. T *new = malloc(n * sizeof *new); /is/ self-documenting. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-21 09:47 -0700 |
| Message-ID | <lnpoq7j5uo.fsf@kst-u.example.com> |
| In reply to | #90709 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, July 21, 2016 at 12:55:32 AM UTC+1, Keith Thompson wrote:
>> If you need to see something concrete, you can add a comment:
>>
>> magptr = malloc(40 * sizeof *magptr); /* 160 bytes */
>>
>> Keeping the comment in sync with the code is left as an exercise.
>>
> You can.
I wouldn't. I was suggesting that *you* can add a comment if *you*
want to see the number of bytes allocated explicitly. I'd just write
magptr = malloc(40 * sizeof *magptr);
and leave it at that.
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-23 09:37 +0000 |
| Message-ID | <57933a73.4812875@news.xs4all.nl> |
| In reply to | #90709 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Thursday, July 21, 2016 at 12:55:32 AM UTC+1, Keith Thompson wrote: > > > > > > If you need to see something concrete, you can add a comment: > > > > magptr = malloc(40 * sizeof *magptr); /* 160 bytes */ > > > > Keeping the comment in sync with the code is left as an exercise. > > > You can. > Part of the art of programming is writing code that is essentially > self-documenting. But you're trying to document two different things here: - 40 of whatever magptr points at; - 160. It is not a priori clear that those two are the same. Therefore, either one or the other, plus their equality, needs to be explicitly documented. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-23 03:23 -0700 |
| Message-ID | <f21ce6b1-3be2-422e-8511-c84d5b13e757@googlegroups.com> |
| In reply to | #90838 |
On Saturday, July 23, 2016 at 10:37:29 AM UTC+1, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > On Thursday, July 21, 2016 at 12:55:32 AM UTC+1, Keith Thompson wrote: > > > > > > > > > If you need to see something concrete, you can add a comment: > > > > > > magptr = malloc(40 * sizeof *magptr); /* 160 bytes */ > > > > > > Keeping the comment in sync with the code is left as an exercise. > > > > > You can. > > Part of the art of programming is writing code that is essentially > > self-documenting. > > But you're trying to document two different things here: > > - 40 of whatever magptr points at; > - 160. > > It is not a priori clear that those two are the same. Therefore, either > one or the other, plus their equality, needs to be explicitly > documented. > You don't necessarily know how the code will be used. Someone might say "oh no, this code is gobbling too much memory" and do a grep on "malloc". He then gets most of the allocation lines, but not calloc, realloc, or malloc wrappers. If he sees malloc(40 *sizeof(int)) he instantly knows how much memory. But more likely it will be N * sizeof(int). So has N gone wild. Another not too unlikely possibility is that we have a structure with magptr, a list of magnitudes we need to cache for some reason, embedded in it. User changes the type of magptr in the structure, but doesn't examine the calling code. You can argue that one both ways, calling code shouldn't break at all object->magptr = malloc(object->Nthingumies * sizeof *object->magptr) it shouldn't silently break object->magptr = (int *) malloc(object->Nthingumies * sizeof(int)); or maintainer should be checking all the code anyway object->magptr = malloc(object->Nthingumies * sizeof(int)); for(i=0;i<object->Nthingumies;i++) object->magptr[i] = INT_MAX; if we change magptr to a double *, the code will subtly break anyway, and actually it's probably quite a dangerous bug, it will likely work until someone takes advantage of the move to double to pass in some huge values. So solution one is giving us a false sense of security.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-23 19:47 +0000 |
| Message-ID | <5793c8e5.2941812@news.xs4all.nl> |
| In reply to | #90844 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, July 23, 2016 at 10:37:29 AM UTC+1, Richard Bos wrote: > > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > On Thursday, July 21, 2016 at 12:55:32 AM UTC+1, Keith Thompson wrote: > > > > > > > > If you need to see something concrete, you can add a comment: > > > > > > > > magptr = malloc(40 * sizeof *magptr); /* 160 bytes */ > > > > > > > > Keeping the comment in sync with the code is left as an exercise. > > > > > > > You can. > > > Part of the art of programming is writing code that is essentially > > > self-documenting. > > > > But you're trying to document two different things here: > > > > - 40 of whatever magptr points at; > > - 160. > > > > It is not a priori clear that those two are the same. Therefore, either > > one or the other, plus their equality, needs to be explicitly > > documented. > > > You don't necessarily know how the code will be used. > Someone might say "oh no, this code is gobbling too much memory" and > do a grep on "malloc". He then gets most of the allocation lines, > but not calloc, realloc, or malloc wrappers. If he sees malloc(40 *sizeof(int)) he instantly knows how much memory. > But more likely it will be N * sizeof(int). So has N gone wild. Mate, you're supercatting. All that mass of argumentation of dubious validity, even if some of it _were_ completely valid, still would have no relevance at all to the point I raised: that 40 * sizeof *magptr is _not_ /ipso naturo/ equal to 160, and that if you want to rely on that equality, it had better be documented one way or another. No amount of side-tracking about malloc() is going to change that. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-23 13:38 -0700 |
| Message-ID | <b80e8423-7bb0-432b-894a-8cd6bb038ea6@googlegroups.com> |
| In reply to | #90865 |
On Saturday, July 23, 2016 at 8:47:20 PM UTC+1, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > Mate, you're supercatting. All that mass of argumentation of dubious > validity, even if some of it _were_ completely valid, still would have > no relevance at all to the point I raised: that 40 * sizeof *magptr is > _not_ /ipso naturo/ equal to 160, and that if you want to rely on that > equality, it had better be documented one way or another. No amount of > side-tracking about malloc() is going to change that. > Code relies on basic types being their normal sizes all the time. magptr = malloc(40 * sizeof *magptr) means create 40 objects of size and type we have to check elsewhere magptr = malloc(40 * sizeof(int)) means allocate 160 bytes and assign to magptr. Which almost always will be a buffer of 40 ints. Possible bugs, someone has changed magptr to use a type other than int, someone has changed the algorithm to require more than 40 integers. Now to what extent do we rely on sizeof(int) being 4? Hard to say without context. There could easily be code in there that will break if ints are 16 bits, less likely but by no means impossible that it will also break if ints are 64 bits. It won't be documented, certainly not in the malloc call.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-23 17:53 -0400 |
| Message-ID | <nn0p0u$jgm$1@jstuckle.eternal-september.org> |
| In reply to | #90872 |
On 7/23/2016 4:38 PM, Malcolm McLean wrote: > On Saturday, July 23, 2016 at 8:47:20 PM UTC+1, Richard Bos wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >> >> Mate, you're supercatting. All that mass of argumentation of dubious >> validity, even if some of it _were_ completely valid, still would have >> no relevance at all to the point I raised: that 40 * sizeof *magptr is >> _not_ /ipso naturo/ equal to 160, and that if you want to rely on that >> equality, it had better be documented one way or another. No amount of >> side-tracking about malloc() is going to change that. >> > Code relies on basic types being their normal sizes all the time. > > magptr = malloc(40 * sizeof *magptr) > > means create 40 objects of size and type we have to check elsewhere > > magptr = malloc(40 * sizeof(int)) > > means allocate 160 bytes and assign to magptr. Which almost always > will be a buffer of 40 ints. Possible bugs, someone has changed > magptr to use a type other than int, someone has changed the > algorithm to require more than 40 integers. > No, it means allocate the amount required for 40 ints and assign the address to magptr. An int is NOT necessarily 4 bytes. It can be any length at least as big as a short and not bigger than a long. > Now to what extent do we rely on sizeof(int) being 4? Hard > to say without context. There could easily be code in there that > will break if ints are 16 bits, less likely but by no means > impossible that it will also break if ints are 64 bits. It > won't be documented, certainly not in the malloc call. > You cannot rely on an int being 4 bytes. But good code will not break no matter what the size of the int. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-24 01:52 +0100 |
| Message-ID | <87oa5n97rz.fsf@bsb.me.uk> |
| In reply to | #90883 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 7/23/2016 4:38 PM, Malcolm McLean wrote: <snip> >> magptr = malloc(40 * sizeof(int)) >> >> means allocate 160 bytes and assign to magptr. Which almost always >> will be a buffer of 40 ints. Possible bugs, someone has changed >> magptr to use a type other than int, someone has changed the >> algorithm to require more than 40 integers. > > No, it means allocate the amount required for 40 ints and assign the > address to magptr. An int is NOT necessarily 4 bytes. It can be any > length at least as big as a short and not bigger than a long. That last bit true of what C calls the width of the types (the number of value bits plus one for signed types) but, because of the possibility of padding bits, it's not true of the size in bytes. Of course it's almost inconceivable that any real implementation would have, for example, sizeof (short) > sizeof (int) but it is permitted. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 11:06 -0400 |
| Message-ID | <nn2lht$lsh$1@jstuckle.eternal-september.org> |
| In reply to | #90885 |
On 7/23/2016 8:52 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 7/23/2016 4:38 PM, Malcolm McLean wrote: > <snip> >>> magptr = malloc(40 * sizeof(int)) >>> >>> means allocate 160 bytes and assign to magptr. Which almost always >>> will be a buffer of 40 ints. Possible bugs, someone has changed >>> magptr to use a type other than int, someone has changed the >>> algorithm to require more than 40 integers. >> >> No, it means allocate the amount required for 40 ints and assign the >> address to magptr. An int is NOT necessarily 4 bytes. It can be any >> length at least as big as a short and not bigger than a long. > > That last bit true of what C calls the width of the types (the number of > value bits plus one for signed types) but, because of the possibility of > padding bits, it's not true of the size in bytes. Of course it's almost > inconceivable that any real implementation would have, for example, > sizeof (short) > sizeof (int) but it is permitted. > > <snip> > It is also the size in bytes. Size of an int does not include any padding. And no, sizeof (short) > sizeof (int) is not permitted. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-24 16:32 +0100 |
| Message-ID | <nn2n1o$rb4$1@dont-email.me> |
| In reply to | #90901 |
On 24/07/16 16:06, Jerry Stuckle wrote: > On 7/23/2016 8:52 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 7/23/2016 4:38 PM, Malcolm McLean wrote: >> <snip> >>>> magptr = malloc(40 * sizeof(int)) >>>> >>>> means allocate 160 bytes and assign to magptr. Which almost always >>>> will be a buffer of 40 ints. Possible bugs, someone has changed >>>> magptr to use a type other than int, someone has changed the >>>> algorithm to require more than 40 integers. >>> >>> No, it means allocate the amount required for 40 ints and assign the >>> address to magptr. An int is NOT necessarily 4 bytes. It can be any >>> length at least as big as a short and not bigger than a long. >> >> That last bit true of what C calls the width of the types (the number of >> value bits plus one for signed types) but, because of the possibility of >> padding bits, it's not true of the size in bytes. Of course it's almost >> inconceivable that any real implementation would have, for example, >> sizeof (short) > sizeof (int) but it is permitted. >> >> <snip> >> > > It is also the size in bytes. Size of an int does not include any padding. Yes, it does. See 6.2.6.2(1) and 6.2.6.2(2) (which show that padding bits are allowed in integer types, both signed and unsigned flavours), and the sizeof operator yields the size of its operand in bytes (6.5.3.4(2)), expressed as an integer. Since the Standard does not require the number of padding bits to equate to a multiple of CHAR_BIT, and since sizeof has no licence to return a rounded value, it must therefore be the case that any padding bits are included in the result of sizeof. > And no, sizeof (short) > sizeof (int) is not permitted. It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX (see 6.2.5(8), which says the same thing in different words). It is, for example, legal (albeit rather daft) for int to be 16 bits (with no padding) and short to be 24 bits (with 8 bits of padding). -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 17:27 -0400 |
| Message-ID | <nn3bqq$4ps$1@jstuckle.eternal-september.org> |
| In reply to | #90904 |
On 7/24/2016 11:32 AM, Richard Heathfield wrote: > On 24/07/16 16:06, Jerry Stuckle wrote: >> On 7/23/2016 8:52 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 7/23/2016 4:38 PM, Malcolm McLean wrote: >>> <snip> >>>>> magptr = malloc(40 * sizeof(int)) >>>>> >>>>> means allocate 160 bytes and assign to magptr. Which almost always >>>>> will be a buffer of 40 ints. Possible bugs, someone has changed >>>>> magptr to use a type other than int, someone has changed the >>>>> algorithm to require more than 40 integers. >>>> >>>> No, it means allocate the amount required for 40 ints and assign the >>>> address to magptr. An int is NOT necessarily 4 bytes. It can be any >>>> length at least as big as a short and not bigger than a long. >>> >>> That last bit true of what C calls the width of the types (the number of >>> value bits plus one for signed types) but, because of the possibility of >>> padding bits, it's not true of the size in bytes. Of course it's almost >>> inconceivable that any real implementation would have, for example, >>> sizeof (short) > sizeof (int) but it is permitted. >>> >>> <snip> >>> >> >> It is also the size in bytes. Size of an int does not include any >> padding. > > Yes, it does. See 6.2.6.2(1) and 6.2.6.2(2) (which show that padding > bits are allowed in integer types, both signed and unsigned flavours), > and the sizeof operator yields the size of its operand in bytes > (6.5.3.4(2)), expressed as an integer. Since the Standard does not > require the number of padding bits to equate to a multiple of CHAR_BIT, > and since sizeof has no licence to return a rounded value, it must > therefore be the case that any padding bits are included in the result > of sizeof. > >> And no, sizeof (short) > sizeof (int) is not permitted. > > It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX > (see 6.2.5(8), which says the same thing in different words). > > It is, for example, legal (albeit rather daft) for int to be 16 bits > (with no padding) and short to be 24 bits (with 8 bits of padding). > No, these paragraphs refer to padding BITS, not bytes. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-24 22:58 +0100 |
| Message-ID | <nn3dlt$a4v$1@dont-email.me> |
| In reply to | #90915 |
On 24/07/16 22:27, Jerry Stuckle wrote: > On 7/24/2016 11:32 AM, Richard Heathfield wrote: >> On 24/07/16 16:06, Jerry Stuckle wrote: >>> On 7/23/2016 8:52 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 7/23/2016 4:38 PM, Malcolm McLean wrote: >>>> <snip> >>>>>> magptr = malloc(40 * sizeof(int)) >>>>>> >>>>>> means allocate 160 bytes and assign to magptr. Which almost always >>>>>> will be a buffer of 40 ints. Possible bugs, someone has changed >>>>>> magptr to use a type other than int, someone has changed the >>>>>> algorithm to require more than 40 integers. >>>>> >>>>> No, it means allocate the amount required for 40 ints and assign the >>>>> address to magptr. An int is NOT necessarily 4 bytes. It can be any >>>>> length at least as big as a short and not bigger than a long. >>>> >>>> That last bit true of what C calls the width of the types (the number of >>>> value bits plus one for signed types) but, because of the possibility of >>>> padding bits, it's not true of the size in bytes. Of course it's almost >>>> inconceivable that any real implementation would have, for example, >>>> sizeof (short) > sizeof (int) but it is permitted. >>>> >>>> <snip> >>>> >>> >>> It is also the size in bytes. Size of an int does not include any >>> padding. >> >> Yes, it does. See 6.2.6.2(1) and 6.2.6.2(2) (which show that padding >> bits are allowed in integer types, both signed and unsigned flavours), >> and the sizeof operator yields the size of its operand in bytes >> (6.5.3.4(2)), expressed as an integer. Since the Standard does not >> require the number of padding bits to equate to a multiple of CHAR_BIT, >> and since sizeof has no licence to return a rounded value, it must >> therefore be the case that any padding bits are included in the result >> of sizeof. >> >>> And no, sizeof (short) > sizeof (int) is not permitted. >> >> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >> (see 6.2.5(8), which says the same thing in different words). >> >> It is, for example, legal (albeit rather daft) for int to be 16 bits >> (with no padding) and short to be 24 bits (with 8 bits of padding). >> > > No, Yes. > these paragraphs refer to padding BITS, not bytes. Padding bytes are perfectly legal. And so are padding bits. For example, it would be legal to have an implementation with CHAR_BIT = 11, with shorts being 17 value bits and 27 padding bits (giving 44 bits altogether, and sizeof(short) being 4), and ints being 20 value bits and 2 padding bits (giving 22 bits altogether, and sizeof(int) being 2). That is, it doesn't matter either way. It's perfectly possible and legal for sizeof(short) to exceed sizeof(int). What is /not/ legal is for SHRT_MAX to exceed INT_MAX. -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 18:19 -0400 |
| Message-ID | <nn3est$ge2$1@jstuckle.eternal-september.org> |
| In reply to | #90917 |
On 7/24/2016 5:58 PM, Richard Heathfield wrote: > On 24/07/16 22:27, Jerry Stuckle wrote: >> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>> On 24/07/16 16:06, Jerry Stuckle wrote: >>>> On 7/23/2016 8:52 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 7/23/2016 4:38 PM, Malcolm McLean wrote: >>>>> <snip> >>>>>>> magptr = malloc(40 * sizeof(int)) >>>>>>> >>>>>>> means allocate 160 bytes and assign to magptr. Which almost always >>>>>>> will be a buffer of 40 ints. Possible bugs, someone has changed >>>>>>> magptr to use a type other than int, someone has changed the >>>>>>> algorithm to require more than 40 integers. >>>>>> >>>>>> No, it means allocate the amount required for 40 ints and assign the >>>>>> address to magptr. An int is NOT necessarily 4 bytes. It can be any >>>>>> length at least as big as a short and not bigger than a long. >>>>> >>>>> That last bit true of what C calls the width of the types (the >>>>> number of >>>>> value bits plus one for signed types) but, because of the >>>>> possibility of >>>>> padding bits, it's not true of the size in bytes. Of course it's >>>>> almost >>>>> inconceivable that any real implementation would have, for example, >>>>> sizeof (short) > sizeof (int) but it is permitted. >>>>> >>>>> <snip> >>>>> >>>> >>>> It is also the size in bytes. Size of an int does not include any >>>> padding. >>> >>> Yes, it does. See 6.2.6.2(1) and 6.2.6.2(2) (which show that padding >>> bits are allowed in integer types, both signed and unsigned flavours), >>> and the sizeof operator yields the size of its operand in bytes >>> (6.5.3.4(2)), expressed as an integer. Since the Standard does not >>> require the number of padding bits to equate to a multiple of CHAR_BIT, >>> and since sizeof has no licence to return a rounded value, it must >>> therefore be the case that any padding bits are included in the result >>> of sizeof. >>> >>>> And no, sizeof (short) > sizeof (int) is not permitted. >>> >>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >>> (see 6.2.5(8), which says the same thing in different words). >>> >>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>> (with no padding) and short to be 24 bits (with 8 bits of padding). >>> >> >> No, > > Yes. > >> these paragraphs refer to padding BITS, not bytes. > > Padding bytes are perfectly legal. And so are padding bits. > Citation? And don't try to tell me bits are the same as bytes. Where does it say an int can have padding BYTES? > For example, it would be legal to have an implementation with CHAR_BIT = > 11, with shorts being 17 value bits and 27 padding bits (giving 44 bits > altogether, and sizeof(short) being 4), and ints being 20 value bits and > 2 padding bits (giving 22 bits altogether, and sizeof(int) being 2). > Citation? 6.2.6.2(1) and 6.2.6.2(2) do not say that. > That is, it doesn't matter either way. It's perfectly possible and legal > for sizeof(short) to exceed sizeof(int). What is /not/ legal is for > SHRT_MAX to exceed INT_MAX. > Again, citation? Where does it say sizeof(short) can exceed sizeof(int)? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-24 23:44 +0100 |
| Message-ID | <nn3gd7$kp0$1@dont-email.me> |
| In reply to | #90920 |
On 24/07/16 23:19, Jerry Stuckle wrote: > On 7/24/2016 5:58 PM, Richard Heathfield wrote: >> On 24/07/16 22:27, Jerry Stuckle wrote: >>> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>>> On 24/07/16 16:06, Jerry Stuckle wrote: >>>>> On 7/23/2016 8:52 PM, Ben Bacarisse wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>> >>>>>>> On 7/23/2016 4:38 PM, Malcolm McLean wrote: >>>>>> <snip> >>>>>>>> magptr = malloc(40 * sizeof(int)) >>>>>>>> >>>>>>>> means allocate 160 bytes and assign to magptr. Which almost always >>>>>>>> will be a buffer of 40 ints. Possible bugs, someone has changed >>>>>>>> magptr to use a type other than int, someone has changed the >>>>>>>> algorithm to require more than 40 integers. >>>>>>> >>>>>>> No, it means allocate the amount required for 40 ints and assign the >>>>>>> address to magptr. An int is NOT necessarily 4 bytes. It can be any >>>>>>> length at least as big as a short and not bigger than a long. >>>>>> >>>>>> That last bit true of what C calls the width of the types (the >>>>>> number of >>>>>> value bits plus one for signed types) but, because of the >>>>>> possibility of >>>>>> padding bits, it's not true of the size in bytes. Of course it's >>>>>> almost >>>>>> inconceivable that any real implementation would have, for example, >>>>>> sizeof (short) > sizeof (int) but it is permitted. >>>>>> >>>>>> <snip> >>>>>> >>>>> >>>>> It is also the size in bytes. Size of an int does not include any >>>>> padding. >>>> >>>> Yes, it does. See 6.2.6.2(1) and 6.2.6.2(2) (which show that padding >>>> bits are allowed in integer types, both signed and unsigned flavours), >>>> and the sizeof operator yields the size of its operand in bytes >>>> (6.5.3.4(2)), expressed as an integer. Since the Standard does not >>>> require the number of padding bits to equate to a multiple of CHAR_BIT, >>>> and since sizeof has no licence to return a rounded value, it must >>>> therefore be the case that any padding bits are included in the result >>>> of sizeof. >>>> >>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>> >>>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >>>> (see 6.2.5(8), which says the same thing in different words). >>>> >>>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>>> (with no padding) and short to be 24 bits (with 8 bits of padding). >>>> >>> >>> No, >> >> Yes. >> >>> these paragraphs refer to padding BITS, not bytes. >> >> Padding bytes are perfectly legal. And so are padding bits. >> > > Citation? And don't try to tell me bits are the same as bytes. Where > does it say an int can have padding BYTES? The Standard places no upper limit on the number of padding bits a (non-char) integer type may have. It can certainly have CHAR_BIT padding bits, or more. And there are CHAR_BIT bits in a byte. >> For example, it would be legal to have an implementation with CHAR_BIT = >> 11, with shorts being 17 value bits and 27 padding bits (giving 44 bits >> altogether, and sizeof(short) being 4), and ints being 20 value bits and >> 2 padding bits (giving 22 bits altogether, and sizeof(int) being 2). >> > > Citation? 6.2.6.2(1) and 6.2.6.2(2) do not say that. The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed (6.2.6.2(2)) integer types. ISO could easily have defined the relationship of integer types by size including padding, but it chose instead to define that relationship in terms of ranks and value ranges. Now, your claim is that sizeof(short) cannot exceed sizeof(int) - that it is *not permitted*. I have shown why I think it /is/ permitted. What you have not done is shown why you think it isn't. >> That is, it doesn't matter either way. It's perfectly possible and legal >> for sizeof(short) to exceed sizeof(int). What is /not/ legal is for >> SHRT_MAX to exceed INT_MAX. >> > > Again, citation? Where does it say sizeof(short) can exceed sizeof(int)? The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed (6.2.6.2(2)) integer types. ISO could easily have defined the relationship of integer types by size including padding, but it chose instead to define that relationship in terms of ranks and value ranges. -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 20:57 -0400 |
| Message-ID | <nn3o53$6ca$1@jstuckle.eternal-september.org> |
| In reply to | #90923 |
On 7/24/2016 6:44 PM, Richard Heathfield wrote: > On 24/07/16 23:19, Jerry Stuckle wrote: >> On 7/24/2016 5:58 PM, Richard Heathfield wrote: >>> On 24/07/16 22:27, Jerry Stuckle wrote: >>>> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>>>> On 24/07/16 16:06, Jerry Stuckle wrote: >>>>>> On 7/23/2016 8:52 PM, Ben Bacarisse wrote: >>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>>> >>>>>>>> On 7/23/2016 4:38 PM, Malcolm McLean wrote: >>>>>>> <snip> >>>>>>>>> magptr = malloc(40 * sizeof(int)) >>>>>>>>> >>>>>>>>> means allocate 160 bytes and assign to magptr. Which almost always >>>>>>>>> will be a buffer of 40 ints. Possible bugs, someone has changed >>>>>>>>> magptr to use a type other than int, someone has changed the >>>>>>>>> algorithm to require more than 40 integers. >>>>>>>> >>>>>>>> No, it means allocate the amount required for 40 ints and assign >>>>>>>> the >>>>>>>> address to magptr. An int is NOT necessarily 4 bytes. It can >>>>>>>> be any >>>>>>>> length at least as big as a short and not bigger than a long. >>>>>>> >>>>>>> That last bit true of what C calls the width of the types (the >>>>>>> number of >>>>>>> value bits plus one for signed types) but, because of the >>>>>>> possibility of >>>>>>> padding bits, it's not true of the size in bytes. Of course it's >>>>>>> almost >>>>>>> inconceivable that any real implementation would have, for example, >>>>>>> sizeof (short) > sizeof (int) but it is permitted. >>>>>>> >>>>>>> <snip> >>>>>>> >>>>>> >>>>>> It is also the size in bytes. Size of an int does not include any >>>>>> padding. >>>>> >>>>> Yes, it does. See 6.2.6.2(1) and 6.2.6.2(2) (which show that padding >>>>> bits are allowed in integer types, both signed and unsigned flavours), >>>>> and the sizeof operator yields the size of its operand in bytes >>>>> (6.5.3.4(2)), expressed as an integer. Since the Standard does not >>>>> require the number of padding bits to equate to a multiple of >>>>> CHAR_BIT, >>>>> and since sizeof has no licence to return a rounded value, it must >>>>> therefore be the case that any padding bits are included in the result >>>>> of sizeof. >>>>> >>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>> >>>>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed >>>>> INT_MAX >>>>> (see 6.2.5(8), which says the same thing in different words). >>>>> >>>>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>>>> (with no padding) and short to be 24 bits (with 8 bits of padding). >>>>> >>>> >>>> No, >>> >>> Yes. >>> >>>> these paragraphs refer to padding BITS, not bytes. >>> >>> Padding bytes are perfectly legal. And so are padding bits. >>> >> >> Citation? And don't try to tell me bits are the same as bytes. Where >> does it say an int can have padding BYTES? > > The Standard places no upper limit on the number of padding bits a > (non-char) integer type may have. It can certainly have CHAR_BIT padding > bits, or more. And there are CHAR_BIT bits in a byte. > >>> For example, it would be legal to have an implementation with CHAR_BIT = >>> 11, with shorts being 17 value bits and 27 padding bits (giving 44 bits >>> altogether, and sizeof(short) being 4), and ints being 20 value bits and >>> 2 padding bits (giving 22 bits altogether, and sizeof(int) being 2). >>> >> >> Citation? 6.2.6.2(1) and 6.2.6.2(2) do not say that. > > The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed > (6.2.6.2(2)) integer types. ISO could easily have defined the > relationship of integer types by size including padding, but it chose > instead to define that relationship in terms of ranks and value ranges. > It also does not say you can pad BYTES. > Now, your claim is that sizeof(short) cannot exceed sizeof(int) - that > it is *not permitted*. I have shown why I think it /is/ permitted. What > you have not done is shown why you think it isn't. > No, the only thing you have shown is an incorrect interpretation. >>> That is, it doesn't matter either way. It's perfectly possible and legal >>> for sizeof(short) to exceed sizeof(int). What is /not/ legal is for >>> SHRT_MAX to exceed INT_MAX. >>> >> >> Again, citation? Where does it say sizeof(short) can exceed sizeof(int)? > > The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed > (6.2.6.2(2)) integer types. ISO could easily have defined the > relationship of integer types by size including padding, but it chose > instead to define that relationship in terms of ranks and value ranges. > And where does it say you can pad BYTES? The answer is - nowhere. Bits are NOT bytes. Typical language lawyer - can read, but cannot understand. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-25 02:11 +0100 |
| Message-ID | <nn3p0e$8on$1@dont-email.me> |
| In reply to | #90929 |
On 25/07/16 01:57, Jerry Stuckle wrote: > On 7/24/2016 6:44 PM, Richard Heathfield wrote: >> On 24/07/16 23:19, Jerry Stuckle wrote: >>> On 7/24/2016 5:58 PM, Richard Heathfield wrote: >>>> On 24/07/16 22:27, Jerry Stuckle wrote: >>>>> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>>>>> On 24/07/16 16:06, Jerry Stuckle wrote: <snip> >>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>> >>>>>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed >>>>>> INT_MAX >>>>>> (see 6.2.5(8), which says the same thing in different words). >>>>>> >>>>>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>>>>> (with no padding) and short to be 24 bits (with 8 bits of padding). <snip> >> >> The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed >> (6.2.6.2(2)) integer types. ISO could easily have defined the >> relationship of integer types by size including padding, but it chose >> instead to define that relationship in terms of ranks and value ranges. >> > > It also does not say you can pad BYTES. The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed (6.2.6.2(2)) integer types. ISO could easily have defined the relationship of integer types by size including padding, but it chose instead to define that relationship in terms of ranks and value ranges. Which bit of this don't you understand? >> Now, your claim is that sizeof(short) cannot exceed sizeof(int) - that >> it is *not permitted*. I have shown why I think it /is/ permitted. What >> you have not done is shown why you think it isn't. > > No, the only thing you have shown is an incorrect interpretation. I presume you mean it's an interpretation that disagrees with yours. But no, it's not incorrect. >>>> That is, it doesn't matter either way. It's perfectly possible and legal >>>> for sizeof(short) to exceed sizeof(int). What is /not/ legal is for >>>> SHRT_MAX to exceed INT_MAX. >>>> >>> >>> Again, citation? Where does it say sizeof(short) can exceed sizeof(int)? >> >> The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed >> (6.2.6.2(2)) integer types. ISO could easily have defined the >> relationship of integer types by size including padding, but it chose >> instead to define that relationship in terms of ranks and value ranges. >> > > And where does it say you can pad BYTES? It's a silly question. Implementations may use as many padding bits as they like in integer types, and they are under no obligation to ensure that that padding results in the integer sizes obeying any kind of relational ordering. The /range/ of short must not exceed the /range/ of int, but there's no such limitation on /size/. More to the point, where does it say sizeof(short) must not exceed sizeof(int)? That was your claim, that was the claim I was gainsaying, and you have yet to provide even a shred of evidence to support it. <nonsense snipped> -- 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 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web