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 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-27 12:05 -0400 |
| Message-ID | <nnam40$ivq$2@jstuckle.eternal-september.org> |
| In reply to | #91136 |
On 7/27/2016 10:58 AM, jameskuyper@verizon.net wrote:
> 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 hasn't specifically ruled it out because it
doesn't concern itself with such absurd ideas. It has much more
important things to concern itself with.
>>>> ... 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.
>
You have no idea what I would or would not consider absurd, and to even
claim that you do shows how stoopid you really are.
--
==================
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-27 17:18 +0100 |
| Message-ID | <nnams5$mc2$1@dont-email.me> |
| In reply to | #91149 |
On 27/07/16 17:05, Jerry Stuckle wrote: > On 7/27/2016 10:58 AM, jameskuyper@verizon.net wrote: <snip> >> >> 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 hasn't specifically ruled it out QED. > because it > doesn't concern itself with such absurd ideas. It has much more > important things to concern itself with. Of course. That's why it doesn't bother to forbid stuff that it doesn't need to forbid. And that's why it didn't bother to forbid sizeof(short) > sizeof(long). And therefore, in the absence of any general rule that disqualifies that possibility, the possibility is permitted, even though it's absurd. <nonsense snipped> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-27 16:20 -0400 |
| Message-ID | <nnb51f$ci1$2@jstuckle.eternal-september.org> |
| In reply to | #91152 |
On 7/27/2016 12:18 PM, Richard Heathfield wrote: > On 27/07/16 17:05, Jerry Stuckle wrote: >> On 7/27/2016 10:58 AM, jameskuyper@verizon.net wrote: > <snip> >>> >>> 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 hasn't specifically ruled it out > > QED. > Nice example of taking something out of context! >> because it >> doesn't concern itself with such absurd ideas. It has much more >> important things to concern itself with. > > Of course. That's why it doesn't bother to forbid stuff that it doesn't > need to forbid. And that's why it didn't bother to forbid sizeof(short) >> sizeof(long). And therefore, in the absence of any general rule that > disqualifies that possibility, the possibility is permitted, even though > it's absurd. > > <nonsense snipped> > Yes, of course. They don't bother to rule out such an absurd idea. Only an idiot would suggest it's possible. As you so well qualify. -- ================== 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-28 07:14 +0100 |
| Message-ID | <nnc7rb$c9c$1@dont-email.me> |
| In reply to | #91190 |
On 27/07/16 21:20, Jerry Stuckle wrote: > On 7/27/2016 12:18 PM, Richard Heathfield wrote: >> On 27/07/16 17:05, Jerry Stuckle wrote: >>> On 7/27/2016 10:58 AM, jameskuyper@verizon.net wrote: >> <snip> >>>> >>>> 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 hasn't specifically ruled it out >> >> QED. >> > > Nice example of taking something out of context! The whole relevant context was quoted in my reply, both the part that came before and the part that came afterwards. The choice of layout was to highlight the important bit. So it's actually an example of leaving something /in/ its context. > Yes, of course. They don't bother to rule out such an absurd idea. We told you that at the very outset. You now realise that we were correct and that you were incorrect. That's good. It's a shame we couldn't have got to this point without you being such an offensive jerk, but that's life. Presumably now you understand that such offensiveness is counter-productive? (Don't bother. It's rhetorical.) > Only an idiot would suggest it's possible. As you so well qualify. Ah, so you don't realise that offensiveness is counter-productive. And you continue to make mistakes. It is simply not true that "only an idiot would suggest it's possible". It's not forbidden by the Standard and it's not breaking the laws of physics, so why /wouldn't/ it be possible? No, the idiocy lies not in suggesting it's not possible but in insisting that it's forbidden in the face of genuine experts who have demonstrated otherwise in meticulous detail. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-28 08:59 -0700 |
| Message-ID | <lnk2g592jq.fsf@kst-u.example.com> |
| In reply to | #91203 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 27/07/16 21:20, Jerry Stuckle wrote:
> [more of the same]
>
> Ah, so you don't realise that offensiveness is counter-productive.
Depends on your goal. It seems to be quite effective at getting people
to waste time arguing with him.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-28 13:37 -0400 |
| Message-ID | <nndfs0$h9a$1@jstuckle.eternal-september.org> |
| In reply to | #91203 |
On 7/28/2016 2:14 AM, Richard Heathfield wrote: > On 27/07/16 21:20, Jerry Stuckle wrote: >> On 7/27/2016 12:18 PM, Richard Heathfield wrote: >>> On 27/07/16 17:05, Jerry Stuckle wrote: >>>> On 7/27/2016 10:58 AM, jameskuyper@verizon.net wrote: >>> <snip> >>>>> >>>>> 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 hasn't specifically ruled it out >>> >>> QED. >>> >> >> Nice example of taking something out of context! > > The whole relevant context was quoted in my reply, both the part that > came before and the part that came afterwards. The choice of layout was > to highlight the important bit. So it's actually an example of leaving > something /in/ its context. > >> Yes, of course. They don't bother to rule out such an absurd idea. > > We told you that at the very outset. You now realise that we were > correct and that you were incorrect. That's good. It's a shame we > couldn't have got to this point without you being such an offensive > jerk, but that's life. Presumably now you understand that such > offensiveness is counter-productive? (Don't bother. It's rhetorical.) > Try again. Read back through the thread. It was *I* who first told you the Standards Committee doesn't bother with such an absurd idea. But like a troll, now you're trying to take credit for it. >> Only an idiot would suggest it's possible. As you so well qualify. > > Ah, so you don't realise that offensiveness is counter-productive. And > you continue to make mistakes. It is simply not true that "only an idiot > would suggest it's possible". It's not forbidden by the Standard and > it's not breaking the laws of physics, so why /wouldn't/ it be possible? > > No, the idiocy lies not in suggesting it's not possible but in insisting > that it's forbidden in the face of genuine experts who have demonstrated > otherwise in meticulous detail. > Yes, the truth does hurt, doesn't it? -- ================== 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:42 -0700 |
| Message-ID | <77dd4179-c844-4814-9695-2c2231eb220b@googlegroups.com> |
| In reply to | #91149 |
On Wednesday, July 27, 2016 at 12:05:29 PM UTC-4, Jerry Stuckle wrote:
> On 7/27/2016 10:58 AM, jameskuyper@verizon.net wrote:
> > On Tuesday, July 26, 2016 at 11:26:34 PM UTC-4, Jerry Stuckle wrote:
...
> >> Show me ONE compiler which has sizeof(short) > sizeof(int).
...
> The Standards Committee hasn't specifically ruled it out
As Richard said: QED.
> ... because it
> doesn't concern itself with such absurd ideas. ...
Yes, it does, actually - on a fairly regular basis. That's mostly because they are, at least as a group, substantially more open-minded than you are, but also partly because they feel obligated to respond officially and meaningfully to any properly filed defect report, so they often have to respond to some really stupid questions.
...
> > 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).
...
> You have no idea what I would or would not consider absurd,
Yes, I do - you've presented a fair number of examples in this newsgroup of how you do what you would call "thinking" - and I'm also very familiar with the kinds of issues that have been raised in defect reports. That's sufficient information to justify the conclusions I described above.
> ... and to even
> claim that you do shows how stoopid you really are.
When your main argument on just every issue is to assert that your opponents are stupid for disagreeing with you, it doesn't help you much to misspell it.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-27 16:20 -0400 |
| Message-ID | <nnb52d$ci1$3@jstuckle.eternal-september.org> |
| In reply to | #91159 |
On 7/27/2016 12:42 PM, jameskuyper@verizon.net wrote: ... Nothing worth responding to. Just another 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-26 15:31 -0700 |
| Message-ID | <34c53a97-ce5d-4303-a336-cc466528900e@googlegroups.com> |
| In reply to | #91111 |
On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: ... > Yes, they make up extreme examples. But people of intelligence make up > REASONABLE extreme examples. Not absurd ones like Richard's. Actually, the absurd example that has been the topic of this sub-thread was Ben's not Richards. So, let's take a close look at that example. It's obviously absurd, and no one has ever suggested other wise, but every absurd feature of it served to highlight an important fact: Absurd Feature 1: it has padding bits all over the place. Corresponding important fact: the standard imposes no requirements, of any kind, on the location of padding bits. Absurd Feature 2: no two of the padding bits are adjacent to each other Corresponding important fact: the standard, in particular, imposes no requirement that padding bits be adjacent to each other. Nor does it require that value bits be adjacent to each other. Absurd Feature 3: it has a total of 16 padding bits. Corresponding important fact: the standard imposes no upper limit on the number of padding bits. Absurd Feature 4: despite feature 3, because of feature 2, there's not a single byte in the entire object composed entirely of padding bits. Corresponding important fact: you can have more than CHAR_BIT padding bits without have any padding bytes. Your non-existent reputation as a reasonable man would be better served by identifying which of those facts you consider to be false, rather than just calling the whole thing "absurd". Of course, that would require that you identify the text from the standard that imposes the relevant requirements. That reputation would be even better served by admitting that there are no such requirements. I predict that you will do none of those things: you won't be specific about which of those facts you dispute, you won't identify relevant requirements, and you won't admit that there aren't any.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-26 23:32 -0400 |
| Message-ID | <nn9a0i$86m$1@jstuckle.eternal-september.org> |
| In reply to | #91117 |
On 7/26/2016 6:31 PM, jameskuyper@verizon.net wrote: > On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: > ... >> Yes, they make up extreme examples. But people of intelligence make up >> REASONABLE extreme examples. Not absurd ones like Richard's. > > Actually, the absurd example that has been the topic of this sub-thread was Ben's not Richards. > > So, let's take a close look at that example. It's obviously absurd, and no one has ever suggested other wise, but every absurd feature of it served to highlight an important fact: > > Absurd Feature 1: it has padding bits all over the place. > Corresponding important fact: the standard imposes no requirements, of any kind, on the location of padding bits. > > Absurd Feature 2: no two of the padding bits are adjacent to each other > Corresponding important fact: the standard, in particular, imposes no requirement that padding bits be adjacent to each other. Nor does it require that value bits be adjacent to each other. > > Absurd Feature 3: it has a total of 16 padding bits. > Corresponding important fact: the standard imposes no upper limit on the number of padding bits. > > Absurd Feature 4: despite feature 3, because of feature 2, there's not a single byte in the entire object composed entirely of padding bits. > Corresponding important fact: you can have more than CHAR_BIT padding bits without have any padding bytes. > > Your non-existent reputation as a reasonable man would be better served by identifying which of those facts you consider to be false, rather than just calling the whole thing "absurd". Of course, that would require that you identify the text from the standard that imposes the relevant requirements. That reputation would be even better served by admitting that there are no such requirements. I predict that you will do none of those things: you won't be specific about which of those facts you dispute, you won't identify relevant requirements, and you won't admit that there aren't any. > I don't care what you think of my reputation. The people who count know and appreciate my reputation because I've never steered them wrong. And they pay me quite well for my work, which makes me quite happy. I also have quite a good reputation amongst real C experts - not like the people here who think they know something about the language because the can quote the standard (not that they have the official standard - just a draft). The guys I know are called on by members of the standards committee (or are on the committee themselves) for their input into the process. They not only read the standards (and yes, they have the real standard - not a copy of a draft), but they understand what the standard says - and doesn't say. Nothing you or anyone else on this newsgroup stack up against any of those people. And I still maintain the example is so totally absurd it isn't even worth bringing up. Try to run it past the standards committee. You'll be laughed out of the room. -- ================== 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-27 07:58 +0100 |
| Message-ID | <nn9m2j$41r$1@dont-email.me> |
| In reply to | #91120 |
On 27/07/16 04:32, Jerry Stuckle wrote: > On 7/26/2016 6:31 PM, jameskuyper@verizon.net wrote: >> On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: >> ... >>> Yes, they make up extreme examples. But people of intelligence make up >>> REASONABLE extreme examples. Not absurd ones like Richard's. >> >> Actually, the absurd example that has been the topic of this sub-thread was Ben's not Richards. >> >> So, let's take a close look at that example. It's obviously absurd, and no one has ever suggested other wise, but every absurd feature of it served to highlight an important fact: >> >> Absurd Feature 1: it has padding bits all over the place. >> Corresponding important fact: the standard imposes no requirements, of any kind, on the location of padding bits. >> >> Absurd Feature 2: no two of the padding bits are adjacent to each other >> Corresponding important fact: the standard, in particular, imposes no requirement that padding bits be adjacent to each other. Nor does it require that value bits be adjacent to each other. >> >> Absurd Feature 3: it has a total of 16 padding bits. >> Corresponding important fact: the standard imposes no upper limit on the number of padding bits. >> >> Absurd Feature 4: despite feature 3, because of feature 2, there's not a single byte in the entire object composed entirely of padding bits. >> Corresponding important fact: you can have more than CHAR_BIT padding bits without have any padding bytes. >> >> Your non-existent reputation as a reasonable man would be better served by identifying which of those facts you consider to be false, rather than just calling the whole thing "absurd". Of course, that would require that you identify the text from the standard that imposes the relevant requirements. That reputation would be even better served by admitting that there are no such requirements. I predict that you will do none of those things: you won't be specific about which of those facts you dispute, you won't identify relevant requirements, and you won't admit that there aren't any. >> > > I don't care what you think of my reputation. You obviously don't care what /anyone/ thinks of your reputation, or you wouldn't post such drivel on a public server. > The people who count know > and appreciate my reputation because I've never steered them wrong. Well, you probably /have/ steered them wrong, if your track record here is anything to go by. But as long as they never find out, you'll be fine. > And they pay me quite well for my work, which makes me quite happy. I'm sure it does, but we've all known well-paid contractors who think they know what they're doing but don't. One of the first C contractors I ever met thought char * meant "string", as in: char *p; strcpy(p, "yes, he really believed the memory would magically appear"); - and, since at the time I hadn't yet ventured out into contracting, he was paid far more than me - but he was still wrong, and I told him so (and I explained how he could achieve what he needed to achieve). Unlike you, he had the grace to acknowledge the fact and the ability to learn from someone who knew C better than he did. > I also have quite a good reputation amongst real C experts You have demonstrated that you are not capable of recognising real C experts. -- 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:52 -0400 |
| Message-ID | <nnaap9$8li$1@jstuckle.eternal-september.org> |
| In reply to | #91125 |
On 7/27/2016 2:58 AM, Richard Heathfield wrote: > On 27/07/16 04:32, Jerry Stuckle wrote: >> On 7/26/2016 6:31 PM, jameskuyper@verizon.net wrote: >>> On Tuesday, July 26, 2016 at 4:39:14 PM UTC-4, Jerry Stuckle wrote: >>> ... >>>> Yes, they make up extreme examples. But people of intelligence make up >>>> REASONABLE extreme examples. Not absurd ones like Richard's. >>> >>> Actually, the absurd example that has been the topic of this >>> sub-thread was Ben's not Richards. >>> >>> So, let's take a close look at that example. It's obviously absurd, >>> and no one has ever suggested other wise, but every absurd feature of >>> it served to highlight an important fact: >>> >>> Absurd Feature 1: it has padding bits all over the place. >>> Corresponding important fact: the standard imposes no requirements, >>> of any kind, on the location of padding bits. >>> >>> Absurd Feature 2: no two of the padding bits are adjacent to each other >>> Corresponding important fact: the standard, in particular, imposes no >>> requirement that padding bits be adjacent to each other. Nor does it >>> require that value bits be adjacent to each other. >>> >>> Absurd Feature 3: it has a total of 16 padding bits. >>> Corresponding important fact: the standard imposes no upper limit on >>> the number of padding bits. >>> >>> Absurd Feature 4: despite feature 3, because of feature 2, there's >>> not a single byte in the entire object composed entirely of padding >>> bits. >>> Corresponding important fact: you can have more than CHAR_BIT padding >>> bits without have any padding bytes. >>> >>> Your non-existent reputation as a reasonable man would be better >>> served by identifying which of those facts you consider to be false, >>> rather than just calling the whole thing "absurd". Of course, that >>> would require that you identify the text from the standard that >>> imposes the relevant requirements. That reputation would be even >>> better served by admitting that there are no such requirements. I >>> predict that you will do none of those things: you won't be specific >>> about which of those facts you dispute, you won't identify relevant >>> requirements, and you won't admit that there aren't any. >>> >> >> I don't care what you think of my reputation. > > You obviously don't care what /anyone/ thinks of your reputation, or you > wouldn't post such drivel on a public server. > Oh, I do care what some people think about my reputation. And I've even pointed some of them to this newsgroup. All they do is shake their heads and ask how some people here ever got jobs as programmers. >> The people who count know >> and appreciate my reputation because I've never steered them wrong. > > Well, you probably /have/ steered them wrong, if your track record here > is anything to go by. But as long as they never find out, you'll be fine. > You sure are good at jumping to absurd conclusions, aren't you? >> And they pay me quite well for my work, which makes me quite happy. > > I'm sure it does, but we've all known well-paid contractors who think > they know what they're doing but don't. One of the first C contractors I > ever met thought char * meant "string", as in: char *p; strcpy(p, "yes, > he really believed the memory would magically appear"); - and, since at > the time I hadn't yet ventured out into contracting, he was paid far > more than me - but he was still wrong, and I told him so (and I > explained how he could achieve what he needed to achieve). Unlike you, > he had the grace to acknowledge the fact and the ability to learn from > someone who knew C better than he did. > I wouldn't have survived for over 25 years as a consultant (not a "contractor") if I didn't know what I was doing. And I wouldn't have companies keep coming back to me if I didn't get their jobs successfully finished in time and under budget. >> I also have quite a good reputation amongst real C experts > > You have demonstrated that you are not capable of recognising real C > experts. > Oh, I am. But you are definitely not one of them. Something you've proven time and time again. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-27 11:21 +0100 |
| Message-ID | <nna1vh$9gb$1@dont-email.me> |
| In reply to | #91109 |
On 26/07/2016 21:23, jameskuyper@verizon.net wrote: [Are you still on Google Groups?] > 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. I haven't a clue what anyone is on about so leave me out of it! Anyone could be right or wrong, maybe both. But perhaps another topic to add my collection of C quirks. (BTW why is it only C that is obsessed with padding bits? They don't seem to crop up with any other language. Not even assembly.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-27 13:34 +0100 |
| Message-ID | <nna9ot$4ji$1@dont-email.me> |
| In reply to | #91128 |
On 27/07/16 11:21, BartC wrote: > On 26/07/2016 21:23, jameskuyper@verizon.net wrote: > > [Are you still on Google Groups?] > > > 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. > > I haven't a clue what anyone is on about so leave me out of it! Fair enough. > Anyone > could be right or wrong, maybe both. No, there's no question about it. The matter under consideration is whether sizeof(short) can exceed sizeof(int), and Jerry Stuckle's position is that it makes no sense that such an absurd case could be permitted by the Standard. James has guessed that few people who contribute to the group would agree with Jerry Stuckle, but that, if there were any, you /might/ be one of them. I presume he is basing that on your track record, but of course you might not agree with Jerry Stuckle, or you might not know whether or not you do (which now appears to be the case). But the Standard can leave no C expert in any doubt that an implementation could make sizeof(short) > sizeof(int) and still be conforming. A number of citations to that effect have been made, and no evidence *at all* has been presented in support of Jerry Stuckle's claim, except his own pleading that nothing so absurd could possibly be permitted. Nobody denies that it's absurd, but to claim that it is therefore not permitted is simply wrong. > But perhaps another topic to add my collection of C quirks. Perhaps. But if you bang on about it here, don't expect anyone to be impressed. :-) > (BTW why is it only C that is obsessed with padding bits? They don't > seem to crop up with any other language. Not even assembly.) C isn't obsessed with padding bits. It doesn't even require them. It simply permits them. That is, it refuses to place an arbitrary limitation on implementations for no good reason, and that's a very good sign. It is not the function of language standards to impose arbitrary limitations on implementations for no good reason, and so we should be encouraged that ISO has not done so on this occasion. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-27 16:31 +0200 |
| Message-ID | <nnagks$u8l$1@dont-email.me> |
| In reply to | #91129 |
On 27/07/16 14:34, Richard Heathfield wrote: > On 27/07/16 11:21, BartC wrote: > >> (BTW why is it only C that is obsessed with padding bits? They don't >> seem to crop up with any other language. Not even assembly.) > Assembly can have padding bits too - it's just assembly on the processors /you/ are familiar with that don't have them. To be fair, few modern cpus need any sort of padding unless you are trying to use bitfields. But they do turn up in odd processor architectures, including some mainframes or older machines. So C allows the possibility of padding bits for much the same reasons it allows signed integers in formats other than two's complement. Most higher level languages insulate you from such low-level details, so that you neither know nor care about any padding bits. But in C, they could occasionally be relevant because you do low-level operations in different ways. > C isn't obsessed with padding bits. It doesn't even require them. It > simply permits them. That is, it refuses to place an arbitrary > limitation on implementations for no good reason, and that's a very good > sign. It is not the function of language standards to impose arbitrary > limitations on implementations for no good reason, and so we should be > encouraged that ISO has not done so on this occasion. >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-27 16:20 +0100 |
| Message-ID | <8760rrf6q8.fsf@bsb.me.uk> |
| In reply to | #91133 |
David Brown <david.brown@hesbynett.no> writes: > On 27/07/16 14:34, Richard Heathfield wrote: >> On 27/07/16 11:21, BartC wrote: > >> >>> (BTW why is it only C that is obsessed with padding bits? They don't >>> seem to crop up with any other language. Not even assembly.) >> > > Assembly can have padding bits too - it's just assembly on the > processors /you/ are familiar with that don't have them. To be fair, > few modern cpus need any sort of padding unless you are trying to use > bitfields. But they do turn up in odd processor architectures, > including some mainframes or older machines. So C allows the > possibility of padding bits for much the same reasons it allows signed > integers in formats other than two's complement. There's another more direct use of padding bits: _Bool. In most C implementations _Bool has one value bit and 7 padding bits. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-27 23:36 +0100 |
| Message-ID | <nnbd27$c7d$1@dont-email.me> |
| In reply to | #91145 |
On 27/07/2016 16:20, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 27/07/16 14:34, Richard Heathfield wrote: >>> On 27/07/16 11:21, BartC wrote: >> >>> >>>> (BTW why is it only C that is obsessed with padding bits? They don't >>>> seem to crop up with any other language. Not even assembly.) >>> >> >> Assembly can have padding bits too - it's just assembly on the >> processors /you/ are familiar with that don't have them. To be fair, >> few modern cpus need any sort of padding unless you are trying to use >> bitfields. But they do turn up in odd processor architectures, >> including some mainframes or older machines. So C allows the >> possibility of padding bits for much the same reasons it allows signed >> integers in formats other than two's complement. > > There's another more direct use of padding bits: _Bool. In most C > implementations _Bool has one value bit and 7 padding bits. Are the really padding bits, or does it just restrict the value that can be stored in an 8-bit type to 0 or 1 instead of 0 to 255? Because I could easily store data in those extra 7 bits in all six C compilers I tried (by casting _Bool* to char*). I think all of them restricted the value that can be stored in a _Bool to 0 or 1, but not all of them did the same when reading out the value as a _Bool (they assumed the other 7 bits were zero). (How many padding bits would there be in a type that occupies 8 bits, but restricts the values to 80 to 100? It wouldn't be meaningful here, and neither do I think that the spare bits in a _Bool are real padding bits.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-28 14:51 +0100 |
| Message-ID | <87zip1yip2.fsf@bsb.me.uk> |
| In reply to | #91189 |
BartC <bc@freeuk.com> writes: > On 27/07/2016 16:20, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 27/07/16 14:34, Richard Heathfield wrote: >>>> On 27/07/16 11:21, BartC wrote: >>> >>>> >>>>> (BTW why is it only C that is obsessed with padding bits? They don't >>>>> seem to crop up with any other language. Not even assembly.) >>>> >>> >>> Assembly can have padding bits too - it's just assembly on the >>> processors /you/ are familiar with that don't have them. To be fair, >>> few modern cpus need any sort of padding unless you are trying to use >>> bitfields. But they do turn up in odd processor architectures, >>> including some mainframes or older machines. So C allows the >>> possibility of padding bits for much the same reasons it allows signed >>> integers in formats other than two's complement. >> >> There's another more direct use of padding bits: _Bool. In most C >> implementations _Bool has one value bit and 7 padding bits. > > Are the really padding bits, or does it just restrict the value that > can be stored in an 8-bit type to 0 or 1 instead of 0 to 255? The bits in an integer type's representation are either a sign bit, values bits or padding bits. > Because I could easily store data in those extra 7 bits in all six C > compilers I tried (by casting _Bool* to char*). Yes, that's common. Exactly what happens then is then up to the implementation, but it's got carte blanche since almost everything to do with padding bits is undefined. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-28 09:26 -0700 |
| Message-ID | <b950294f-1a8c-4c0f-87a6-f307f3138f24@googlegroups.com> |
| In reply to | #91231 |
On Thursday, July 28, 2016 at 2:51:28 PM UTC+1, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
> > Because I could easily store data in those extra 7 bits in all six C
> > compilers I tried (by casting _Bool* to char*).
>
> Yes, that's common. Exactly what happens then is then up to the
> implementation, but it's got carte blanche since almost everything to do
> with padding bits is undefined.
>
int particular
void foo(bool aflag)
{
if(aflag)
printf("Flagged\n");
}
can compile to
byteregister aflag
branch if aflag equals 1 : doprint
or
byteregister aflag
branch if aflag notequals 0 : doprint
If padding is held to zero, both will work. If you fiddle about with the
padding bits, you might get unexpected results.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-28 10:54 -0700 |
| Message-ID | <kfn7fc5ps0e.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91145 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > David Brown <david.brown@hesbynett.no> writes: > >> On 27/07/16 14:34, Richard Heathfield wrote: >>> On 27/07/16 11:21, BartC wrote: >>> >>>> (BTW why is it only C that is obsessed with padding bits? They don't >>>> seem to crop up with any other language. Not even assembly.) >>> >> >> Assembly can have padding bits too - it's just assembly on the >> processors /you/ are familiar with that don't have them. To be fair, >> few modern cpus need any sort of padding unless you are trying to use >> bitfields. But they do turn up in odd processor architectures, >> including some mainframes or older machines. So C allows the >> possibility of padding bits for much the same reasons it allows signed >> integers in formats other than two's complement. > > There's another more direct use of padding bits: _Bool. In most C > implementations _Bool has one value bit and 7 padding bits. I seem to recall a response to a Defect report that says the width of _Bool must be one. If that is true then _Bool will always have at least CHAR_BIT-1 padding bits.
[toc] | [prev] | [next] | [standalone]
Page 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web