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 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-07-26 18:09 +0000 |
| Message-ID | <slrn3vfsnpf9q1.frf.ike@iceland.freeshell.org> |
| In reply to | #91095 |
On 2016-07-26, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> Why is the same attitude not expressed when compilers take something like:
>
> unsigned mul(unsigned short x, unsighed short y) { return x*y; }
The typo made me smile.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-26 14:43 -0400 |
| Message-ID | <nn8b0p$dil$1@jstuckle.eternal-september.org> |
| In reply to | #91095 |
On 7/26/2016 12:41 PM, supercat@casperkitty.com wrote:
> On Tuesday, July 26, 2016 at 11:29:20 AM UTC-5, Jerry Stuckle wrote:
>> Yes, the standards committee assumes a modicum of intelligence by those
>> who read the standards. I see you can't even reach that level.
>
> Why is the same attitude not expressed when compilers take something like:
>
> unsigned mul(unsigned short x, unsighed short y) { return x*y; }
>
> and produce code that doesn't work when the product is in the range
> INT_MAX+1u and UINT_MAX? The C89 rationale notes that on the majority
> of current implementations computations yielding values in that range
> would work identically with signed and unsigned types except when the
> results were used in certain specific ways, and I don't think they would
> have said that if they didn't expect non-obtuse implementations on two's-
> complement silent-wraparound hardware to continue behaving likewise?
>
Maybe because C also depends on a modicum of intelligence by
programmers. It doesn't put in all kinds of checks for programming
errors which slow down the system.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-26 20:25 +0100 |
| Message-ID | <87fuqwp5fc.fsf@bsb.me.uk> |
| In reply to | #91094 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 7/25/2016 8:08 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 7/25/2016 12:07 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 7/24/2016 7:24 PM, Ben Bacarisse wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> <snip> >>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>> >>>>>> Yes it is because there is no limit placed on the number of padding bits >>>>>> an integer type can have -- int might have none and short might have >>>>>> dozens. There's no reason I can see for an implementation to do this, >>>>>> but it's not prohibited by the language. >>>>> >>>>> There is no allowance for padding BYTES. Only BITS. >>>> >>>> If there are enough padding bits, sizeof (short) can be > sizeof (int). >>>> The padding bits may or may not be consecutive, but they all contribute >>>> to the overall size, just as the sign bit and value bits do. This >>>> layout, for a four (8-bit) byte short, appears to have nothing that >>>> could be called a padding byte, but sizeof (short) must report 4: >>>> >>>> SPVPVPVP VPVPVPVP VPVPVPVP VPVPVPVP >>>> >>>> If you don't accept this possibility, please indicate the padding bytes. >>> >>> So you, too, are going into the realm of the totally absurd. >> >> Ah. Were you only saying that having sizeof (short) > sizeof (int) is >> totally absurd? If so, we agree. I was only disagreeing with the >> incorrect statement that it is not permitted. > > Not at all. I'm saying your example is totally absurd. Yes it is, but you seem to be reluctant to say if it is permitted or not (which, remember, is the only difference of fact as far as I can see). Presumably you don't think it is permitted, but since you don't say why I can't say much more than it is. The sections the permit is are clear and have been cited several times now so there's not much point in going over that again. If you think it is not permitted *because* it is absurd, that introduces an unfortunate degree of subjectivity to the standard. Someone else might think that having sizeof (void *) > sizeof (int *) is absurd, or any of a large number of other permitted peculiarities, and then the discussion about what a C implementation may do will become far too subjective for my taste (not to say very likely not at all what the committee intended). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-26 15:33 -0400 |
| Message-ID | <nn8dt4$o57$1@jstuckle.eternal-september.org> |
| In reply to | #91103 |
On 7/26/2016 3:25 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 7/25/2016 8:08 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 7/25/2016 12:07 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 7/24/2016 7:24 PM, Ben Bacarisse wrote: >>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> <snip> >>>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>>> >>>>>>> Yes it is because there is no limit placed on the number of padding bits >>>>>>> an integer type can have -- int might have none and short might have >>>>>>> dozens. There's no reason I can see for an implementation to do this, >>>>>>> but it's not prohibited by the language. >>>>>> >>>>>> There is no allowance for padding BYTES. Only BITS. >>>>> >>>>> If there are enough padding bits, sizeof (short) can be > sizeof (int). >>>>> The padding bits may or may not be consecutive, but they all contribute >>>>> to the overall size, just as the sign bit and value bits do. This >>>>> layout, for a four (8-bit) byte short, appears to have nothing that >>>>> could be called a padding byte, but sizeof (short) must report 4: >>>>> >>>>> SPVPVPVP VPVPVPVP VPVPVPVP VPVPVPVP >>>>> >>>>> If you don't accept this possibility, please indicate the padding bytes. >>>> >>>> So you, too, are going into the realm of the totally absurd. >>> >>> Ah. Were you only saying that having sizeof (short) > sizeof (int) is >>> totally absurd? If so, we agree. I was only disagreeing with the >>> incorrect statement that it is not permitted. >> >> Not at all. I'm saying your example is totally absurd. > > Yes it is, but you seem to be reluctant to say if it is permitted or not > (which, remember, is the only difference of fact as far as I can see). > Presumably you don't think it is permitted, but since you don't say why > I can't say much more than it is. The sections the permit is are clear > and have been cited several times now so there's not much point in going > over that again. > > If you think it is not permitted *because* it is absurd, that introduces > an unfortunate degree of subjectivity to the standard. Someone else > might think that having sizeof (void *) > sizeof (int *) is absurd, or > any of a large number of other permitted peculiarities, and then the > discussion about what a C implementation may do will become far too > subjective for my taste (not to say very likely not at all what the > committee intended). > > <snip> > At least you are admitting your example is absurd. And no, I will not say anything so absurd is permitted. It makes no sense at all - except to you, anyway. But then people with intelligence don't need to make up stupid examples like that to try to prove a point. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-26 21:05 +0100 |
| Message-ID | <nn8fph$vl4$1@dont-email.me> |
| In reply to | #91104 |
On 26/07/16 20:33, Jerry Stuckle wrote: <snip> > At least you are admitting your example is absurd. That was never in doubt. Nobody here has claimed that making sizeof(short) > sizeof(int) is anything other than ridiculous. That isn't the point. The point is that it is not forbidden. > And no, I will not say anything so absurd is permitted. And who gets to decide what is absurd and what is not? You? > It makes no sense at all - except to you, anyway. It makes sense for the Standard not to nail implementations down too tightly, partly because to do so would render some implementations non-conforming for no good reason, and partly because too tight a spec can stifle innovation in perhaps unexpected areas. One consequence of this relative laxity is that it is possible to hypothesise implementations that would be conforming despite making absurd design decisions (such as sizeof(short) > sizeof(int)). Nobody thinks for a moment that a real implementation would do this, but to be able to reason about such hypothetical implementations can be useful nonetheless. Of course, such discussions would seem pointless to someone who thinks that "absurd" and "forbidden" are synonymous. > But then people with intelligence don't need to make up stupid examples > like that to try to prove a point. You made a false claim. The falsity of the claim has been demonstrated beyond any reasonable doubt. And yet you continue to make that claim. That doesn't put you in the "bright bunny" camp. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-26 16:37 -0400 |
| Message-ID | <nn8hlh$62i$1@jstuckle.eternal-september.org> |
| In reply to | #91108 |
On 7/26/2016 4:05 PM, Richard Heathfield wrote: > On 26/07/16 20:33, Jerry Stuckle wrote: > <snip> >> At least you are admitting your example is absurd. > > That was never in doubt. Nobody here has claimed that making > sizeof(short) > sizeof(int) is anything other than ridiculous. That > isn't the point. The point is that it is not forbidden. > >> And no, I will not say anything so absurd is permitted. > > And who gets to decide what is absurd and what is not? You? > It is absurd to anyone with a modicum of intelligence. I guess that leaves you out, though. >> It makes no sense at all - except to you, anyway. > > It makes sense for the Standard not to nail implementations down too > tightly, partly because to do so would render some implementations > non-conforming for no good reason, and partly because too tight a spec > can stifle innovation in perhaps unexpected areas. One consequence of > this relative laxity is that it is possible to hypothesise > implementations that would be conforming despite making absurd design > decisions (such as sizeof(short) > sizeof(int)). Nobody thinks for a > moment that a real implementation would do this, but to be able to > reason about such hypothetical implementations can be useful > nonetheless. Of course, such discussions would seem pointless to someone > who thinks that "absurd" and "forbidden" are synonymous. > >> But then people with intelligence don't need to make up stupid examples >> like that to try to prove a point. > > You made a false claim. The falsity of the claim has been demonstrated > beyond any reasonable doubt. And yet you continue to make that claim. > That doesn't put you in the "bright bunny" camp. > Not at all. I made a claim that you tried to disprove with a completely absurd example. But you can't figure that out. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-26 13:23 -0700 |
| Message-ID | <2c152373-28b9-49dc-b221-d24dcb9ee08c@googlegroups.com> |
| In reply to | #91104 |
On Tuesday, July 26, 2016 at 3:33:01 PM UTC-4, Jerry Stuckle wrote: > On 7/26/2016 3:25 PM, Ben Bacarisse wrote: > > Jerry Stuckle <jstucklex@attglobal.net> writes: > > > >> On 7/25/2016 8:08 PM, Ben Bacarisse wrote: > >>> Jerry Stuckle <jstucklex@attglobal.net> writes: > >>> > >>>> On 7/25/2016 12:07 PM, Ben Bacarisse wrote: ... > >>>>> If there are enough padding bits, sizeof (short) can be > sizeof (int). > >>>>> The padding bits may or may not be consecutive, but they all contribute > >>>>> to the overall size, just as the sign bit and value bits do. This > >>>>> layout, for a four (8-bit) byte short, appears to have nothing that > >>>>> could be called a padding byte, but sizeof (short) must report 4: > >>>>> > >>>>> SPVPVPVP VPVPVPVP VPVPVPVP VPVPVPVP > >>>>> > >>>>> If you don't accept this possibility, please indicate the padding bytes. > >>>> > >>>> So you, too, are going into the realm of the totally absurd. > >>> > >>> Ah. Were you only saying that having sizeof (short) > sizeof (int) is > >>> totally absurd? If so, we agree. I was only disagreeing with the > >>> incorrect statement that it is not permitted. > >> > >> Not at all. I'm saying your example is totally absurd. > > > > Yes it is, but you seem to be reluctant to say if it is permitted or not > > (which, remember, is the only difference of fact as far as I can see). > > Presumably you don't think it is permitted, but since you don't say why > > I can't say much more than it is. The sections the permit is are clear > > and have been cited several times now so there's not much point in going > > over that again. > > > > If you think it is not permitted *because* it is absurd, that introduces > > an unfortunate degree of subjectivity to the standard. Someone else > > might think that having sizeof (void *) > sizeof (int *) is absurd, or > > any of a large number of other permitted peculiarities, and then the > > discussion about what a C implementation may do will become far too > > subjective for my taste (not to say very likely not at all what the > > committee intended). > > > > <snip> > > > > At least you are admitting your example is absurd. "At least"? No one has ever suggested otherwise. Have you been paying any attention whatsoever to what other people are actually saying? > ... And no, I will not > say anything so absurd is permitted. ... No surprise there. You will also, I predict, refuse to cite the text of relevant requirements that it violates. > ... It makes no sense at all - except > to you, anyway. It makes sense to me, Richard Heathfield, Keith Thompson, and Joe Pfeiffer, among others. You can dismiss us all as idiots - none of us will be surprised if you do - but I object strenuously to your claim that we are stupid enough to agree with you that it doesn't make sense. I can't find statements by the other participants in this thread that clarify whether they think it makes sense, but from past experience I'd expect most of them to agree (except possibly Rosario19, Malcolm McClean, Rick Hodgins and BartC). I don't see anyone joining you in claiming it's senseless. The truth isn't something that can be decided by a vote - it's entirely possible to be the only person in the world who correctly understands something. However, that isn't the smart way to bet. When a large number of people disagree with you about something, and almost no one agrees with you, you should give some consideration to the possibility that you've misunderstood something. I'm quite confident that you are too stubborn to ever consider that possibility. It's a possibility that I consider on a regular basis, which sometimes leads to me correcting my views. > But then people with intelligence don't need to make up stupid examples > like that to try to prove a point. People with intelligence routinely make up extreme examples in order to check whether a rule makes sense, and for the purpose of clarifying precisely what a rule means. They don't need to - it's just that they are intelligent enough (unlike you) to realize that extreme cases often help make the relevant issues clearer.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-26 16:39 -0400 |
| Message-ID | <nn8hpb$62i$2@jstuckle.eternal-september.org> |
| In reply to | #91109 |
On 7/26/2016 4:23 PM, jameskuyper@verizon.net wrote: > On Tuesday, July 26, 2016 at 3:33:01 PM UTC-4, Jerry Stuckle wrote: >> On 7/26/2016 3:25 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 7/25/2016 8:08 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 7/25/2016 12:07 PM, Ben Bacarisse wrote: > ... >>>>>>> If there are enough padding bits, sizeof (short) can be > sizeof (int). >>>>>>> The padding bits may or may not be consecutive, but they all contribute >>>>>>> to the overall size, just as the sign bit and value bits do. This >>>>>>> layout, for a four (8-bit) byte short, appears to have nothing that >>>>>>> could be called a padding byte, but sizeof (short) must report 4: >>>>>>> >>>>>>> SPVPVPVP VPVPVPVP VPVPVPVP VPVPVPVP >>>>>>> >>>>>>> If you don't accept this possibility, please indicate the padding bytes. >>>>>> >>>>>> So you, too, are going into the realm of the totally absurd. >>>>> >>>>> Ah. Were you only saying that having sizeof (short) > sizeof (int) is >>>>> totally absurd? If so, we agree. I was only disagreeing with the >>>>> incorrect statement that it is not permitted. >>>> >>>> Not at all. I'm saying your example is totally absurd. >>> >>> Yes it is, but you seem to be reluctant to say if it is permitted or not >>> (which, remember, is the only difference of fact as far as I can see). >>> Presumably you don't think it is permitted, but since you don't say why >>> I can't say much more than it is. The sections the permit is are clear >>> and have been cited several times now so there's not much point in going >>> over that again. >>> >>> If you think it is not permitted *because* it is absurd, that introduces >>> an unfortunate degree of subjectivity to the standard. Someone else >>> might think that having sizeof (void *) > sizeof (int *) is absurd, or >>> any of a large number of other permitted peculiarities, and then the >>> discussion about what a C implementation may do will become far too >>> subjective for my taste (not to say very likely not at all what the >>> committee intended). >>> >>> <snip> >>> >> >> At least you are admitting your example is absurd. > > "At least"? No one has ever suggested otherwise. Have you been paying any attention whatsoever to what other people are actually saying? > Sure. Unlike you, I can read. >> ... And no, I will not >> say anything so absurd is permitted. ... > > No surprise there. You will also, I predict, refuse to cite the text of relevant requirements that it violates. > Only a complete moron would consider that example to be anything but absurd. And the standards committee doesn't waste its time on absurd examples like this. >> ... It makes no sense at all - except >> to you, anyway. > > It makes sense to me, Richard Heathfield, Keith Thompson, and Joe Pfeiffer, among others. You can dismiss us all as idiots - none of us will be surprised if you do - but I object strenuously to your claim that we are stupid enough to agree with you that it doesn't make sense. > Sure, it WOULD make sense to you. > I can't find statements by the other participants in this thread that clarify whether they think it makes sense, but from past experience I'd expect most of them to agree (except possibly Rosario19, Malcolm McClean, Rick Hodgins and BartC). I don't see anyone joining you in claiming it's senseless. > > The truth isn't something that can be decided by a vote - it's entirely possible to be the only person in the world who correctly understands something. However, that isn't the smart way to bet. When a large number of people disagree with you about something, and almost no one agrees with you, you should give some consideration to the possibility that you've misunderstood something. I'm quite confident that you are too stubborn to ever consider that possibility. It's a possibility that I consider on a regular basis, which sometimes leads to me correcting my views. > >> But then people with intelligence don't need to make up stupid examples >> like that to try to prove a point. > > People with intelligence routinely make up extreme examples in order to check whether a rule makes sense, and for the purpose of clarifying precisely what a rule means. They don't need to - it's just that they are intelligent enough (unlike you) to realize that extreme cases often help make the relevant issues clearer. > Yes, they make up extreme examples. But people of intelligence make up REASONABLE extreme examples. Not absurd ones like Richard's. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-26 14:07 -0700 |
| Message-ID | <e43569c2-6584-473f-92f8-27c4a469065c@googlegroups.com> |
| In reply to | #91111 |
On Tuesday, July 26, 2016 at 3:39:14 PM UTC-5, Jerry Stuckle wrote: > Only a complete moron would consider that example to be anything but > absurd. And the standards committee doesn't waste its time on absurd > examples like this. It's too bad they didn't spend time on notions that would have been thought of as absurd in 1989, since some such notions have since become fashionable.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-26 14:51 -0700 |
| Message-ID | <1abfc0e6-895c-437e-829b-f19ecb4737e5@googlegroups.com> |
| In reply to | #91111 |
On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: > On 7/26/2016 4:23 PM, jameskuyper@verizon.net wrote: > > On Tuesday, July 26, 2016 at 3:33:01 PM UTC-4, Jerry Stuckle wrote: ... > >> At least you are admitting your example is absurd. > > > > "At least"? No one has ever suggested otherwise. Have you been paying any attention whatsoever to what other people are actually saying? > > > > Sure. Unlike you, I can read. Then how did you arrive at the misconception that there was anyone here disagreeing with you about the absurdity of "sizeof(short) > sizeof(int)"? A failure to properly read what we've written seems the only way to justify that misconception. The only thing anyone has ever been disagreeing with you about is whether it's permitted, not about whether it's absurd. ... > ... the standards committee doesn't waste its time on absurd > examples like this. Actually, it often does. Many defect reports include examples that are deliberately extreme in ways that I'm sure you would consider absurd. Some of those "absurd" cases correspond to real world systems. > >> ... It makes no sense at all - except > >> to you, anyway. > > > > It makes sense to me, Richard Heathfield, Keith Thompson, and Joe Pfeiffer, > > among others. You can dismiss us all as idiots - none of us will be > > surprised if you do - but I object strenuously to your claim that we are > > stupid enough to agree with you that it doesn't make sense. > > > > Sure, it WOULD make sense to you. Of course - the people I've listed are among the most knowledgeable people you're ever likely to meet about this subject, so of course we're in agreement. ... > > People with intelligence routinely make up extreme examples in order to > > check whether a rule makes sense, and for the purpose of clarifying > > precisely what a rule means. They don't need to - it's just that they are > > intelligent enough (unlike you) to realize that extreme cases often help > > make the relevant issues clearer. > > > > Yes, they make up extreme examples. But people of intelligence make up > REASONABLE extreme examples. Not absurd ones like Richard's. No, unreasonably extreme examples are often more useful than reasonably extreme examples - it's often easier to see what's going on. Einstein loved such examples - he called them Gedankenexperiments. His examples routinely involved absurd situations that could obviously never involve things moving fast enough to show relativistic effects, or could obviously never allow measurements precise enough to detect those effects - usually both. The effects he described using his Gedankenexperiments were often confirmed decades later by real experiments, using technology that would have been considered absurd at the time he described his Gedankenexperiments.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2016-07-26 15:17 -0700 |
| Message-ID | <b5eba5c7-fd99-4332-b011-5c11d73e11f8@googlegroups.com> |
| In reply to | #91115 |
On Wednesday, 27 July 2016 00:52:03 UTC+3, james...@verizon.net wrote: > > No, unreasonably extreme examples are often more useful than > reasonably extreme examples - it's often easier to see what's going > on. Einstein loved such examples - he called them Gedankenexperiments. I thought it was Hans Christian Ørsted or may be Ernst Mach lot earlier who coined that term (or was it Gedankenversuch)? Most famous of such thought experiments is likely from Erwin Schrödinger (the Schrödinger's cat).
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-26 23:26 -0400 |
| Message-ID | <nn99km$7cq$1@jstuckle.eternal-september.org> |
| In reply to | #91115 |
On 7/26/2016 5:51 PM, jameskuyper@verizon.net wrote: > On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: >> On 7/26/2016 4:23 PM, jameskuyper@verizon.net wrote: >>> On Tuesday, July 26, 2016 at 3:33:01 PM UTC-4, Jerry Stuckle wrote: > ... >>>> At least you are admitting your example is absurd. >>> >>> "At least"? No one has ever suggested otherwise. Have you been paying any attention whatsoever to what other people are actually saying? >>> >> >> Sure. Unlike you, I can read. > > Then how did you arrive at the misconception that there was anyone here > disagreeing with you about the absurdity of "sizeof(short) > sizeof(int)"? A > failure to properly read what we've written seems the only way to justify that > misconception. The only thing anyone has ever been disagreeing with you about > is whether it's permitted, not about whether it's absurd. > Because sizeof(short) cannot be larger than sizeof(int). They can be the same size, or int can be larger. Show me ONE compiler which has sizeof(short) > sizeof(int). > ... >> ... the standards committee doesn't waste its time on absurd >> examples like this. > > Actually, it often does. Many defect reports include examples that are deliberately extreme in ways that I'm sure you would consider absurd. Some of those "absurd" cases correspond to real world systems. > Yes, they are extreme. But they are not absurd. There is a difference - extreme does not necessarily mean absurd. >>>> ... It makes no sense at all - except >>>> to you, anyway. >>> >>> It makes sense to me, Richard Heathfield, Keith Thompson, and Joe Pfeiffer, >>> among others. You can dismiss us all as idiots - none of us will be >>> surprised if you do - but I object strenuously to your claim that we are >>> stupid enough to agree with you that it doesn't make sense. >>> >> >> Sure, it WOULD make sense to you. > > Of course - the people I've listed are among the most knowledgeable people you're ever likely to meet about this subject, so of course we're in agreement. > The most likely to meet in this newsgroup are definitely NOT the most knowledgeable people I have ever met - or will meet again in the future. The real experts don't try to read things into the standards like you guys do. > ... >>> People with intelligence routinely make up extreme examples in order to >>> check whether a rule makes sense, and for the purpose of clarifying >>> precisely what a rule means. They don't need to - it's just that they are >>> intelligent enough (unlike you) to realize that extreme cases often help >>> make the relevant issues clearer. >>> >> >> Yes, they make up extreme examples. But people of intelligence make up >> REASONABLE extreme examples. Not absurd ones like Richard's. > > No, unreasonably extreme examples are often more useful than reasonably extreme examples - it's often easier to see what's going on. Einstein loved such examples - he called them Gedankenexperiments. His examples routinely involved absurd situations that could obviously never involve things moving fast enough to show relativistic effects, or could obviously never allow measurements precise enough to detect those effects - usually both. > The effects he described using his Gedankenexperiments were often confirmed decades later by real experiments, using technology that would have been considered absurd at the time he described his Gedankenexperiments. > Unreasonably extreme examples are worthless in developing standards. People would have to waste way too much time digging though the examples, and standard committee members are too busy to handle such asinine requests. They don't even get serious consideration. And Einstein is an entirely different subject. His thought experiments were his way of trying to understand theoretical physics, not create a language standard. No relationship at all. But you probably can't understand that, either. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-26 20:46 -0700 |
| Message-ID | <327e375e-3c75-41ee-befd-b06ecbfc9d92@googlegroups.com> |
| In reply to | #91119 |
On Wednesday, July 27, 2016 at 4:26:34 AM UTC+1, Jerry Stuckle wrote: > > Unreasonably extreme examples are worthless in developing standards. > People would have to waste way too much time digging though the > examples, and standard committee members are too busy to handle such > asinine requests. They don't even get serious consideration. > There are often implicit, unstated limits. You can't have more than SIZE_MAX * CHAR_BIT - 16 padding bits in a short, for example. But a clause saying "the number of padding bits is arbitrary" is reasonable, no-one would expect that sort of maximum to be calculated and stated. > > And Einstein is an entirely different subject. His thought experiments > were his way of trying to understand theoretical physics, not create a > language standard. No relationship at all. But you probably can't > understand that, either. > To compare oneself to Einstein in this particular thread is pushing it, I agree.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-27 07:52 +0100 |
| Message-ID | <nn9lmu$36d$1@dont-email.me> |
| In reply to | #91119 |
On 27/07/16 04:26, Jerry Stuckle wrote: > On 7/26/2016 5:51 PM, jameskuyper@verizon.net wrote: >> On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: >>> On 7/26/2016 4:23 PM, jameskuyper@verizon.net wrote: >>>> On Tuesday, July 26, 2016 at 3:33:01 PM UTC-4, Jerry Stuckle wrote: >> ... >>>>> At least you are admitting your example is absurd. >>>> >>>> "At least"? No one has ever suggested otherwise. Have you been paying any attention whatsoever to what other people are actually saying? >>>> >>> >>> Sure. Unlike you, I can read. >> >> Then how did you arrive at the misconception that there was anyone here >> disagreeing with you about the absurdity of "sizeof(short) > sizeof(int)"? A >> failure to properly read what we've written seems the only way to justify that >> misconception. The only thing anyone has ever been disagreeing with you about >> is whether it's permitted, not about whether it's absurd. >> > > Because sizeof(short) cannot be larger than sizeof(int). If your latest claim (to be able to read) is correct, then the following facts are true: (A) you think it is absurd that sizeof(short) could be greater than sizeof(int) AND (B) everybody agrees with you about the absurdity AND (C) you mistakenly think that some people disagree about the absurdity AND (D) your belief that sizeof(short) /cannot/ exceed sizeof(int) somehow acts as a logical explanation of (C), such that you advance it as a reason when questioned about how you arrived at (C). (A), (B), and (C) are all correct, but (D) is not. Conclusion: you can't read, after all. > They can be > the same size, or int can be larger. They can have the same /range/, or int's /range/ can be larger. But short can have more bits. > Show me ONE compiler which has sizeof(short) > sizeof(int). Since the very idea is absurd, there is no reason to expect any C compiler (or C implementation of any kind) that would incorporate this design decision. Nobody has claimed that any such implementation exists. The claim, which has been more than adequately justified, is that such an implementation is /permitted/. It's an important distinction, but one that you seem unable to grasp. >>> ... the standards committee doesn't waste its time on absurd >>> examples like this. >> >> Actually, it often does. Many defect reports include examples that are deliberately extreme in ways that I'm sure you would consider absurd. Some of those "absurd" cases correspond to real world systems. >> > > Yes, they are extreme. But they are not absurd. There is a difference > - extreme does not necessarily mean absurd. And you are, no doubt, the sole arbiter of the distinction between "extreme" and "absurd". But in fact absurd examples can be useful, and your arbitrary claim to the contrary has no merit. The current example is a case in point. >>>>> ... It makes no sense at all - except >>>>> to you, anyway. >>>> >>>> It makes sense to me, Richard Heathfield, Keith Thompson, and Joe Pfeiffer, >>>> among others. You can dismiss us all as idiots - none of us will be >>>> surprised if you do - but I object strenuously to your claim that we are >>>> stupid enough to agree with you that it doesn't make sense. >>>> >>> >>> Sure, it WOULD make sense to you. >> >> Of course - the people I've listed are among the most knowledgeable people you're ever likely to meet about this subject, so of course we're in agreement. >> > > The most likely to meet in this newsgroup are definitely NOT the most > knowledgeable people I have ever met - or will meet again in the future. It is not clear whether you have the ability to recognise what constitutes a knowledgeable person. I don't make the claim for myself, of course, but I would certainly recognise Keith and James as being experts on the C language. Joe doesn't post here quite so often, but he too is definitely on my list of smart guys. > The real experts don't try to read things into the standards like you > guys do. Yes, they do, and James and Keith are cases in point. They /are/ real experts. >>>> People with intelligence routinely make up extreme examples in order to >>>> check whether a rule makes sense, and for the purpose of clarifying >>>> precisely what a rule means. They don't need to - it's just that they are >>>> intelligent enough (unlike you) to realize that extreme cases often help >>>> make the relevant issues clearer. >>>> >>> >>> Yes, they make up extreme examples. But people of intelligence make up >>> REASONABLE extreme examples. Not absurd ones like Richard's. >> >> No, unreasonably extreme examples are often more useful than reasonably extreme examples - it's often easier to see what's going on. Einstein loved such examples - he called them Gedankenexperiments. His examples routinely involved absurd situations that could obviously never involve things moving fast enough to show relativistic effects, or could obviously never allow measurements precise enough to detect those effects - usually both. >> The effects he described using his Gedankenexperiments were often confirmed decades later by real experiments, using technology that would have been considered absurd at the time he described his Gedankenexperiments. >> > > Unreasonably extreme examples are worthless in developing standards. I disagree. Surely deciding the boundary between "unreasonably extreme" and "acceptably extreme" is of great value in developing an international standard. When I learned, as a child, that chocolate could pass a health inspection if it contained /fewer than/ X fly hairs, I was appalled - why permit /any/? It's a reasonable question, and it's an extreme question too. What's more, it seems absurd to me that it would be /legal/ to put fly hairs into chocolate. But of course in real life it's not about putting them in - it's about the difficulty of keeping them out. The question is not "what value of X would we /like/?" because of course the answer is 0. No, the question is "what value of X is /acceptable/, given the realities of manufacturing?" And the real absurdity was mine, in that I was expecting perfection from a human manufacturing process. In that example, X is acceptably extreme, 0 is unreasonably extreme, but 0 nevertheless remains a worthy goal to which chocolate implementations should aspire, and it is not even remotely implausible that comp.std.chocolate (!) could have meaningful discussions about factory processes where X is 0, even though everyone involved knows that the very idea is absurd. > People would have to waste way too much time digging though the > examples, and standard committee members are too busy to handle such > asinine requests. They don't even get serious consideration. James asked you to look at some DRs. Had you done so, you'd realise that the Committee members do handle and consider some cases that do indeed sound absurd. For example, DR 451 asks "Can an uninitialized variable with automatic storage duration (of a type that does not have trap values, whose address has been taken so 6.3.2.1p2 does not apply, and which is not volatile) change its value without direct action of the program?" It may or may not sound like a silly question to you. I have no way of knowing. But it sounds pretty silly to me. Of course the answer, in the /real/ world, is bound to be "no", right? Not because the Standard forbids it, necessarily, but because any mechanism that might legitimately have changed it was carefully excluded in the question. Surely the Committee wouldn't waste their time on such a question. But they did answer it, and the answer they came up with was "yes". For that value to change is perhaps absurd, but most certainly not forbidden. Conclusion: you are again mistaken. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-27 08:47 -0400 |
| Message-ID | <nnaahh$7kg$1@jstuckle.eternal-september.org> |
| In reply to | #91124 |
On 7/27/2016 2:52 AM, Richard Heathfield wrote: > On 27/07/16 04:26, Jerry Stuckle wrote: >> On 7/26/2016 5:51 PM, jameskuyper@verizon.net wrote: >>> On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: >>>> On 7/26/2016 4:23 PM, jameskuyper@verizon.net wrote: >>>>> On Tuesday, July 26, 2016 at 3:33:01 PM UTC-4, Jerry Stuckle wrote: >>> ... >>>>>> At least you are admitting your example is absurd. >>>>> >>>>> "At least"? No one has ever suggested otherwise. Have you been >>>>> paying any attention whatsoever to what other people are actually >>>>> saying? >>>>> >>>> >>>> Sure. Unlike you, I can read. >>> >>> Then how did you arrive at the misconception that there was anyone here >>> disagreeing with you about the absurdity of "sizeof(short) > >>> sizeof(int)"? A >>> failure to properly read what we've written seems the only way to >>> justify that >>> misconception. The only thing anyone has ever been disagreeing with >>> you about >>> is whether it's permitted, not about whether it's absurd. >>> >> >> Because sizeof(short) cannot be larger than sizeof(int). > > If your latest claim (to be able to read) is correct, then the following > facts are true: > > (A) you think it is absurd that sizeof(short) could be greater than > sizeof(int) AND That is true. > (B) everybody agrees with you about the absurdity AND That is true. > (C) you mistakenly think that some people disagree about the absurdity AND No mistake. Just idiots think it's possible. Something I find quite in abundance in some people in this newsgroup. > (D) your belief that sizeof(short) /cannot/ exceed sizeof(int) somehow > acts as a logical explanation of (C), such that you advance it as a > reason when questioned about how you arrived at (C). > Nope. The fact sizeof(short) cannot exceed sizeof(int) proves the idiocy of some people in this newsgroup. > (A), (B), and (C) are all correct, but (D) is not. > > Conclusion: you can't read, after all. > Conclusion: you are an idiot. > >> They can be >> the same size, or int can be larger. > > They can have the same /range/, or int's /range/ can be larger. But > short can have more bits. > Show me where that is stated in the standard. >> Show me ONE compiler which has sizeof(short) > sizeof(int). > > Since the very idea is absurd, there is no reason to expect any C > compiler (or C implementation of any kind) that would incorporate this > design decision. Nobody has claimed that any such implementation exists. > The claim, which has been more than adequately justified, is that such > an implementation is /permitted/. It's an important distinction, but one > that you seem unable to grasp. > So now you admit it is absurd. That's a start, anyway. And the standards committee doesn't bother itself with absurd concepts - unlike some people in this newsgroup. >>>> ... the standards committee doesn't waste its time on absurd >>>> examples like this. >>> >>> Actually, it often does. Many defect reports include examples that >>> are deliberately extreme in ways that I'm sure you would consider >>> absurd. Some of those "absurd" cases correspond to real world systems. >>> >> >> Yes, they are extreme. But they are not absurd. There is a difference >> - extreme does not necessarily mean absurd. > > And you are, no doubt, the sole arbiter of the distinction between > "extreme" and "absurd". But in fact absurd examples can be useful, and > your arbitrary claim to the contrary has no merit. The current example > is a case in point. > Nope, the standards committee is. But some things are so patently absurd they don't need any arbitration. They stand on their own. >>>>>> ... It makes no sense at all - except >>>>>> to you, anyway. >>>>> >>>>> It makes sense to me, Richard Heathfield, Keith Thompson, and Joe >>>>> Pfeiffer, >>>>> among others. You can dismiss us all as idiots - none of us will be >>>>> surprised if you do - but I object strenuously to your claim that >>>>> we are >>>>> stupid enough to agree with you that it doesn't make sense. >>>>> >>>> >>>> Sure, it WOULD make sense to you. >>> >>> Of course - the people I've listed are among the most knowledgeable >>> people you're ever likely to meet about this subject, so of course >>> we're in agreement. >>> >> >> The most likely to meet in this newsgroup are definitely NOT the most >> knowledgeable people I have ever met - or will meet again in the future. > > It is not clear whether you have the ability to recognise what > constitutes a knowledgeable person. I don't make the claim for myself, > of course, but I would certainly recognise Keith and James as being > experts on the C language. Joe doesn't post here quite so often, but he > too is definitely on my list of smart guys. > I sure do, and I know a lot of people who are much smarter than anyone in this newsgroup. They don't try to propose absurd concepts, for instance. >> The real experts don't try to read things into the standards like you >> guys do. > > Yes, they do, and James and Keith are cases in point. They /are/ real > experts. > In the land of the blind, the one-eyed man is king. I'm talking about real experts - ones who have been instrumental in the development of the language over the years. >>>>> People with intelligence routinely make up extreme examples in >>>>> order to >>>>> check whether a rule makes sense, and for the purpose of clarifying >>>>> precisely what a rule means. They don't need to - it's just that >>>>> they are >>>>> intelligent enough (unlike you) to realize that extreme cases often >>>>> help >>>>> make the relevant issues clearer. >>>>> >>>> >>>> Yes, they make up extreme examples. But people of intelligence make up >>>> REASONABLE extreme examples. Not absurd ones like Richard's. >>> >>> No, unreasonably extreme examples are often more useful than >>> reasonably extreme examples - it's often easier to see what's going >>> on. Einstein loved such examples - he called them >>> Gedankenexperiments. His examples routinely involved absurd >>> situations that could obviously never involve things moving fast >>> enough to show relativistic effects, or could obviously never allow >>> measurements precise enough to detect those effects - usually both. >>> The effects he described using his Gedankenexperiments were often >>> confirmed decades later by real experiments, using technology that >>> would have been considered absurd at the time he described his >>> Gedankenexperiments. >>> >> >> Unreasonably extreme examples are worthless in developing standards. > > I disagree. Surely deciding the boundary between "unreasonably extreme" > and "acceptably extreme" is of great value in developing an > international standard. When I learned, as a child, that chocolate could > pass a health inspection if it contained /fewer than/ X fly hairs, I was > appalled - why permit /any/? It's a reasonable question, and it's an > extreme question too. What's more, it seems absurd to me that it would > be /legal/ to put fly hairs into chocolate. But of course in real life > it's not about putting them in - it's about the difficulty of keeping > them out. The question is not "what value of X would we /like/?" because > of course the answer is 0. No, the question is "what value of X is > /acceptable/, given the realities of manufacturing?" And the real > absurdity was mine, in that I was expecting perfection from a human > manufacturing process. In that example, X is acceptably extreme, 0 is > unreasonably extreme, but 0 nevertheless remains a worthy goal to which > chocolate implementations should aspire, and it is not even remotely > implausible that comp.std.chocolate (!) could have meaningful > discussions about factory processes where X is 0, even though everyone > involved knows that the very idea is absurd. > You would disagree. But then you've already shown you believe absurd is acceptable. >> People would have to waste way too much time digging though the >> examples, and standard committee members are too busy to handle such >> asinine requests. They don't even get serious consideration. > > James asked you to look at some DRs. Had you done so, you'd realise that > the Committee members do handle and consider some cases that do indeed > sound absurd. For example, DR 451 asks "Can an uninitialized variable > with automatic storage duration (of a type that does not have trap > values, whose address has been taken so 6.3.2.1p2 does not apply, and > which is not volatile) change its value without direct action of the > program?" > > It may or may not sound like a silly question to you. I have no way of > knowing. But it sounds pretty silly to me. Of course the answer, in the > /real/ world, is bound to be "no", right? Not because the Standard > forbids it, necessarily, but because any mechanism that might > legitimately have changed it was carefully excluded in the question. > No, it's not a silly question. There are a number of ways that could realistically happen. And no, "any mechanism that might legitimately have change id" was not "carefully excluded". > Surely the Committee wouldn't waste their time on such a question. But > they did answer it, and the answer they came up with was "yes". For that > value to change is perhaps absurd, but most certainly not forbidden. > > Conclusion: you are again mistaken. > Nope, they came up with "yes" because it is something that could happen. But it is an absurd question to someone who doesn't understand it - and the reasoning behind the question. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-27 17:13 +0200 |
| Message-ID | <nnaj2p$7tb$1@dont-email.me> |
| In reply to | #91130 |
On 27/07/16 14:47, Jerry Stuckle wrote: > On 7/27/2016 2:52 AM, Richard Heathfield wrote: >> On 27/07/16 04:26, Jerry Stuckle wrote: >>> On 7/26/2016 5:51 PM, jameskuyper@verizon.net wrote: >>>> On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: >>>>> On 7/26/2016 4:23 PM, jameskuyper@verizon.net wrote: >>>>>> On Tuesday, July 26, 2016 at 3:33:01 PM UTC-4, Jerry Stuckle wrote: >>>> ... >>>>>>> At least you are admitting your example is absurd. >>>>>> >>>>>> "At least"? No one has ever suggested otherwise. Have you been >>>>>> paying any attention whatsoever to what other people are actually >>>>>> saying? >>>>>> >>>>> >>>>> Sure. Unlike you, I can read. >>>> >>>> Then how did you arrive at the misconception that there was anyone here >>>> disagreeing with you about the absurdity of "sizeof(short) > >>>> sizeof(int)"? A >>>> failure to properly read what we've written seems the only way to >>>> justify that >>>> misconception. The only thing anyone has ever been disagreeing with >>>> you about >>>> is whether it's permitted, not about whether it's absurd. >>>> >>> >>> Because sizeof(short) cannot be larger than sizeof(int). >> >> If your latest claim (to be able to read) is correct, then the following >> facts are true: >> >> (A) you think it is absurd that sizeof(short) could be greater than >> sizeof(int) AND > > That is true. OK. > >> (B) everybody agrees with you about the absurdity AND > > That is true. OK. > >> (C) you mistakenly think that some people disagree about the absurdity AND > > No mistake. Just idiots think it's possible. Something I find quite in > abundance in some people in this newsgroup. Basically, you are unable to distinguish between "absurd" and "impossible". Everyone agrees it would be absurd to have a C implementation with sizeof(short) > sizeof(int). But apart from you, no one who has expressed an opinion thinks it is impossible (meaning, in this context, that it would be against the C standards). It would be /absurd/ for a strawberry farmer to sell kilogram boxes for 10 pence, and hectogram boxes for 10 pounds. But it is certainly /possible/. Do you understand the difference? > >> (D) your belief that sizeof(short) /cannot/ exceed sizeof(int) somehow >> acts as a logical explanation of (C), such that you advance it as a >> reason when questioned about how you arrived at (C). >> > > Nope. The fact sizeof(short) cannot exceed sizeof(int) proves the > idiocy of some people in this newsgroup. Unfortunately for you, sizeof(short) /can/ exceed sizeof(int). Nothing in the C standards suggests otherwise. > >> (A), (B), and (C) are all correct, but (D) is not. >> >> Conclusion: you can't read, after all. >> > > Conclusion: you are an idiot. > >> >>> They can be >>> the same size, or int can be larger. >> >> They can have the same /range/, or int's /range/ can be larger. But >> short can have more bits. >> > > Show me where that is stated in the standard. > >>> Show me ONE compiler which has sizeof(short) > sizeof(int). >> >> Since the very idea is absurd, there is no reason to expect any C >> compiler (or C implementation of any kind) that would incorporate this >> design decision. Nobody has claimed that any such implementation exists. >> The claim, which has been more than adequately justified, is that such >> an implementation is /permitted/. It's an important distinction, but one >> that you seem unable to grasp. >> > > So now you admit it is absurd. That's a start, anyway. And the > standards committee doesn't bother itself with absurd concepts - unlike > some people in this newsgroup. Richard - along with everyone else - has been happy to call the idea absurd right from the start. The standards committee has not bothered discussing such an absurd idea in the C standards - but that also includes not bothering to explicitly disallow the possibility. I don't think anyone believes the C standards committee actively intended to allow sizeof(short) to be greater than sizeof(int) - they simply did not bother to disallow it, and therefore it is possible to have a conforming C implementation with sizeof(short) > sizeof(int). >> >> It is not clear whether you have the ability to recognise what >> constitutes a knowledgeable person. I don't make the claim for myself, >> of course, but I would certainly recognise Keith and James as being >> experts on the C language. Joe doesn't post here quite so often, but he >> too is definitely on my list of smart guys. >> > > I sure do, and I know a lot of people who are much smarter than anyone > in this newsgroup. They don't try to propose absurd concepts, for > instance. > >>> The real experts don't try to read things into the standards like you >>> guys do. >> >> Yes, they do, and James and Keith are cases in point. They /are/ real >> experts. >> > > In the land of the blind, the one-eyed man is king. I'm talking about > real experts - ones who have been instrumental in the development of the > language over the years. It is amazing how you have had such close regular contact with so many C experts, and yet still have such a poor grasp of C, programming, logical, and basic reading comprehension. Didn't you learn /anything/ during all those claimed years as an IBM consultant?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-27 12:03 -0400 |
| Message-ID | <nnalvv$ivq$1@jstuckle.eternal-september.org> |
| In reply to | #91141 |
On 7/27/2016 11:13 AM, David Brown wrote: > On 27/07/16 14:47, Jerry Stuckle wrote: >> On 7/27/2016 2:52 AM, Richard Heathfield wrote: >>> On 27/07/16 04:26, Jerry Stuckle wrote: >>>> On 7/26/2016 5:51 PM, jameskuyper@verizon.net wrote: >>>>> On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: >>>>>> On 7/26/2016 4:23 PM, jameskuyper@verizon.net wrote: >>>>>>> On Tuesday, July 26, 2016 at 3:33:01 PM UTC-4, Jerry Stuckle wrote: >>>>> ... >>>>>>>> At least you are admitting your example is absurd. >>>>>>> >>>>>>> "At least"? No one has ever suggested otherwise. Have you been >>>>>>> paying any attention whatsoever to what other people are actually >>>>>>> saying? >>>>>>> >>>>>> >>>>>> Sure. Unlike you, I can read. >>>>> >>>>> Then how did you arrive at the misconception that there was anyone here >>>>> disagreeing with you about the absurdity of "sizeof(short) > >>>>> sizeof(int)"? A >>>>> failure to properly read what we've written seems the only way to >>>>> justify that >>>>> misconception. The only thing anyone has ever been disagreeing with >>>>> you about >>>>> is whether it's permitted, not about whether it's absurd. >>>>> >>>> >>>> Because sizeof(short) cannot be larger than sizeof(int). >>> >>> If your latest claim (to be able to read) is correct, then the following >>> facts are true: >>> >>> (A) you think it is absurd that sizeof(short) could be greater than >>> sizeof(int) AND >> >> That is true. > > OK. > >> >>> (B) everybody agrees with you about the absurdity AND >> >> That is true. > > OK. > >> >>> (C) you mistakenly think that some people disagree about the absurdity AND >> >> No mistake. Just idiots think it's possible. Something I find quite in >> abundance in some people in this newsgroup. > > Basically, you are unable to distinguish between "absurd" and > "impossible". Everyone agrees it would be absurd to have a C > implementation with sizeof(short) > sizeof(int). But apart from you, no > one who has expressed an opinion thinks it is impossible (meaning, in > this context, that it would be against the C standards). > > It would be /absurd/ for a strawberry farmer to sell kilogram boxes for > 10 pence, and hectogram boxes for 10 pounds. But it is certainly > /possible/. > > Do you understand the difference? > I understand the difference. I also understand the Standards Committee doesn't waste its time with absurd ideas such as this. >> >>> (D) your belief that sizeof(short) /cannot/ exceed sizeof(int) somehow >>> acts as a logical explanation of (C), such that you advance it as a >>> reason when questioned about how you arrived at (C). >>> >> >> Nope. The fact sizeof(short) cannot exceed sizeof(int) proves the >> idiocy of some people in this newsgroup. > > Unfortunately for you, sizeof(short) /can/ exceed sizeof(int). Nothing > in the C standards suggests otherwise. > Yes, because the Standards Committee doesn't waste its time with absurd ideas such as this. >> >>> (A), (B), and (C) are all correct, but (D) is not. >>> >>> Conclusion: you can't read, after all. >>> >> >> Conclusion: you are an idiot. >> >>> >>>> They can be >>>> the same size, or int can be larger. >>> >>> They can have the same /range/, or int's /range/ can be larger. But >>> short can have more bits. >>> >> >> Show me where that is stated in the standard. >> >>>> Show me ONE compiler which has sizeof(short) > sizeof(int). >>> >>> Since the very idea is absurd, there is no reason to expect any C >>> compiler (or C implementation of any kind) that would incorporate this >>> design decision. Nobody has claimed that any such implementation exists. >>> The claim, which has been more than adequately justified, is that such >>> an implementation is /permitted/. It's an important distinction, but one >>> that you seem unable to grasp. >>> >> >> So now you admit it is absurd. That's a start, anyway. And the >> standards committee doesn't bother itself with absurd concepts - unlike >> some people in this newsgroup. > > Richard - along with everyone else - has been happy to call the idea > absurd right from the start. The standards committee has not bothered > discussing such an absurd idea in the C standards - but that also > includes not bothering to explicitly disallow the possibility. I don't > think anyone believes the C standards committee actively intended to > allow sizeof(short) to be greater than sizeof(int) - they simply did not > bother to disallow it, and therefore it is possible to have a conforming > C implementation with sizeof(short) > sizeof(int). > Which is exactly why the Standards Committee hasn't said anything about it. They don't waste their time with absurd ideas such as this. >>> >>> It is not clear whether you have the ability to recognise what >>> constitutes a knowledgeable person. I don't make the claim for myself, >>> of course, but I would certainly recognise Keith and James as being >>> experts on the C language. Joe doesn't post here quite so often, but he >>> too is definitely on my list of smart guys. >>> >> >> I sure do, and I know a lot of people who are much smarter than anyone >> in this newsgroup. They don't try to propose absurd concepts, for >> instance. >> >>>> The real experts don't try to read things into the standards like you >>>> guys do. >>> >>> Yes, they do, and James and Keith are cases in point. They /are/ real >>> experts. >>> >> >> In the land of the blind, the one-eyed man is king. I'm talking about >> real experts - ones who have been instrumental in the development of the >> language over the years. > > It is amazing how you have had such close regular contact with so many C > experts, and yet still have such a poor grasp of C, programming, > logical, and basic reading comprehension. Didn't you learn /anything/ > during all those claimed years as an IBM consultant? > I have a much better grasp of C programming than you even THINK you do. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-27 09:57 -0700 |
| Message-ID | <7cb873e4-ecf7-4dfe-8810-4f221574e130@googlegroups.com> |
| In reply to | #91130 |
On Wednesday, July 27, 2016 at 8:47:54 AM UTC-4, Jerry Stuckle wrote: > On 7/27/2016 2:52 AM, Richard Heathfield wrote: ... > > (A) you think it is absurd that sizeof(short) could be greater than > > sizeof(int) AND > > That is true. > > > (B) everybody agrees with you about the absurdity AND > > That is true. > > > (C) you mistakenly think that some people disagree about the absurdity AND > > No mistake. ... You just said "that is true" to the claim that we all agree with you about the absurdity. Do you believe that there is someone who simultaneously agrees with you about the absurdity, and disagrees with you about the absurdity? > ... Just idiots think it's possible. Now - wait a minute - are you actually claiming that it's physically impossible to construct an implementation that would work that way? I can't imagine why anyone would want to, but I thought your argument was only that it was absurd and therefore not permitted. I never thought that you were claiming that it was actually impossible. At the very least, it should obviously be possible to convert an ordinary implementation of C into one that supports this format for short ints by replacing every read of a short int from memory with a call to a function that removes the padding bits and compresses it down to two bytes, and every write of a short int to memory with a function that decompresses it to four bytes, inserting the specified padding bits. Are you claiming that it would be impossible to write such functions? If so, we could make a contest of it - a fair number of people here could probably come up with tricks that would be more efficient than the straightforward algorithm that I can easily come up with.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-27 16:18 -0400 |
| Message-ID | <nnb4uo$ci1$1@jstuckle.eternal-september.org> |
| In reply to | #91160 |
On 7/27/2016 12:57 PM, jameskuyper@verizon.net wrote: ... Nothing worth responding to. Just a typical troll post. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-27 07:58 -0700 |
| Message-ID | <36a18b33-59dd-4211-a1e0-b442a67c5bbd@googlegroups.com> |
| In reply to | #91119 |
On Tuesday, July 26, 2016 at 11:26:34 PM UTC-4, Jerry Stuckle wrote:
> On 7/26/2016 5:51 PM, jameskuyper@verizon.net wrote:
...
> > Then how did you arrive at the misconception that there was anyone here
> > disagreeing with you about the absurdity of "sizeof(short) > sizeof(int)"?
I see that you didn't bother answering this question. I suppose the true answer would be embarrassing.
...
> Show me ONE compiler which has sizeof(short) > sizeof(int).
Why? I've asserted that such an implementation is permitted. Just because something is permitted doesn't mean anyone is actually doing it. I've also asserted that such an implementation is absurd (which does not contradict the first assertion: the standard does not prohibit absurd implementations in general - many things that are prohibited are absurd, but so are many of the things that are permitted). It follows that it's extremely unlikely that any such implementation exists. Showing you such an implementation would only serve to prove that I was wrong about it being absurd.
Do you think that showing you such an implementation would support my argument that it's permitted? Almost all implementations of C, when invoked in their default mode, do a great many things that the C standard does not permit a conforming implementation to do. That's why those implementations are not conforming in their default mode. Almost all implementations require you select specific options to put them in a mode that is supposed to be fully conforming. But even in that mode, many implementation do at least one thing that they're not permitted to do. Its just like the legal system in this regard: murder is prohibited, but many murders get committed every day. Would you argue that the occurrence of those murders provides evidence that murder is permitted?
What real world implementations actually do is completely irrelevant to the question of whether or not the C standard permits them to do it - they're perfectly capable of doing things without permission. The only pieces of evidence that are relevant to that question are the actual text of the standard, and the responses the committee has made to defect reports.
And I notice that, in all of your discussions, you have never bothered citing a single line of text from either the standard or the defect reports. There's an obvious reason for this: you can't cite any lines that support your point of view, because there are no such lines. But it's pretty clear that there's a deeper reason for your lack of citations: you don't know what the standard says, and that's because deep down you don't really care what the standard says.
If something seems absurd to you, that's all you care about - the actual words of the standard are irrelevant.
> >> ... the standards committee doesn't waste its time on absurd
> >> examples like this.
> >
> > Actually, it often does. Many defect reports include examples that are
> > deliberately extreme in ways that I'm sure you would consider absurd. Some
> > of those "absurd" cases correspond to real world systems.
> >
>
> Yes, they are extreme. But they are not absurd. ...
I'd recommend following the link I provided earlier listing the defect reports that have been processed. If you violate my expectations by actually looking at them, I would expect you to quickly come to conclusion that many of the reports are about absurd issues, leaving you wondering why the committee would be stupid enough to bother responding to them. If you kept reading long enough, I'm certain you would eventually find a committee response that you would also consider absurd. I certainly have, from time to time ("the answer is perfectly clear", as the entire answer to a yes/no question, comes to mind).
> ... There is a difference
> - extreme does not necessarily mean absurd.
No, but absurd is usually extreme, and that's exactly how I used those terms.
[toc] | [prev] | [next] | [standalone]
Page 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web