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 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-27 14:58 +0000 |
| Message-ID | <5798cad0.2436140@news.xs4all.nl> |
| In reply to | #90872 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, July 23, 2016 at 8:47:20 PM UTC+1, Richard Bos wrote: > > > > 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. Bad code, or platform-specific code. > magptr = malloc(40 * sizeof *magptr) > > means create 40 objects of size and type we have to check elsewhere No, it means create 40 objects of the type we're about to use because we're using that pointer, and exact size is irrelevant for now. > magptr = malloc(40 * sizeof(int)) > > means allocate 160 bytes and assign to magptr. No, it doesn't. > Which almost always will be a buffer of 40 ints. The above is _always_ a buffer of 40 ints, not always. It _may_ be 160 bytes. If you need > Possible bugs, someone has changed magptr to use a type other than int, That's a bug in your version, and a dangerous one. In my version, it's not a bug, it's accounted for. > someone has changed the algorithm to require more than 40 integers. That's equally a problem in both versions, and an even greater problem if you blindly suppose you're getting 160 bytes. > Now to what extent do we rely on sizeof(int) being 4? Your version, entirely, which is bad. My version, not at all, which is good. > 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. If the other code relies on ints being exactly 4 bytes, it either documents it with exclamation marks attached, or it's bad code. Either way, it's no reason for the malloc() call to introduce _yet another_ system-dependency for no good reason. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-27 09:14 -0700 |
| Message-ID | <ln1t2fawid.fsf@kst-u.example.com> |
| In reply to | #91137 |
raltbos@xs4all.nl (Richard Bos) writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
[...]
>> magptr = malloc(40 * sizeof(int))
>>
>> means allocate 160 bytes and assign to magptr.
>
> No, it doesn't.
>
>> Which almost always will be a buffer of 40 ints.
>
> The above is _always_ a buffer of 40 ints, not [almost] always. It
> _may_ be 160 bytes. If you need
(I inserted a missing "almost" in the above.)
I think Malcolm is using his own idiosyncratic meaning of the word
"buffer". I can't be bothered to remember what it is, but I suspect
that given his definition, the malloc() call (if successful!) may or may
not create a "buffer". (At least "buffer" isn't a word defined by the
standard.)
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-27 11:55 -0700 |
| Message-ID | <ff0c1e47-a2ea-43c1-bbbc-100e6b8e863a@googlegroups.com> |
| In reply to | #91137 |
On Wednesday, July 27, 2016 at 9:58:55 AM UTC-5, Richard Bos wrote: > > Code relies on basic types being their normal sizes all the time. > > Bad code, or platform-specific code. For over 30 years, the vast majority of C implementations have included 8-, 16-, and 32-bit integer types, and 32- and 64-bit floating-point types. For much of that time, they allowed those types to be accessed using the built-in names "char", "short", "long", "float", and "double". The type "int" would be a 16-bit type on some compilers, and a 32-bit type on others, and some systems used big-endian byte order and some used little- endian, but code could take advantage of "chunking optimizations" to achieve 2x or better speedups while being able to run on the vast majority of platforms if the programmer avoided reliance upon the size of "int" and write one big-endian and one little-endian version of each routine where endian-ness mattered. The C Standards Committee may never have bothered to officially document the dialect of C that was popular in the 1990s, but I'd hardly call code that only runs on the extremely vast majority of C implementations "machine-specific", nor would I call code which runs more than twice as fast as any strictly-conforming equivalent "poorly-written".
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-07-20 19:47 +0000 |
| Message-ID | <slrn3vfsnovlac.c9q.ike@iceland.freeshell.org> |
| In reply to | #90681 |
On 2016-07-20, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Wednesday, July 20, 2016 at 5:09:16 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > On Wednesday, July 20, 2016 at 6:07:50 AM UTC+1, Charles Richmond wrote: >> >> IMHO, a better choice for the standard would have been... to *forbid* any >> >> variable length array type name to be used in sizeof(). >> >> >> > Only types should be passed to sizeof(). >> > In particular, uninitialised pointers should not be dereferenced >> > in a sizeof expression. By a quirk of the language, that happens >> > to be legal. But it's very obviously undesirable. >> >> Are you serious about this, or are you just trolling (or, as you >> called it downthread, "teasing Richard")? >> > It's the double abstraction problem > > magptr = malloc(40 * sizeof(float)); > > tells us that we are asking for 160 bytes of memory. Only if it's guaranteed that sizeof(float) equals four. > 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. If the type of *magptr is such that sizeof *magptr equals four, this still means that 160 bytes are allocated. If sizeof *magptr does not equal four, or if you are not sure about sizeof *magptr, then allocating (40 * sizeof *magptr) bytes is a better idea than allocating 160 bytes if the allocated space is supposed to hold 40 objects of the type that magptr points to. > magptr = malloc(160); > has the opposite problem. We know that we're asking for 160 bytes of > memory, but we don't know why. So write that as 'malloc(40 * 4);'. I still think that's a silly thing to do, but it's probably not as silly as writing 'malloc(160);'.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-20 13:09 -0700 |
| Message-ID | <bd22a477-ec0b-4e43-ad84-da9dc5704adb@googlegroups.com> |
| In reply to | #90688 |
On Wednesday, July 20, 2016 at 8:47:42 PM UTC+1, Ike Naar wrote: > On 2016-07-20, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > > tells us that we are asking for 160 bytes of memory. > > Only if it's guaranteed that sizeof(float) equals four. > Generally it is. You can always check and fail if that's a requirement, which it could well be, especially in a context where it's important to know how much memory is being used. And even of float isn't 4 bytes, 160 bytes is still a ballpark figure. sizeof *magptr could be 10K. A float is unlikely to go above a few bytes.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-07-20 20:49 +0000 |
| Message-ID | <slrn3vfsnovouk.mbc.ike@iceland.freeshell.org> |
| In reply to | #90693 |
On 2016-07-20, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Wednesday, July 20, 2016 at 8:47:42 PM UTC+1, Ike Naar wrote: >> On 2016-07-20, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >> > >> > tells us that we are asking for 160 bytes of memory. >> >> Only if it's guaranteed that sizeof(float) equals four. >> > Generally it is. > You can always check and fail if that's a requirement, which > it could well be, especially in a context where it's important > to know how much memory is being used. > > And even of float isn't 4 bytes, 160 bytes is still a ballpark > figure. But it would be the wrong ballpark figure if you use malloc(40 * 4); and it would be the proper ballpark figure if you use malloc(40 * sizeof(float)); > sizeof *magptr could be 10K. A float is unlikely to go above a > few bytes. That seems to contradict your earlier assertion that 4 == sizeof *magptr. If sizeof *magptr could be 10K, then why on earth would you allocate 40 * 4 bytes to hold 40 objects of size 10K?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-20 14:35 -0700 |
| Message-ID | <605cbcbe-1aec-460c-af90-63f5bde20736@googlegroups.com> |
| In reply to | #90696 |
On Wednesday, July 20, 2016 at 9:49:44 PM UTC+1, Ike Naar wrote: > On 2016-07-20, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > And even of float isn't 4 bytes, 160 bytes is still a ballpark > > figure. > > But it would be the wrong ballpark figure if you use > > malloc(40 * 4); > > and it would be the proper ballpark figure if you use > > malloc(40 * sizeof(float)); > Sure. We see 40 * sizeof(float) and mentally translate to "160 bytes". Now if it is crucial that that object doesn't go above 160 bytes, and floats are in fact 8 bytes, then of course we're wrong. But if we're not interested in objects under 1K, because they're not going to make any difference in the great scheme of things, then to think of it as 160 bytes isn't too bad an error. > > > sizeof *magptr could be 10K. A float is unlikely to go above a > > few bytes. > > That seems to contradict your earlier assertion that 4 == sizeof *magptr. > If sizeof *magptr could be 10K, then why on earth would you allocate > 40 * 4 bytes to hold 40 objects of size 10K? > We see the line magptr = malloc(40 * sizeof *magptr); so how much memory is that? If we're not interested in allocations under 1K because they aren't going to make any difference in the great scheme of things, do we skip over this line, or is it in fact the reason our program is failing?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-20 09:01 -0700 |
| Message-ID | <lninw0mh81.fsf@kst-u.example.com> |
| In reply to | #90638 |
"Charles Richmond" <numerist@aquaporin4.com> writes:
[...]
> IMHO, a better choice for the standard would have been... to *forbid*
> any variable length array type name to be used in sizeof().
I presume you'd permit a VLA *expression* to be used in sizeof.
(If not, it would make VLAs much less useful.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-20 08:59 -0700 |
| Message-ID | <lnmvlcmhai.fsf@kst-u.example.com> |
| In reply to | #90635 |
Udyant Wig <udyant.wig@gmail.com> writes:
> 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.
That would probably be a sensible rule, but it's not what the standard
says.
N1570 6.5.3.4p2:
If the type of the operand is a variable length array type, the
operand is evaluated; otherwise, the operand is not evaluated
and the result is an integer constant.
That still leaves some open questions (which have been discussed
at some length).
The phrase "integer constant" is used incorrectly. An "integer
constant" is by definition a decimal, octal, or hexadecimal constant.
It should say "integer constant expression".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-20 09:24 -0700 |
| Message-ID | <kfn8twwuvkl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90631 |
Keith Thompson <kst-u@mib.org> writes:
> 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. [...]
Please excuse a small correction. A sizeof operand is evaluated
if (and only if) it has variable length array type. All variable
length array types are variably modified types, but not all
variably modified types are variable length array types.
void
foo( int n ){
int x[n]; // x has a VLA type
int (*y)[n] = &x; // y has VM type, but not VLA type
sizeof y++; // operand is not evaluated
sizeof *y++; // operand is evaluated
}
> 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));
> }
Another way is to ensure the evaluation has defined behavior, as
for example:
#include <stdlib.h>
void *valid_all;
int main(void) {
valid_all = malloc(1); // and check for success...
int n = 10;
typedef int vla[n];
vla *p = malloc(sizeof *(p = valid_all));
}
At level O1 (and above, presumably), gcc is smart enough to
optimize away the redundant assignment in such cases.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-20 11:28 -0700 |
| Message-ID | <lnshv4kvul.fsf@kst-u.example.com> |
| In reply to | #90670 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> 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. [...]
>
> Please excuse a small correction. A sizeof operand is evaluated
> if (and only if) it has variable length array type. All variable
> length array types are variably modified types, but not all
> variably modified types are variable length array types.
Quite right. I hadn't realized that.
Which means, for example, that a structure or union cannot have a member
whose type is a pointer to a VLA type. I can't think of any good reason
for that particular restriction (such a pointer type must have a fixed
size, even for an implementation that uses fat pointers), and I wonder
if it was intended. On the other hand, such a structure or union would
rarely be useful, since variably modified types can be defined and used
only within a single function.
[...]
>> 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));
>> }
>
> Another way is to ensure the evaluation has defined behavior, as
> for example:
>
> #include <stdlib.h>
>
> void *valid_all;
>
> int main(void) {
> valid_all = malloc(1); // and check for success...
> int n = 10;
> typedef int vla[n];
> vla *p = malloc(sizeof *(p = valid_all));
> }
>
> At level O1 (and above, presumably), gcc is smart enough to
> optimize away the redundant assignment in such cases.
Sure. It seems a bit convoluted, though.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-21 18:38 -0700 |
| Message-ID | <kfninvytptq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90678 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> 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. [...]
>>
>> Please excuse a small correction. A sizeof operand is evaluated
>> if (and only if) it has variable length array type. All variable
>> length array types are variably modified types, but not all
>> variably modified types are variable length array types.
>
> Quite right. I hadn't realized that.
>
> Which means, for example, that a structure or union cannot have a member
> whose type is a pointer to a VLA type. I can't think of any good reason
> for that particular restriction (such a pointer type must have a fixed
> size, even for an implementation that uses fat pointers), and I wonder
> if it was intended. On the other hand, such a structure or union would
> rarely be useful, since variably modified types can be defined and used
> only within a single function.
My guess is it just was easier to disallow it than to try to
think through the implications of allowing it. Since allowing
it has close to zero utility, a cost/benefit analysis easily
comes down on the side of ruling it out.
>>> 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));
>>> }
>>
>> Another way is to ensure the evaluation has defined behavior, as
>> for example:
>>
>> #include <stdlib.h>
>>
>> void *valid_all;
>>
>> int main(void) {
>> valid_all = malloc(1); // and check for success...
>> int n = 10;
>> typedef int vla[n];
>> vla *p = malloc(sizeof *(p = valid_all));
>> }
>>
>> At level O1 (and above, presumably), gcc is smart enough to
>> optimize away the redundant assignment in such cases.
>
> Sure. It seems a bit convoluted, though.
Written as a single example, I agree. But it might make
sense if hidden under a layer of abstraction, eg, a NEW()
macro along the lines of examples mentioned in the group
now and then.
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2016-07-20 22:10 +0200 |
| Message-ID | <jlmvob1hlikf22bjqfou0raheep1qlcs0a@4ax.com> |
| In reply to | #90631 |
On Tue, 19 Jul 2016 15:30:06 -0700, Keith Thompson wrote:
>A simple example:
>
> #include <stdlib.h>
> int main(void) {
> int n = 10;
> int (*p)[n] = malloc(sizeof *p);
i would never write (*p)[n] i use only "int *p"
in case above
int (*p)[n]=malloc(n*sizeof(int));
if that compile...
> }
>
>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.
[toc] | [prev] | [next] | [standalone]
| From | Anand Hariharan <mailto.anand.hariharan@gmail.com> |
|---|---|
| Date | 2016-07-20 16:16 -0700 |
| Message-ID | <d7eb9912-f53b-4450-9f67-2cd7e055e0db@googlegroups.com> |
| In reply to | #90631 |
On Tuesday, July 19, 2016 at 5:30:16 PM UTC-5, Keith Thompson wrote: > 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); > There are three points to justify this idiom: 1. The point being discussed in this thread 2. sizeof should not parenthesize its operand unless it is a type 3. Take advantage of C's implicit conversion from void* to some_type* Would you consider discussing #2 and #3? #2 is a style issue. Why not parenthesize expressions? With typedefs and preprocessor, and considering that not everyone writing C is a language lawyer, the line that divides what is a type and what is an expression becomes rather faint. As a style, it is consistent to always parenthesize. Regarding #3, with C99 onwards, prototypes are required, and there is no more implicit int. There is no danger of the cast masking an egregious error. There is no implicit conversion between T1* and T2*, so should the type of allocated pointer be changed, the compiler will emit a diagnostic. IME C-like code gets written in C++ environments quite a lot, the cast makes the code usable in such instances. --
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-20 19:56 -0700 |
| Message-ID | <ln37n3lmwn.fsf@kst-u.example.com> |
| In reply to | #90702 |
Anand Hariharan <mailto.anand.hariharan@gmail.com> writes:
> On Tuesday, July 19, 2016 at 5:30:16 PM UTC-5, Keith Thompson wrote:
>> 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);
>>
>
> There are three points to justify this idiom:
>
> 1. The point being discussed in this thread
>
> 2. sizeof should not parenthesize its operand unless it is a type
>
> 3. Take advantage of C's implicit conversion from void* to some_type*
>
> Would you consider discussing #2 and #3?
Sure.
> #2 is a style issue. Why not parenthesize expressions? With typedefs
> and preprocessor, and considering that not everyone writing C is a
> language lawyer, the line that divides what is a type and what is an
> expression becomes rather faint. As a style, it is consistent to always
> parenthesize.
I suggest that the burden of proof is on the argument to *add* the
parentheses.
There are two distinct forms of sizeof, one that takes an expression and
one that takes a parenthesized type name. They're different constructs.
In my opinion, as a matter of style they *should* look different.
> Regarding #3, with C99 onwards, prototypes are required, and there is no
> more implicit int.
Quibble: Neither C99 or C11 requires prototypes. Old-style function
declarations are still permitted (though they've been obsolescent since
C89/C90). That doesn't affect your argument, though.
> There is no danger of the cast masking an egregious
> error. There is no implicit conversion between T1* and T2*, so should
> the type of allocated pointer be changed, the compiler will emit a
> diagnostic.
Not all compilers emit all the diagnostics they're supposed to, and gcc
is notorious for issuing warnings (which are too easy to ignore) for
type mismatches.
Similarly, I suggest that the burden of proof is on the argument in
favor of adding the cast.
> IME C-like code gets written in C++ environments quite a lot,
> the cast makes the code usable in such instances.
If I were writing code intended to be compiled both as C and as C++, I'd
cast the result of malloc() simply because I'd have to.
When I write C code, I don't go out of my way to make it compilable as
C++. Indeed, making it *invalid* C++ will remind anyone who wants to
compile it as C++ that they need to take a close look at it, and makes
it clear that it's never been tested as C++.
In most (but admittedly not all) cases, it's better to use C++'s
cross-language features (`extern "C"` et al) and compile C as C and C++
as C++.
--
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 | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-21 18:46 +0530 |
| Message-ID | <nmqhvg$86c$1@dont-email.me> |
| In reply to | #90702 |
[I wish to discuss just point 2 at present.] On 07/21/2016 04:46 AM, Anand Hariharan wrote: > [elided] > > 2. sizeof should not parenthesize its operand unless it is a type > > Would you consider discussing #2 and #3? > > #2 is a style issue. Why not parenthesize expressions? With typedefs > and preprocessor, and considering that not everyone writing C is a > language lawyer, the line that divides what is a type and what is an > expression becomes rather faint. As a style, it is consistent to > always parenthesize. Short of being a language lawyer, I think every programmer of a language with a reference/standard should have access to an authoritative copy of the reference/standard. I accept, as Keith Thompson points out, that sizeof can be applied in two different ways. One form necessitates parentheses, and in the other it is permissible. The majority view, as I understand it, is to not use parentheses in the form that does not require it. This is the position of a number of prominent and respected participants in this newsgroup and in other fora. The minority view is that since parentheses are permitted in one form and mandated in the other, one should simply use them in all cases, thus dispensing with needing to handle each case separately. This position is held by Linus Torvalds, besides others. (I had referred to a mail by Linus Torvalds to the Linux Kernel Mailing List a few days ago. I found another one today. <URL:http://lkml.iu.edu/hypermail/linux/kernel/1207.1/00933.html> I quote most of the relevant parts here: sizeof without parenthesis is an abomination, and should never be used. Sure, you don't need to have the parenthesis (except when you do - for actual types), but it's a parsing oddity. The sane solution is: just add the f*cking parenthesis, and don't use the parsing oddity. The parenthesis are *required* when it is a type, and they are a nice clarification (and makes the code easier to read) when it's an expression. Not having them is insane, because it just makes it clear how odd the parsing rules are for the two different cases. And talking about "prefix operators" is a moronic thing to do. It does *not* look like a prefix operator, and it does not even *act* like a prefix operator (look at types, where it really does require the parenthesis). But most importantly, it's not how sane people think about it. Think of it as a function, and get over your idiotic pissing match over how long you've both known C. That's irrelevant. It's a C builtin function with (unnecessarily) odd parsing rules that the kernel tries to standardize. The fact that it can take a type is the least odd part of it (there are other built-in C extensions that look like functions and do special things with the arguments they get - __builtin_constant_p(), __builtin_choose_expr() etc - they don't evaluate the *value* of the argument either). Btw, the spacing rule is separate, and the "3.1 Spaces" thing was added later and is in fact somewhat misleading. The spacing rules have nothing to do with "function-vs-keyword", and everything to do with "function-vs-control-flow". So "sizeof()" is not actually an exception at all, like the docs state: it's perfectly regular. It looks and acts as a function, not as a control flow operation.) -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-07-21 17:20 +0000 |
| Message-ID | <slrn3vfsnp212e.nqu.ike@iceland.freeshell.org> |
| In reply to | #90718 |
On 2016-07-21, Udyant Wig <udyant.wig@gmail.com> wrote: > The sane solution is: just add the f*cking parenthesis, and don't use > the parsing oddity. > > The parenthesis are *required* when it is a type, and they are a nice > clarification (and makes the code easier to read) when it's an > expression. Not having them is insane, because it just makes it clear > how odd the parsing rules are for the two different cases. > > And talking about "prefix operators" is a moronic thing to do. It does > *not* look like a prefix operator, and it does not even *act* like a > prefix operator (look at types, where it really does require the > parenthesis). But most importantly, it's not how sane people think > about it. According to the C standard, sizeof is an operator (6.5.3.4). Its operand is either an expression or a parenthesized type name. In case of the type name, the parentheses are not part of the sizeof operator (to make it look like a function), they are part of the operand (to make it look like a parenthesized type name). > Think of it as a function, and get over your idiotic pissing match > over how long you've both known C. That's irrelevant. It's a C builtin > function with (unnecessarily) odd parsing rules that the kernel tries > to standardize. So you say. The standard says it's an operator, not a built-in function. What do kernels have to do with this? Which kernel tries to standardize odd parsing rules? And by the way, do you think using street language helps to make your point?
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-22 18:03 +0530 |
| Message-ID | <nmt3qg$7ou$1@dont-email.me> |
| In reply to | #90729 |
Ike Naar, which part of "I quote most of the relevant parts here:" in On 07/21/2016 06:46 PM, Udyant Wig wrote: > (I had referred to a mail by Linus Torvalds to the Linux Kernel > Mailing List a few days ago. I found another one today. > <URL:http://lkml.iu.edu/hypermail/linux/kernel/1207.1/00933.html> > I quote most of the relevant parts here: > > [quoting Linus Torvalds elided] did you not get? -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-21 15:39 -0400 |
| Message-ID | <nmr8cm$rep$1@dont-email.me> |
| In reply to | #90718 |
On 07/21/2016 09:16 AM, Udyant Wig wrote: ... > And talking about "prefix operators" is a moronic thing to do. It does > *not* look like a prefix operator, and it does not even *act* like a > prefix operator (look at types, where it really does require the > parenthesis). ... What do you think prefix operators look like? My only expectation for prefix operators is that they precede the the thing that they operate on, and sizeof certainly meets that criterion. > ... But most importantly, it's not how sane people think > about it. Well, that's not the first time I've been accused of insanity. > Think of it as a function, Whenever I try thinking of it as a function, I stumble over a couple of things: sizeof(5)[array] and sizeof(sin)(0) were two examples of the stumbling blocks.
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-22 18:04 +0530 |
| Message-ID | <nmt3sq$7ou$2@dont-email.me> |
| In reply to | #90737 |
James Kuyper, which part of "I quote most of the relevant parts here:" in On 07/21/2016 06:46 PM, Udyant Wig wrote: > (I had referred to a mail by Linus Torvalds to the Linux Kernel > Mailing List a few days ago. I found another one today. > <URL:http://lkml.iu.edu/hypermail/linux/kernel/1207.1/00933.html> > I quote most of the relevant parts here: > > [quoting Linus Torvalds elided] did you not get? -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
Page 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web