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 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-22 13:44 -0400 |
| Message-ID | <nmtm18$9f4$1@dont-email.me> |
| In reply to | #90778 |
On 07/22/2016 08:34 AM, Udyant Wig wrote: > 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? Well, for one thing, I can't be certain where your quote started and ended, because you didn't use any of the methods conventionally used to indicate that fact. Four of the most common ways of doing this are bracketing quoted material with quote marks or html-like tags, preceding each line of quoted material with ">" (see above for an example), or indentation of the quoted material. Oddly enough, your comment about quoting him was indented, relative to what I think was the quoted material, which is precisely the reverse of one of the standard ways of marking quoted material. However, that's hardly relevant, it doesn't matter to me whether the text I was responding to was written by you or by Linus Torvalds. Either way, when I said "you", I was referring to the author of the text. Furthermore, if your citation of his words was not intended as an endorsement of what he said, then you should have provided more explanation of why you were bothering to cite them. If you do endorse what he said, than you are just as valid a target for my use of "you" as Linus was. As such, what I said contains a question that you should be able to answer - and you didn't. It also ended with a comment that I hoped you might respond to in some meaningful fashion, but since you bothered responding in this fashion, I doubt that will ever happen.
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-23 15:38 +0530 |
| Message-ID | <nmvfmm$d4j$2@dont-email.me> |
| In reply to | #90797 |
On 07/22/2016 11:14 PM, James Kuyper wrote: > Well, for one thing, I can't be certain where your quote started and > ended, because you didn't use any of the methods conventionally used > to indicate that fact. Four of the most common ways of doing this are > bracketing quoted material with quote marks or html-like tags, > preceding each line of quoted material with ">" (see above for an > example), or indentation of the quoted material. Oddly enough, your > comment about quoting him was indented, relative to what I think was > the quoted material, which is precisely the reverse of one of the > standard ways of marking quoted material. I have since gone back to convention. > However, that's hardly relevant, it doesn't matter to me whether the > text I was responding to was written by you or by Linus > Torvalds. Either way, when I said "you", I was referring to the author > of the text. Furthermore, if your citation of his words was not > intended as an endorsement of what he said, then you should have > provided more explanation of why you were bothering to cite them. I had written in the article that you replied to that there are two schools of thought concerning parenthesizing the arguments of sizeof. The minority view is that they should be put in parentheses in all cases. Linus Torvalds has expressed this view on a few occasions, in the Linux kernel mailing list at least. Hence my citation. > If you do endorse what he said, than you are just as valid a target > for my use of "you" as Linus was. As such, what I said contains a > question that you should be able to answer - and you didn't. It also > ended with a comment that I hoped you might respond to in some > meaningful fashion, but since you bothered responding in this fashion, > I doubt that will ever happen. Please check again. -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyant.wig@gmail.com> |
|---|---|
| Date | 2016-07-23 15:36 +0530 |
| Message-ID | <nmvfk6$d4j$1@dont-email.me> |
| In reply to | #90737 |
On 07/22/2016 01:09 AM, James Kuyper wrote: > 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. From what I read and gathered from that lkml thread, I guess that Linus Torvalds was objecting to treating sizeof as a prefix operator because other prefix operators such as prefix ++ and -- operate on lvalues whereas sizeof, by admitting use of type names, does not (at least not wholly.) >> ... 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. I get your point and I get Linus'. Surely you are aware of Linus Torvalds' fondness of hyperbole. He himself has said that he uses extremes to emphasize a point. >> 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. I can parse the first as the (not recommended) equivalent to array[5]. Perhaps you could also have written sizeof(5[array])? For the second, perhaps the misapplied parentheses were your cause of stumbling? Might sizeof(sin(0)) have been the intent? -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-23 13:08 -0400 |
| Message-ID | <ed145e7c-5198-20e4-ed78-51740b44e837@verizon.net> |
| In reply to | #90840 |
On 07/23/2016 06:06 AM, Udyant Wig wrote:
> On 07/22/2016 01:09 AM, James Kuyper wrote:
>> 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.
>
> From what I read and gathered from that lkml thread, I guess that Linus
> Torvalds was objecting to treating sizeof as a prefix operator because
> other prefix operators such as prefix ++ and -- operate on lvalues
> whereas sizeof, by admitting use of type names, does not (at least not
> wholly.)
sizeof is certainly a different kind of operator, but it's still an
operator, it just operates on types as well as values (even for values,
it operates only on the type of the value). In any event, if that's what
he meant, then he would have conveyed his objection more clearly by
using the term "operator" rather than "prefix operator". Using the more
specific term gives the impression that his objections were specific to
the way in which that term differs from the more general one.
As of C2011, sizeof is no longer unique in it's peculiarities:
_Alignof(type-name) is exactly syntactically parallel to
sizeof(type-name), and _Generic is another new operator that takes the
form of a (reserved) identifier. Like "sizeof expression",
_Generic(expression, ...) does not evaluate its expression, and has
semantics that depend only upon the type of that expression.
Note: the standard does not provide a general definition for "operator".
6.4.6 specifies that when a punctuator specifies an operation to be
performed, it is known as an operator, but it also specifies "other
forms of operators exist". Most of the sections under 6.5 have titles
that contain "operator", allowing us to conclude that the things they
describe are all operators. However, 6.5.1, uses the term "expression"
rather than "operator". On the other hand, 6.5p1 specifies that "An
expression is a sequence of operators and operands ..." - _Generic
cannot by any means be considered an operand of a generic-selection, so
"operator" is the only plausible alternative.
...
>>> 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.
>
> I can parse the first as the (not recommended) equivalent to array[5].
> Perhaps you could also have written sizeof(5[array])? For the second,
> perhaps the misapplied parentheses were your cause of stumbling?
> Might sizeof(sin(0)) have been the intent?
You're missing my point. sizeof(5)[array] is a syntactically correct C
expression, equivalent to sizeof(5[array]). But if sizeof were a
function, it would necessarily be equivalent to (sizeof 5)[array] (or
more conventionally, array[sizeof 5]).
Similarly, sizeof(sin)(0) is a syntactically correct C expression,
equivalent to sizeof(sin(0)). But if sizeof were a function, then it
would be equivalent to (sizeof sin)(0), which would be a syntax error.
The key point is that when you write sizeof(expression), the parentheses
are NOT part of a function call syntax. They serve only to make the
expression they surround a primary-expression. Since the right operand
of sizeof is a unary-expression, if sizeof is followed by a unary
expression that starts with a parenthesized expression, the entire unary
expression will be the right operand of the sizeof operator, not just
the parenthesized part. That's a key difference from the way sizeof
would be treated if it were a function.
Perhaps it would have been better if I had chosen for my parenthesized
expressions ones where the parentheses are actually necessary, because
they have a lower precedence than postfix-expressions.
Every unary expression that is not a postfix-expression starts with an
operator. The first part therefore cannot be parenthesized, which is why
all of my examples are postfix-expressions:
sizeof (pointer+integer1)[integer2]
sizeof ((function_type *)function_ptr)(argument)
sizeof (*struct_ptr).member
sizeof (struct_ptr+integer)->member
sizeof (int[]){1, 2, 3}
For completeness, I'll include the following, even though the
parenthesis are clearly unnecessary in these cases:
sizeof (x)++
sizeof (y)--
Misinterpreting sizeof as if it were a function would make you
misinterpret each of those expressions as a syntax error.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-23 13:23 -0700 |
| Message-ID | <lnlh0sf6id.fsf@kst-u.example.com> |
| In reply to | #90848 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 07/23/2016 06:06 AM, Udyant Wig wrote:
>> On 07/22/2016 01:09 AM, James Kuyper wrote:
>>> 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.
>>
>> From what I read and gathered from that lkml thread, I guess that Linus
>> Torvalds was objecting to treating sizeof as a prefix operator because
>> other prefix operators such as prefix ++ and -- operate on lvalues
>> whereas sizeof, by admitting use of type names, does not (at least not
>> wholly.)
>
> sizeof is certainly a different kind of operator, but it's still an
> operator, it just operates on types as well as values (even for values,
> it operates only on the type of the value). In any event, if that's what
> he meant, then he would have conveyed his objection more clearly by
> using the term "operator" rather than "prefix operator". Using the more
> specific term gives the impression that his objections were specific to
> the way in which that term differs from the more general one.
>
> As of C2011, sizeof is no longer unique in it's peculiarities:
> _Alignof(type-name) is exactly syntactically parallel to
> sizeof(type-name), and _Generic is another new operator that takes the
> form of a (reserved) identifier. Like "sizeof expression",
> _Generic(expression, ...) does not evaluate its expression, and has
> semantics that depend only upon the type of that expression.
I'm not convinced that _Generic is an operator. The standard doesn't
call it that, and a generic-selection is a primary-expression.
> Note: the standard does not provide a general definition for
> "operator".
As you say, the standard doesn't define the word "operator", probably
because it doesn't particularly need to. Defining what is or is not
an "operator" is not strictly necessary for a rigorous, consistent,
and correct definition of the syntax and semantics of expressions.
It's unfortunate that the standard's definition of "expression" is "a
sequence of operators and operands ...". Expressions include constructs
that are neither operators nor operands (consider 42, for example).
The C++ standard has similar wording, but in a non-normative note. It
defers to the syntax for the actual definition of "expression". I'd
like to see a future C standard do the same thing.
Ultimately it doesn't matter much whether "sizeof" is an "operator"
or not. I call it an operator because the standard explicitly says
it is one. It would have been equally reasonable for the standard
to restrict the use of the word "operator" to things that have
expressions as operands and whose results depend solely on the
result of evaluating those operands. `sizeof ...` and `_Generic
( ... )` might be called "special forms" or something, or there
might be a special name for "sizeof-expression". It might also
have been reasonable to have a *wider* definition of "operator",
so that *every* expression has a top-level operator (constants
might be considered nullary operators).
But whether we think of "sizeof" as an operator or not, the one
thing that's perfectly clear is that it is not a function, at least
not if you accept the way the C standard defines and uses the word
"function".
[...]
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-23 19:57 +0100 |
| Message-ID | <nn0enl$frc$5@dont-email.me> |
| In reply to | #90840 |
On 23/07/16 11:06, Udyant Wig wrote: > On 07/22/2016 01:09 AM, James Kuyper wrote: >> 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. > > From what I read and gathered from that lkml thread, I guess that Linus > Torvalds was objecting to treating sizeof as a prefix operator because > other prefix operators such as prefix ++ and -- operate on lvalues > whereas sizeof, by admitting use of type names, does not (at least not > wholly.) > >>> ... 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. > > I get your point and I get Linus'. Surely you are aware of Linus > Torvalds' fondness of hyperbole. He himself has said that he uses > extremes to emphasize a point. The most important point he emphasises by using abusive language is that he is not interested in being considered an adult. -- 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-23 13:03 -0700 |
| Message-ID | <lnpoq4f7fo.fsf@kst-u.example.com> |
| In reply to | #90840 |
Udyant Wig <udyant.wig@gmail.com> writes:
> On 07/22/2016 01:09 AM, James Kuyper wrote:
>> 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.
>
> From what I read and gathered from that lkml thread, I guess that Linus
> Torvalds was objecting to treating sizeof as a prefix operator because
> other prefix operators such as prefix ++ and -- operate on lvalues
> whereas sizeof, by admitting use of type names, does not (at least not
> wholly.)
It's not about lvalues. The &, *, +, -, ~, and ! unary operators
do not require an lvalue operand.
[...]
--
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-24 08:06 -0700 |
| Message-ID | <kfntwffrs7k.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90869 |
Keith Thompson <kst-u@mib.org> writes:
> Udyant Wig <udyant.wig@gmail.com> writes:
>> On 07/22/2016 01:09 AM, James Kuyper wrote:
>>> 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.
>>
>> From what I read and gathered from that lkml thread, I guess that Linus
>> Torvalds was objecting to treating sizeof as a prefix operator because
>> other prefix operators such as prefix ++ and -- operate on lvalues
>> whereas sizeof, by admitting use of type names, does not (at least not
>> wholly.)
>
> It's not about lvalues. The &, *, +, -, ~, and ! unary operators
> do not require an lvalue operand.
>
> [...]
The unary & operator almost requires an lvalue, at least
implicitly. The only exception is expressions of function type,
which are kind of "lvalues for functions". And & is like {++,--}
in that applying & to a cast expression is never valid.
All of that is incidental to your point, I just thought it might
be interesting.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-24 14:17 -0700 |
| Message-ID | <lnmvl6enxs.fsf@kst-u.example.com> |
| In reply to | #90900 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> It's not about lvalues. The &, *, +, -, ~, and ! unary operators
>> do not require an lvalue operand.
>>
>> [...]
>
> The unary & operator almost requires an lvalue, at least
> implicitly. The only exception is expressions of function type,
> which are kind of "lvalues for functions". And & is like {++,--}
> in that applying & to a cast expression is never valid.
You're right, of course; I just missed that.
> All of that is incidental to your point, I just thought it might
> be interesting.
Indeed. And my previous statement still applies to unary *, +, -,
~, and !.
--
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 19:45 -0700 |
| Message-ID | <kfna8hatmq6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90718 |
Udyant Wig <udyant.wig@gmail.com> writes: > [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. > > [...] 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. [...] Out of curiosity I looked through 'sizeof' usages in several dozen open-source software packages. A 'sizeof' expression without a following parenthesis was about 7% of the total. Looking over the list by eye (and in particular without doing any parsing), about 2/3 of all sizeof expressions were using type names (which of course require parentheses). That means redundant parentheses with sizeof outnumber unparenthesized operands by about 3 or 4 to 1. (I assumed without looking carefully that almost none of the parenthesized non-type operands required parentheses for other reasons.) It would not surprise me if these results were typical of most C code. I should add, though, that of the packages I looked at, roughly 90% had sizeof expressions both with and without redundant parentheses (ie, of those that had sizeof at all, which not all did). No conclusions to offer, I just thought people might be interested.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-22 13:13 +0100 |
| Message-ID | <nmt2mh$3sk$1@dont-email.me> |
| In reply to | #90748 |
On 22/07/2016 03:45, Tim Rentsch wrote: > Udyant Wig <udyant.wig@gmail.com> writes: > >> [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. >> >> [...] 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. [...] > > Out of curiosity I looked through 'sizeof' usages in several > dozen open-source software packages. A 'sizeof' expression > without a following parenthesis was about 7% of the total. > Looking over the list by eye (and in particular without doing > any parsing), about 2/3 of all sizeof expressions were using > type names (which of course require parentheses). That means > redundant parentheses with sizeof outnumber unparenthesized > operands by about 3 or 4 to 1. (I assumed without looking > carefully that almost none of the parenthesized non-type > operands required parentheses for other reasons.) It would > not surprise me if these results were typical of most C > code. So 93% of usage had parentheses. That means it wouldn't have been a great imposition if the language had required them even for expressions. Of course your study doesn't tell us /why/ the ~80% of sizeof with expression used parentheses: * Maybe they were needed because the expression was complex. * Or maybe people couldn't remember the rule about when they are needed (that would be me) * Or maybe they do remember, but put them in to make it absolutely to everyone else. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-21 19:23 -0700 |
| Message-ID | <kfneg6mtnqs.fsf@x-alumni2.alumni.caltech.edu> |
| 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?
I will take them up in reverse order.
> 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.
One, this assumes that the code is going to be compiled under
C99-or-later rules, and that may not be true. Two, using a cast
violates the factoring principle, and adds extra work in the
event that the type changes. Three, remember the lesson from
"The boy who cried wolf". Casts are dangerous, and the more
of them there are the easier it is to be cavalier about them.
It is better IMO to use a cast only as a last resort, when all
other avenues have been exhausted. Obviously that is not the
case here.
The point about C++ is backwards IMO. If code is intended
for C++, it should use 'new', not malloc(). If code is
intended for C, it shouldn't be compiled as C++, because
of subtle differences between the two languages. It's
better for the code to get a diagnostic than to use a
cast in case it is compiled as C++. This is another
example of the dangers of overusing casting.
> #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.
First there are two concerns, reading and writing, and the
more important concern is reading. Any serious C developer
should be able to read a 'sizeof' expression either with
or without redundant parentheses, and quickly and easily
assimilate/understand either form. Anything less is a
deficiency.
For writing, there are pros and cons for both positions (ie,
either always use parentheses, or use parentheses only when
necessary because of precedence relationships). Personally I
find the arguments in favor of using parentheses only when
necessary more persuasive, but I understand that other people
have different weighting factors for the plusses and minusses.
Recognizing that, IMO it is better not to have a single rule,
and just accept that different developers will make different
choices here. There are more important things to worry about.
I will say one other thing about using parentheses with sizeof.
If one is determined to (sometimes) use extra parentheses with
sizeof "for clarity", an alternative style rule that should be
considered is putting parentheses around the sizeof expression as
a whole. Under this rule the second code line above would be
written as
some_type *ptr = malloc(N * (sizeof *ptr))
Personally I think this gives a better result than writing
'sizeof' expressions so that they look like functions. (And
of course OPMMV.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-21 20:02 -0700 |
| Message-ID | <0def6c1e-9b42-43d9-9280-393dfc0f6bf4@googlegroups.com> |
| In reply to | #90747 |
On Friday, July 22, 2016 at 3:23:17 AM UTC+1, Tim Rentsch wrote: > > First there are two concerns, reading and writing, and the > more important concern is reading. Any serious C developer > should be able to read a 'sizeof' expression either with > or without redundant parentheses, and quickly and easily > assimilate/understand either form. Anything less is a > deficiency. > One of the faults of C is that it is too easy to generate cryptic expressions, due to pointer derefencing, assignment yielding values, the sheer number of levels of precedence and operators, the odd rule that postfix ++ has high precedence for binding but is applied last. What makes an expression "cryptic?" Firstly, obviously, it's complicated. Secondly, it doesn't mean anything outside of the context of C. You couldn't give it to a non-C programmer and have him instantly tell you what must be intended. A few years ago, you could be pretty sure that a programmer presented with C would be a C programmer. It was the default programming language that everyone used. That's less the case now. Quite commonly, programs are written mainly in other languages, with C confined to the algorithmic core. The algorithmic core is often logically or mathematically difficult, the non-C programmer is uncomfortable with it and already out of his depth. So the steps need to be very simple. Now anyone can glance at sizeof(int) and tell you what must be intended. 4 bytes. sizeof *xarray ? xarray is an array that holds integer x values in some complicated algorithm, he can see that because there are lines like xarray[Nx -i] = size*j; But what does sizeof *xarray mean? It's cryptic.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-22 07:57 +0100 |
| Message-ID | <nmsg4a$8tc$1@dont-email.me> |
| In reply to | #90749 |
On 22/07/16 04:02, Malcolm McLean wrote: <snip> > > Now anyone can glance at sizeof(int) and tell you what must be > intended. 4 bytes. No, sizeof(int) bytes must be intended. That may be 4, or it may be 1 or 2 or 3 or 5 or 117; but, whatever happens, it's sizeof(int) bytes. > sizeof *xarray ? xarray is an array that > holds integer x values in some complicated algorithm, he can > see that because there are lines like xarray[Nx -i] = size*j; No, all you can say about xarray from a line like that is that it is an array or possibly a pointer. There is no reason to conclude that it holds integer values. > But what does sizeof *xarray mean? It's cryptic. No, it's trivial. It means the number of bytes required to store *xarray. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-22 00:18 -0700 |
| Message-ID | <87de1c4a-56ce-4840-8567-f7c55d12384a@googlegroups.com> |
| In reply to | #90751 |
On Friday, July 22, 2016 at 7:57:24 AM UTC+1, Richard Heathfield wrote: > On 22/07/16 04:02, Malcolm McLean wrote: > > > But what does sizeof *xarray mean? It's cryptic. > > No, it's trivial. It means the number of bytes required to store *xarray. > Yes it is trivial. Also cryptic. It's not that the operation is fundamentally sophisticated of difficult. All we mean is "4 bytes". But you wouldn't know unless you had the key. So it's an encrypted way of saying "4 bytes" If I say "a cubit is the size of the maximum extension of proximal extremity of the radius to the medial distal phalange" then you might know what I'm talking about, you might not. If I say "a cubit is the size of your forearm with fully-extended middle finger" most people will have no problem.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-22 08:20 +0100 |
| Message-ID | <nmshgl$d6l$1@dont-email.me> |
| In reply to | #90752 |
On 22/07/16 08:18, Malcolm McLean wrote: > On Friday, July 22, 2016 at 7:57:24 AM UTC+1, Richard Heathfield wrote: >> On 22/07/16 04:02, Malcolm McLean wrote: >> >>> But what does sizeof *xarray mean? It's cryptic. >> >> No, it's trivial. It means the number of bytes required to store *xarray. >> > Yes it is trivial. > Also cryptic. No, it's just trivial. > It's not that the operation is fundamentally sophisticated > of difficult. All we mean is "4 bytes". No, we mean sizeof *array bytes. If we meant 4, we'd have said 4. > But you wouldn't know unless you had the key. So it's an encrypted way > of saying "4 bytes" If you don't know C, there are far worse bits of it to be confused by. If you do know C, you know full well that it doesn't mean "4 bytes" *at all*! > If I say "a cubit is the size of the maximum extension of proximal > extremity of the radius to the medial distal phalange" then you might > know what I'm talking about, you might not. > If I say "a cubit is the size of your forearm with fully-extended middle > finger" most people will have no problem. The audience of a C programmer is not "most people" but C programmers. Anyone who can't understand sizeof *p is not a C programmer. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-22 00:49 -0700 |
| Message-ID | <52247664-de2e-44ae-b1c3-8fc2b702df48@googlegroups.com> |
| In reply to | #90753 |
On Friday, July 22, 2016 at 8:21:02 AM UTC+1, Richard Heathfield wrote: > > The audience of a C programmer is not "most people" but C programmers. > Anyone who can't understand sizeof *p is not a C programmer. > There are lots of languages, most of which do most things in much the same way. Most programming comes down to nested loops and applying mathematical or string expressions to the members, after all, and there's only a limited number of ways of doing that. The current situation is that a piece of code is very likely to be written in some vile scripting language, and call C to do some processor intensive or algorithmically complicated programming which the scripting language can't handle sensibly. So the C programmer may find himself having to hack into the vile scripting language, and the scripting programmer may find himself having to hack into the C. Now there are certain things that just have to be done differently. C needs raw access to pointers, vile scripting language probably forbids it. But if things can be done the same, do them the same. Don't use travelling pointers and * dereference syntax when you can use [] for example. Equally, just use function notation for sizeof. sizeof(int) means 4 bytes if we know that integers are 32 bits, and we probably don't need to know that on other platforms that might not be true. It can't mean anything else, unless we don't even know that int is the type for an integer, but virtually any programmer from any background can guess that. sizeof *array could mean dereference the pointer array and take its absolute value. multiply the variable array by the variable sizeof. take the amount of memory occupied by a pointer to an array. take the number of elements in the first row of the array. take the amount of memory occupied by the first element of the array. Now why would you naturally pick one meaning rather than another?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-22 09:31 +0100 |
| Message-ID | <nmslk7$pm9$1@dont-email.me> |
| In reply to | #90754 |
On 22/07/16 08:49, Malcolm McLean wrote: <snip> > > sizeof *array > > could mean > dereference the pointer array and take its absolute value. No, it couldn't. > multiply the variable array by the variable sizeof. No, it couldn't. > take the amount of memory occupied by a pointer to an array. No, it couldn't. > take the number of elements in the first row of the array. No, it couldn't. > take the amount of memory occupied by the first element of the array. No, it couldn't. > Now why would you naturally pick one meaning rather than another? I'd pick the meaning defined by the language spec. The sizeof operator yields the size in bytes of its operand. Full stop. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-22 10:22 +0100 |
| Message-ID | <nmsolf$3dh$1@dont-email.me> |
| In reply to | #90758 |
On 22/07/2016 09:31, Richard Heathfield wrote: > I'd pick the meaning defined by the language spec. The sizeof operator > yields the size in bytes of its operand. Full stop. 'bytes'? Plus there is a big exception to how it works. Normally it takes the type of the nominal expression and returns size in char units that such a type would occupy. But what's the type of the expression here: sizeof "bart"? If it's char*, then it gives the wrong answer (5 instead of perhaps 4 or 8). If it's char[5], then this is different from most other contexts as the array is treated as a value type. And if it is char[5], then it's puzzling as to why: sizeof *"bart" is allowed. There are a lot of inconsistencies associated with this trivial little feature. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-22 12:21 +0100 |
| Message-ID | <nmsvk3$pbk$1@dont-email.me> |
| In reply to | #90762 |
On 22/07/16 10:22, BartC wrote:
> On 22/07/2016 09:31, Richard Heathfield wrote:
>
>> I'd pick the meaning defined by the language spec. The sizeof operator
>> yields the size in bytes of its operand. Full stop.
>
> 'bytes'?
Yes. In C, a byte is a unit of storage exactly wide enough to store one
character.
> Plus there is a big exception to how it works.
There are two. One is that it can take a parenthesised type name, and
the other is that it may evaluate a VLA operand. Neither of these are
troublesome to me, because I don't use VLAs, I rarely use parenthesised
type names, and when I do, I know why I'm doing it.
> Normally it takes the
> type of the nominal expression and returns size in char units that such
> a type would occupy.
That's 'bytes', but yes.
>
> But what's the type of the expression here: sizeof "bart"?
The type of the expression is size_t, because that's the type that
sizeof yields as its result. But if you mean the type of the expression,
it's a non-modifiable array of 5 char.
>
> If it's char*, then it gives the wrong answer (5 instead of perhaps 4 or
> 8). If it's char[5], then this is different from most other contexts as
> the array is treated as a value type.
With the exception noted above, sizeof does not evaluate its operand.
>
> And if it is char[5], then it's puzzling as to why: sizeof *"bart" is
> allowed.
No, it's not puzzling. *"bart" is equivalent to *("bart" + 0), which is
equivalent to "bart"[0], which is equivalent to 'b'. It's not difficult.
> There are a lot of inconsistencies associated with this trivial little
> feature.
You say so. I don't agree.
--
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 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web