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 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-31 14:07 -0700 |
| Message-ID | <7dce47ca-503c-4f82-9afc-b4764b9f6102@googlegroups.com> |
| In reply to | #91374 |
On Saturday, July 30, 2016 at 2:09:44 PM UTC-5, Tim Rentsch wrote: > Most so-called language lawyers don't have to deal with the > sobering consequences that real lawyers experience when they go > through a trial and have a verdict delivered. I try not to get > too invested in language-lawyer type arguments, because usually > they are pretty much pointless. The key governing body for ISO C > is WG14. Unless those arguing about what the Standard "really > means" are willing to have their opinions adjudicated by WG14, > for the most part it's all just a lot of hot air. And that goes > for my comments as well as anyone else's. The problem is that the authors of C89 never intended it to be subjected to 21st-century language lawyers seeking to justify having compilers for existing platforms implement behaviors that were totally unlike anything that existed previously. The authors of the Standard listed the common consequences of UB. They did not forbid all other possibilities, nor did they intend to, but I would expect that they expected quality compilers to refrain from going far beyond those possibilities without a really strong and compelling reason; while 21st-century language lawyers may regard the possibility of optimization as a compelling reason, I don't concur with such judgment.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-31 16:56 -0700 |
| Message-ID | <kfnoa5dl5tv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91429 |
supercat@casperkitty.com writes: > On Saturday, July 30, 2016 at 2:09:44 PM UTC-5, Tim Rentsch wrote: >> Most so-called language lawyers don't have to deal with the >> sobering consequences that real lawyers experience when they go >> through a trial and have a verdict delivered. I try not to get >> too invested in language-lawyer type arguments, because usually >> they are pretty much pointless. The key governing body for ISO C >> is WG14. Unless those arguing about what the Standard "really >> means" are willing to have their opinions adjudicated by WG14, >> for the most part it's all just a lot of hot air. And that goes >> for my comments as well as anyone else's. > > The problem is that the authors of C89 never intended it to be > [...] I think they are in a better position to say what they intended than you are.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-01 08:57 -0700 |
| Message-ID | <cd436839-4875-498b-ba27-34eadf43784c@googlegroups.com> |
| In reply to | #91443 |
On Sunday, July 31, 2016 at 6:56:52 PM UTC-5, Tim Rentsch wrote:
> I think they are in a better position to say what they
> intended than you are.
The authors of the C Standard express the following beliefs in the
rationale for the One Program Rule:
1. While the Standard only requires that an implementation be
able to process one program correctly, **any quality implementation
will go beyond the requirements given by the Standard**.
2. In cases where it would be easier for a compiler to behave usefully
than to behave uselessly, there is no need to go into great detail
about what compilers must do in order to be useful.
Is there any reason to believe they did not intend that quality
implementations would go beyond the requirements given in the
Standard in any way other than their ability to correctly translate
more than one program?
Is there any reason to believe that they endeavored to go into great
detail about all the cases where quality implementations should treat
behavior as defined, given that they expressed a belief that quality
implementations wouldn't go out of their way to be unhelpful?
Is there anything they've written which would contradict my interpretation
of their statements in the rationale?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-27 11:41 -0700 |
| Message-ID | <5bcdcc9d-a66e-4305-8883-05f395c00376@googlegroups.com> |
| In reply to | #91150 |
On Wednesday, July 27, 2016 at 11:09:42 AM UTC-5, Tim Rentsch wrote: > Surely the Standard does not expect that storing into a > bitfield member will preserve the values of any bits used for > padding that happen to occupy less than a full byte. Prior to the publication of C89, there were implementations that would preserve such padding but there were likely others that would not do so. I suspect the reason the "common-initial-sequence" guarantee only grants permission to "inspect" other types has to do with the possibility that storing a value into the last element the common initial sequence might corrupt the contents of other bits or bytes that are not used in the type used for access but might be used in other types which share the same initial sequence. Since the authors of the Standard expected that implementations which offered guarantees beyond those mandated by the Standard would not need to be ordered to keep offering them, and since a requirement that padding bits not be disturbed would force implementations to run some existing code less efficiently than had been possible previously, the authors of the Standard chose to let implementations decide whether or not to preserve padding when updating structure members.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-28 11:25 -0700 |
| Message-ID | <kfny44loc1c.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91168 |
supercat@casperkitty.com writes: > On Wednesday, July 27, 2016 at 11:09:42 AM UTC-5, Tim Rentsch wrote: >> Surely the Standard does not expect that storing into a >> bitfield member will preserve the values of any bits used for >> padding that happen to occupy less than a full byte. > > Prior to the publication of C89, there were implementations that would > preserve such padding but there were likely others that would not do so. > I suspect the reason the "common-initial-sequence" guarantee only > grants permission to "inspect" other types has to do with the possibility > that storing a value into the last element the common initial sequence > might corrupt the contents of other bits or bytes that are not used in > the type used for access but might be used in other types which share the > same initial sequence. Two sentences, 88 words. An average of 44 words/sentence. Postings from other people in the newsgroup typically average under 20 words/sentence per paragraph, usually topping out in the 20's or low 30's. It is rare to see a paragraph with as many as 40 words/sentence. At least, it is rare in others' postings. > Since the authors of the Standard expected that implementations which > offered guarantees beyond those mandated by the Standard would not need > to be ordered to keep offering them, and since a requirement that padding > bits not be disturbed would force implementations to run some existing > code less efficiently than had been possible previously, the authors of > the Standard chose to let implementations decide whether or not to preserve > padding when updating structure members. A verbal monstrosity. One sentence, 73 words. More than twice the maximum of most postings from other people. There is very little incentive to wade though such verbal diarrhea.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-24 15:28 -0700 |
| Message-ID | <cd01cfda-052e-4063-96b4-53e2304ecd81@googlegroups.com> |
| In reply to | #90916 |
On Sunday, July 24, 2016 at 5:28:53 PM UTC-4, Jerry Stuckle wrote: > On 7/24/2016 12:38 PM, jameskuyper@verizon.net wrote: > > On Sunday, July 24, 2016 at 11:06:43 AM UTC-4, Jerry Stuckle wrote: > >> On 7/23/2016 8:52 PM, Ben Bacarisse wrote: > >>> Jerry Stuckle <jstucklex@attglobal.net> writes: > > ... > >>>> No, it means allocate the amount required for 40 ints and assign the > >>>> address to magptr. An int is NOT necessarily 4 bytes. It can be any > >>>> length at least as big as a short and not bigger than a long. > >>> > >>> That last bit true of what C calls the width of the types (the number of > >>> value bits plus one for signed types) but, because of the possibility of > >>> padding bits, it's not true of the size in bytes. Of course it's almost > >>> inconceivable that any real implementation would have, for example, > >>> sizeof (short) > sizeof (int) but it is permitted. > >>> > >>> <snip> > >>> > >> > >> It is also the size in bytes. Size of an int does not > >> include any padding. ... > > Are you suggesting that an integer type with padding bits has > > a size the doesn't include those bits? Types with padding > > bits often only 1 or 2 padding bits. Since sizeof returns an > > unsigned integer value, how would it report a size of 2.875 > > bytes? > > > > Yes - BITS, not BYTES. Do you know the difference? Yes, there's CHAR_BIT bits in a byte. Bits and bytes are, except for being different sizes, equally valid units for measuring memory. If you said something about kilometers, and I said something about meters, and what I said about meters was exactly correct, taking into the consideration the ratio of 1000 meters to one kilometer, would such a statement make you feel justified in asking me whether I knew the difference between meters and kilometers? There are CHAR_BIT padding bits in a padding byte. Which means that allowing an unlimited number of padding bits (as the standard does) means that entire padding bytes are also allowed. However, if the number of padding bits is not an integer multiple of CHAR_BIT, and if you were right about padding being excluded from the size, then sizeof could only correctly report the size by returning a factional number of bytes, which is not actually permitted. > > Let's avoid that issue, at the cost of assuming an extremely > > implausible implementation: assume that 'int' is has 23 value > > bits, 1 sign bit, and 8 padding bits, so it requires 32 bits > > to store an 'int'. Assume CHAR_BIT==8. Are you suggesting > > that sizeof(int) for that platform must be 3? I went out of my way to anticipate that you might raise some confusion about the difference between bits and bytes. I deliberately constructed an example where there was an entire padding byte - precisely to address the quibble that you did, as I expected, raise. And you ignored that example. ... > >> And no, sizeof (short) > sizeof (int) is not permitted. > > > > Citation, please? ... > Which would make as much sense as your first comment. > > Sheesh. Language lawyers who don't know language or law. I do know that if what you said about it not being permitted were true, there would be a relevant rule you could cite which said so. I'll take your failure to cite such a rule as being the closest you'll ever come to admitting what everyone else already knows: you know so little about the C standard that you incorrectly thought there was such a rule. You can't give a proper citation of a real rule that is applicable, so you'll probably just continue ignoring my request for a citation. I expect that if you make any attempt to cite a relevant rule, it will be described so vaguely as to be impossible to falsify - a citation is NOT "proper" unless it is sufficiently specific to allow such falsification, if it happened to be false - at a minimum, it must include precise section numbers and paragraph numbers.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 21:00 -0400 |
| Message-ID | <nn3obm$6ca$4@jstuckle.eternal-september.org> |
| In reply to | #90922 |
On 7/24/2016 6:28 PM, jameskuyper@verizon.net wrote: > On Sunday, July 24, 2016 at 5:28:53 PM UTC-4, Jerry Stuckle wrote: >> On 7/24/2016 12:38 PM, jameskuyper@verizon.net wrote: >>> On Sunday, July 24, 2016 at 11:06:43 AM UTC-4, Jerry Stuckle wrote: >>>> On 7/23/2016 8:52 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> ... >>>>>> No, it means allocate the amount required for 40 ints and assign the >>>>>> address to magptr. An int is NOT necessarily 4 bytes. It can be any >>>>>> length at least as big as a short and not bigger than a long. >>>>> >>>>> That last bit true of what C calls the width of the types (the number of >>>>> value bits plus one for signed types) but, because of the possibility of >>>>> padding bits, it's not true of the size in bytes. Of course it's almost >>>>> inconceivable that any real implementation would have, for example, >>>>> sizeof (short) > sizeof (int) but it is permitted. >>>>> >>>>> <snip> >>>>> >>>> >>>> It is also the size in bytes. Size of an int does not >>>> include any padding. > ... >>> Are you suggesting that an integer type with padding bits has >>> a size the doesn't include those bits? Types with padding >>> bits often only 1 or 2 padding bits. Since sizeof returns an >>> unsigned integer value, how would it report a size of 2.875 >>> bytes? >>> >> >> Yes - BITS, not BYTES. Do you know the difference? > > Yes, there's CHAR_BIT bits in a byte. Bits and bytes are, except > for being different sizes, equally valid units for measuring > memory. If you said something about kilometers, and I said > something about meters, and what I said about meters was exactly > correct, taking into the consideration the ratio of 1000 meters > to one kilometer, would such a statement make you feel justified > in asking me whether I knew the difference between meters and > kilometers? > There are CHAR_BIT padding bits in a padding byte. Which means > that allowing an unlimited number of padding bits (as the > standard does) means that entire padding bytes are also allowed. > However, if the number of padding bits is not an integer multiple > of CHAR_BIT, and if you were right about padding being excluded > from the size, then sizeof could only correctly report the size > by returning a factional number of bytes, which is not actually > permitted. > >>> Let's avoid that issue, at the cost of assuming an extremely >>> implausible implementation: assume that 'int' is has 23 value >>> bits, 1 sign bit, and 8 padding bits, so it requires 32 bits >>> to store an 'int'. Assume CHAR_BIT==8. Are you suggesting >>> that sizeof(int) for that platform must be 3? > > I went out of my way to anticipate that you might raise some > confusion about the difference between bits and bytes. I > deliberately constructed an example where there was an entire > padding byte - precisely to address the quibble that you did, as > I expected, raise. And you ignored that example. > > ... >>>> And no, sizeof (short) > sizeof (int) is not permitted. >>> >>> Citation, please? > ... >> Which would make as much sense as your first comment. >> >> Sheesh. Language lawyers who don't know language or law. > > I do know that if what you said about it not being permitted were > true, there would be a relevant rule you could cite which said > so. I'll take your failure to cite such a rule as being the > closest you'll ever come to admitting what everyone else already > knows: you know so little about the C standard that you > incorrectly thought there was such a rule. > > You can't give a proper citation of a real rule that is > applicable, so you'll probably just continue ignoring my request > for a citation. I expect that if you make any attempt to cite a > relevant rule, it will be described so vaguely as to be > impossible to falsify - a citation is NOT "proper" unless it is > sufficiently specific to allow such falsification, if it happened > to be false - at a minimum, it must include precise section > numbers and paragraph numbers. > You can't give a proper citation to support your claim that C allows for padding BYTES. But then trolls and idiots don't need to support their claims - and you have repeatedly shown yourself to be both. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-25 02:31 +0100 |
| Message-ID | <nn3q69$b7c$1@dont-email.me> |
| In reply to | #90932 |
On 25/07/16 02:00, Jerry Stuckle wrote: > On 7/24/2016 6:28 PM, jameskuyper@verizon.net wrote: <snip> >> You can't give a proper citation of a real rule that is >> applicable, so you'll probably just continue ignoring my request >> for a citation. I expect that if you make any attempt to cite a >> relevant rule, it will be described so vaguely as to be >> impossible to falsify - a citation is NOT "proper" unless it is >> sufficiently specific to allow such falsification, if it happened >> to be false - at a minimum, it must include precise section >> numbers and paragraph numbers. > > You can't give a proper citation to support your claim that C allows for > padding BYTES. He has already cited support for his claim. You have not cited support for your claim. > But then trolls and idiots don't need to support their > claims If the cap fits, wear it. > - and you have repeatedly shown yourself to be both. James Kuyper has repeatedly shown himself to be an expert on the C programming language. When he is wrong, he generally recognises the fact and says so. But he is rarely wrong. And he is certainly not wrong in this case. He is neither a troll nor an idiot. You, on the other hand, jumped in here a few months ago - heaven knows why - and immediately started to behave in a boorish, uncivilised way. Well, comp.lang.c is quite good at putting up with such people, /if/ they know their stuff, but you have repeatedly demonstrated that you do /not/ know your stuff. On the rare occasions that you try to argue from a technical perspective, you fail to justify your argument with reference to the Standard. You have demonstrated an unwillingness to learn and a penchant for insulting people instead of learning from them. Your behaviour does you no credit whatsoever. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 22:21 -0400 |
| Message-ID | <nn3t3j$fq0$1@jstuckle.eternal-september.org> |
| In reply to | #90937 |
On 7/24/2016 9:31 PM, Richard Heathfield wrote: > On 25/07/16 02:00, Jerry Stuckle wrote: >> On 7/24/2016 6:28 PM, jameskuyper@verizon.net wrote: > > <snip> > >>> You can't give a proper citation of a real rule that is >>> applicable, so you'll probably just continue ignoring my request >>> for a citation. I expect that if you make any attempt to cite a >>> relevant rule, it will be described so vaguely as to be >>> impossible to falsify - a citation is NOT "proper" unless it is >>> sufficiently specific to allow such falsification, if it happened >>> to be false - at a minimum, it must include precise section >>> numbers and paragraph numbers. >> >> You can't give a proper citation to support your claim that C allows for >> padding BYTES. > > He has already cited support for his claim. You have not cited support > for your claim. > You have cited nothing which allows for padding bytes. And the standard defines what can be done, not what cannot be done. In this case, it says you can pad bits. The standard also makes a distinction between bits and bytes - but does not say you can pad an int with bytes. >> But then trolls and idiots don't need to support their >> claims > > If the cap fits, wear it. > What size do you wear? >> - and you have repeatedly shown yourself to be both. > > James Kuyper has repeatedly shown himself to be an expert on the C > programming language. When he is wrong, he generally recognises the fact > and says so. But he is rarely wrong. And he is certainly not wrong in > this case. He is neither a troll nor an idiot. > > You, on the other hand, jumped in here a few months ago - heaven knows > why - and immediately started to behave in a boorish, uncivilised way. > Well, comp.lang.c is quite good at putting up with such people, /if/ > they know their stuff, but you have repeatedly demonstrated that you do > /not/ know your stuff. On the rare occasions that you try to argue from > a technical perspective, you fail to justify your argument with > reference to the Standard. You have demonstrated an unwillingness to > learn and a penchant for insulting people instead of learning from them. > Your behaviour does you no credit whatsoever. > And you are nothing but an ignorant asshole. And I really don't give a damn what you think. You're not worth it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-24 19:38 -0700 |
| Message-ID | <66a43602-2319-49c7-8d15-4efa3e0bad8c@googlegroups.com> |
| In reply to | #90932 |
On Sunday, July 24, 2016 at 9:00:45 PM UTC-4, Jerry Stuckle wrote: > On 7/24/2016 6:28 PM, jameskuyper@verizon.net wrote: ... > > Yes, there's CHAR_BIT bits in a byte. Bits and bytes are, except > > for being different sizes, equally valid units for measuring > > memory. If you said something about kilometers, and I said > > something about meters, and what I said about meters was exactly > > correct, taking into the consideration the ratio of 1000 meters > > to one kilometer, would such a statement make you feel justified > > in asking me whether I knew the difference between meters and > > kilometers? > > There are CHAR_BIT padding bits in a padding byte. Which means > > that allowing an unlimited number of padding bits (as the > > standard does) means that entire padding bytes are also allowed. > > However, if the number of padding bits is not an integer multiple > > of CHAR_BIT, and if you were right about padding being excluded > > from the size, then sizeof could only correctly report the size > > by returning a factional number of bytes, which is not actually > > permitted. ... > You can't give a proper citation to support your claim that C allows for > padding BYTES. You're right - I can't. Because I don't claim that C allows for padding bytes. I claim that C says nothing to prohibit padding bytes. As such, my claim is one that's impossible to prove by citation - how could I point you at a place where the C standard fails to say something? Contrarywise, my claim would be trivial to disprove, if it were wrong. So tell me, where does the C standard say anything to disallow padding bytes? The C standard imposes only one requirement at the byte level on the representation of non-bit-field types: they must consist of an integer number of bytes (6.2.6.1p4). Every other requirement that the C standard imposes on the representation of integers is at the bit level. Those requirements are as follows (6.2.6.2): * 0 or 1 sign bit, depending upon whether the type is unsigned or signed, respectively. * A number of value bits that is not specified directly. However, minimum numbers of values bits for each integer type can be inferred from the minimum value for the corresponding *_MAX macro and (for signed types) the maximum value of the corresponding *_MIN macro, specified in 5.2.4.2.1. * A number of padding bits that might be 0, but is implicitly allowed to be greater than 1 (because of the use of the plural). There is no upper limit on the number of padding bits. Again, since I'm claiming that there's no such upper limit, it is inherently impossible for me to point at the place where the C standard fails to imposes such a limit. If I were wrong about that, it should be trivial to prove: cite the place where the C standard imposes an upper limit on the number of padding bits? The representations of integer types are otherwise completely unspecified. Unlike my other negative statements, this one I can actually provide a citation for: 6.2.6.1p1: "The representations of all types are unspecified except as stated in this subclause." I believe that "this subclause" refers to 6.2.6 rather than to 6.2.6.1; otherwise it contradicts the fact that 6.2.6.2 specifies a lot about the representation of integer types. I think this is a defect that needs to be corrected, by moving 6.2.6.1p1 to 6.2.6p1. However, that defect doesn't have any impact on my argument. In particular, the C standard doesn't impose any requirements upon the location of the sign, value, and padding bits of a given integer type. It therefore says nothing to prohibit having an entire byte consisting of nothing but padding bits. Now, I would consider it to be entirely reasonable to describe such a byte as a "padding byte" - but if for some reason you obstinately refuse to describe it that way, that's OK with me. Nothing I say below depends upon calling it a padding byte; the only thing my argument requires is that the number of padding bits is not prohibited from being larger than CHAR_BIT. An implementation could have a short int consisting of 1 sign bit, 15 value bits, and 8 padding bits, and CHAR_BIT==8. It therefore requires exactly 3 bytes to store such an object, no matter which bytes contain the padding bits. It might not have a single byte that consists entirely of padding bits - all that matters is that there are 8 of them. We could also have an int type consisting of 1 sign bit and 15 value bits. That would fit in exactly 2 bytes. If you think there's any requirement imposed by the C standard that would be violated by such an implementation, you'll have to identify it. My claim is that there is no such requirement - and as such, it's impossible for me to cite the locations where the C standard doesn't disallow it. Your claim that there is such a requirement should, if it were valid, be trivial to prove, by citing the requirement. So prove it.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2016-07-24 20:18 -0700 |
| Message-ID | <chine.bleu-6BA316.20182224072016@news.eternal-september.org> |
| In reply to | #90954 |
Doesn't a glitch in the malloc mean they've changed something in the VM? -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. 'I desire mercy, not sacrifice.' If you assume the final scene is a dying delusion as Tom Cruise drowns below the Louvre, then Edge of Tomorrow has a happy ending. Kill Tom repeat..
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 08:15 -0400 |
| Message-ID | <nn4vsp$d9r$1@jstuckle.eternal-september.org> |
| In reply to | #90954 |
On 7/24/2016 10:38 PM, jameskuyper@verizon.net wrote: > On Sunday, July 24, 2016 at 9:00:45 PM UTC-4, Jerry Stuckle wrote: >> On 7/24/2016 6:28 PM, jameskuyper@verizon.net wrote: > ... >>> Yes, there's CHAR_BIT bits in a byte. Bits and bytes are, except >>> for being different sizes, equally valid units for measuring >>> memory. If you said something about kilometers, and I said >>> something about meters, and what I said about meters was exactly >>> correct, taking into the consideration the ratio of 1000 meters >>> to one kilometer, would such a statement make you feel justified >>> in asking me whether I knew the difference between meters and >>> kilometers? >>> There are CHAR_BIT padding bits in a padding byte. Which means >>> that allowing an unlimited number of padding bits (as the >>> standard does) means that entire padding bytes are also allowed. >>> However, if the number of padding bits is not an integer multiple >>> of CHAR_BIT, and if you were right about padding being excluded >>> from the size, then sizeof could only correctly report the size >>> by returning a factional number of bytes, which is not actually >>> permitted. > ... >> You can't give a proper citation to support your claim that C allows for >> padding BYTES. > > You're right - I can't. Because I don't claim that C allows for padding bytes. > I claim that C says nothing to prohibit padding bytes. As such, my claim is one > that's impossible to prove by citation - how could I point you at a place where > the C standard fails to say something? Contrarywise, my claim would be trivial > to disprove, if it were wrong. So tell me, where does the C standard say > anything to disallow padding bytes? > The C standard imposes only one requirement at the byte level on the > representation of non-bit-field types: they must consist of an integer number > of bytes (6.2.6.1p4). Every other requirement that the C standard imposes on > the representation of integers is at the bit level. Those requirements are as > follows (6.2.6.2): > > * 0 or 1 sign bit, depending upon whether the type is unsigned or signed, > respectively. > > * A number of value bits that is not specified directly. However, minimum > numbers of values bits for each integer type can be inferred from the minimum > value for the corresponding *_MAX macro and (for signed types) the maximum > value of the corresponding *_MIN macro, specified in 5.2.4.2.1. > > * A number of padding bits that might be 0, but is implicitly allowed to be > greater than 1 (because of the use of the plural). There is no upper limit on > the number of padding bits. Again, since I'm claiming that there's no such > upper limit, it is inherently impossible for me to point at the place where the > C standard fails to imposes such a limit. If I were wrong about that, it should > be trivial to prove: cite the place where the C standard imposes an upper limit > on the number of padding bits? > > The representations of integer types are otherwise completely unspecified. > Unlike my other negative statements, this one I can actually provide a citation > for: > 6.2.6.1p1: "The representations of all types are unspecified except as stated > in this subclause." I believe that "this subclause" refers to 6.2.6 rather than > to 6.2.6.1; otherwise it contradicts the fact that 6.2.6.2 specifies a lot > about the representation of integer types. I think this is a defect that needs > to be corrected, by moving 6.2.6.1p1 to 6.2.6p1. However, that defect doesn't > have any impact on my argument. > > In particular, the C standard doesn't impose any requirements upon the location > of the sign, value, and padding bits of a given integer type. It therefore says > nothing to prohibit having an entire byte consisting of nothing but padding > bits. Now, I would consider it to be entirely reasonable to describe such a > byte as a "padding byte" - but if for some reason you obstinately refuse to > describe it that way, that's OK with me. Nothing I say below depends upon > calling it a padding byte; the only thing my argument requires is that the > number of padding bits is not prohibited from being larger than CHAR_BIT. > > An implementation could have a short int consisting of 1 sign bit, 15 value > bits, and 8 padding bits, and CHAR_BIT==8. It therefore requires exactly 3 > bytes to store such an object, no matter which bytes contain the padding bits. > It might not have a single byte that consists entirely of padding bits - all > that matters is that there are 8 of them. We could also have an int type > consisting of 1 sign bit and 15 value bits. That would fit in exactly 2 bytes. > If you think there's any requirement imposed by the C standard that would be > violated by such an implementation, you'll have to identify it. My claim is > that there is no such requirement - and as such, it's impossible for me to cite > the locations where the C standard doesn't disallow it. Your claim that there > is such a requirement should, if it were valid, be trivial to prove, by citing > the requirement. So prove it. > Standards say what is allowed, not what is prohibited. If a standard tried to list everything that was prohibited it never could get finished. There would be no way to cover all of the basis. But your claim of a short having 1 sign bit, 15 value bits and 8 padding bits with CHAR_BIT=8 would require a padding byte - which is not allowed. OTOH, the standard DOES say you can have padding bytes in structs and unions. Note that says it is allowed for structs, but does not say it is allowed for ints or shorts. A huge difference. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-25 07:31 -0700 |
| Message-ID | <6821bfac-5b1e-4d0f-999f-b13369ce6324@googlegroups.com> |
| In reply to | #90976 |
On Monday, July 25, 2016 at 8:15:28 AM UTC-4, Jerry Stuckle wrote: > On 7/24/2016 10:38 PM, jameskuyper@verizon.net wrote: > > On Sunday, July 24, 2016 at 9:00:45 PM UTC-4, Jerry Stuckle wrote: > >> On 7/24/2016 6:28 PM, jameskuyper@verizon.net wrote: > > ... > >>> Yes, there's CHAR_BIT bits in a byte. Bits and bytes are, except > >>> for being different sizes, equally valid units for measuring > >>> memory. If you said something about kilometers, and I said > >>> something about meters, and what I said about meters was exactly > >>> correct, taking into the consideration the ratio of 1000 meters > >>> to one kilometer, would such a statement make you feel justified > >>> in asking me whether I knew the difference between meters and > >>> kilometers? > >>> There are CHAR_BIT padding bits in a padding byte. Which means > >>> that allowing an unlimited number of padding bits (as the > >>> standard does) means that entire padding bytes are also allowed. > >>> However, if the number of padding bits is not an integer multiple > >>> of CHAR_BIT, and if you were right about padding being excluded > >>> from the size, then sizeof could only correctly report the size > >>> by returning a factional number of bytes, which is not actually > >>> permitted. > > ... > >> You can't give a proper citation to support your claim that C allows for > >> padding BYTES. > > > > You're right - I can't. Because I don't claim that C allows for padding bytes. > > I claim that C says nothing to prohibit padding bytes. As such, my claim is one > > that's impossible to prove by citation - how could I point you at a place where > > the C standard fails to say something? Contrarywise, my claim would be trivial > > to disprove, if it were wrong. So tell me, where does the C standard say > > anything to disallow padding bytes? > > The C standard imposes only one requirement at the byte level on the > > representation of non-bit-field types: they must consist of an integer number > > of bytes (6.2.6.1p4). Every other requirement that the C standard imposes on > > the representation of integers is at the bit level. Those requirements are as > > follows (6.2.6.2): > > > > * 0 or 1 sign bit, depending upon whether the type is unsigned or signed, > > respectively. > > > > * A number of value bits that is not specified directly. However, minimum > > numbers of values bits for each integer type can be inferred from the minimum > > value for the corresponding *_MAX macro and (for signed types) the maximum > > value of the corresponding *_MIN macro, specified in 5.2.4.2.1. > > > > * A number of padding bits that might be 0, but is implicitly allowed to be > > greater than 1 (because of the use of the plural). There is no upper limit on > > the number of padding bits. Again, since I'm claiming that there's no such > > upper limit, it is inherently impossible for me to point at the place where the > > C standard fails to imposes such a limit. If I were wrong about that, it should > > be trivial to prove: cite the place where the C standard imposes an upper limit > > on the number of padding bits? > > > > The representations of integer types are otherwise completely unspecified. > > Unlike my other negative statements, this one I can actually provide a citation > > for: > > 6.2.6.1p1: "The representations of all types are unspecified except as stated > > in this subclause." I believe that "this subclause" refers to 6.2.6 rather than > > to 6.2.6.1; otherwise it contradicts the fact that 6.2.6.2 specifies a lot > > about the representation of integer types. I think this is a defect that needs > > to be corrected, by moving 6.2.6.1p1 to 6.2.6p1. However, that defect doesn't > > have any impact on my argument. > > > > In particular, the C standard doesn't impose any requirements upon the location > > of the sign, value, and padding bits of a given integer type. It therefore says > > nothing to prohibit having an entire byte consisting of nothing but padding > > bits. Now, I would consider it to be entirely reasonable to describe such a > > byte as a "padding byte" - but if for some reason you obstinately refuse to > > describe it that way, that's OK with me. Nothing I say below depends upon > > calling it a padding byte; the only thing my argument requires is that the > > number of padding bits is not prohibited from being larger than CHAR_BIT. > > > > An implementation could have a short int consisting of 1 sign bit, 15 value > > bits, and 8 padding bits, and CHAR_BIT==8. It therefore requires exactly 3 > > bytes to store such an object, no matter which bytes contain the padding bits. > > It might not have a single byte that consists entirely of padding bits - all > > that matters is that there are 8 of them. We could also have an int type > > consisting of 1 sign bit and 15 value bits. That would fit in exactly 2 bytes. > > If you think there's any requirement imposed by the C standard that would be > > violated by such an implementation, you'll have to identify it. My claim is > > that there is no such requirement - and as such, it's impossible for me to cite > > the locations where the C standard doesn't disallow it. Your claim that there > > is such a requirement should, if it were valid, be trivial to prove, by citing > > the requirement. So prove it. > > > > Standards say what is allowed, not what is prohibited. ... I'm not familiar with any other standard, but I would describe the C standard as consisting primarily of conditional requirements: requirements on the behavior of a program which are conditioned on the source code meeting other requirements. However, anything that meets a requirement is allowed, while anything that doesn't meet a requirement is prohibited, so it's not really an important distinction between "required", "allowed", or "prohibited". They all are different ways of expressing the same thing. > ... If a standard > tried to list everything that was prohibited it never could get > finished. There would be no way to cover all of the basis. The C standard addresses that with general rules that prohibit large categories of things that are prohibited, rather than trying to list each one explicitly. It also addresses that issue by FAILING to prohibit an incredibly large number of things, such as padding bytes in integers. > But your claim of a short having 1 sign bit, 15 value bits and 8 padding > bits with CHAR_BIT=8 would require a padding byte - which is not allowed. A, B, and C, following, are three independent responses to that argument. Any one of them would be sufficient to refute your argument. If you fail to address any one of the three responses, I'm entitled to assume that you're conceding that it's valid. A. As I see it, padding bytes are allowed by 6.2.6.1p1: "The representations of all types are unspecified except as stated in this subclause." In particular, it's unspecified whether the representation of a given type includes an entire byte consisting of padding bits, because nothing to the contrary is said in that subclause (Note: I'm fairly certain that the meaning of 6.2.6.1p1 was intended to refer to sub-clause 6.2.6, rather than sub-clause 6.2.6.1 - but this argument hold up either way). B. Just because it has 8 padding bits doesn't mean that it contains any padding bytes. One of the things not specified by 6.2.6 was the locations where the bits are stored. Therefore, 6.2.6.1p1 allows an implementation to have a type with 8 padding bits distributed as 3 in the first byte, 2 in the second byte, and 3 in the third byte. Which of those three bytes you would consider a padding byte? C. Your argument seems to be that you cannot have a byte consisting entirely of padding bits, because the standard never explicitly states that such a byte is allowed (my argument is that it's allowed because the standard says nothing to prohibit it). However, if your argument were valid, then the same would be true of value bits - nowhere does the standard explicitly allow the existence of a byte consisting entirely of value bits. In real life, where padding bits are extremely rare, bytes consisting entirely of value bits are extremely common. Yet, if your argument were valid, that would not be allowed. I'll offer you a trade: you tell me where the standard explicitly allows value bytes, and I'll show you where it explicitly allows padding bytes.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 11:59 -0400 |
| Message-ID | <nn5d0l$r6q$1@jstuckle.eternal-september.org> |
| In reply to | #90995 |
On 7/25/2016 10:31 AM, jameskuyper@verizon.net wrote: > On Monday, July 25, 2016 at 8:15:28 AM UTC-4, Jerry Stuckle wrote: >> On 7/24/2016 10:38 PM, jameskuyper@verizon.net wrote: >>> On Sunday, July 24, 2016 at 9:00:45 PM UTC-4, Jerry Stuckle wrote: >>>> On 7/24/2016 6:28 PM, jameskuyper@verizon.net wrote: >>> ... >>>>> Yes, there's CHAR_BIT bits in a byte. Bits and bytes are, except >>>>> for being different sizes, equally valid units for measuring >>>>> memory. If you said something about kilometers, and I said >>>>> something about meters, and what I said about meters was exactly >>>>> correct, taking into the consideration the ratio of 1000 meters >>>>> to one kilometer, would such a statement make you feel justified >>>>> in asking me whether I knew the difference between meters and >>>>> kilometers? >>>>> There are CHAR_BIT padding bits in a padding byte. Which means >>>>> that allowing an unlimited number of padding bits (as the >>>>> standard does) means that entire padding bytes are also allowed. >>>>> However, if the number of padding bits is not an integer multiple >>>>> of CHAR_BIT, and if you were right about padding being excluded >>>>> from the size, then sizeof could only correctly report the size >>>>> by returning a factional number of bytes, which is not actually >>>>> permitted. >>> ... >>>> You can't give a proper citation to support your claim that C allows for >>>> padding BYTES. >>> >>> You're right - I can't. Because I don't claim that C allows for padding bytes. >>> I claim that C says nothing to prohibit padding bytes. As such, my claim is one >>> that's impossible to prove by citation - how could I point you at a place where >>> the C standard fails to say something? Contrarywise, my claim would be trivial >>> to disprove, if it were wrong. So tell me, where does the C standard say >>> anything to disallow padding bytes? >>> The C standard imposes only one requirement at the byte level on the >>> representation of non-bit-field types: they must consist of an integer number >>> of bytes (6.2.6.1p4). Every other requirement that the C standard imposes on >>> the representation of integers is at the bit level. Those requirements are as >>> follows (6.2.6.2): >>> >>> * 0 or 1 sign bit, depending upon whether the type is unsigned or signed, >>> respectively. >>> >>> * A number of value bits that is not specified directly. However, minimum >>> numbers of values bits for each integer type can be inferred from the minimum >>> value for the corresponding *_MAX macro and (for signed types) the maximum >>> value of the corresponding *_MIN macro, specified in 5.2.4.2.1. >>> >>> * A number of padding bits that might be 0, but is implicitly allowed to be >>> greater than 1 (because of the use of the plural). There is no upper limit on >>> the number of padding bits. Again, since I'm claiming that there's no such >>> upper limit, it is inherently impossible for me to point at the place where the >>> C standard fails to imposes such a limit. If I were wrong about that, it should >>> be trivial to prove: cite the place where the C standard imposes an upper limit >>> on the number of padding bits? >>> >>> The representations of integer types are otherwise completely unspecified. >>> Unlike my other negative statements, this one I can actually provide a citation >>> for: >>> 6.2.6.1p1: "The representations of all types are unspecified except as stated >>> in this subclause." I believe that "this subclause" refers to 6.2.6 rather than >>> to 6.2.6.1; otherwise it contradicts the fact that 6.2.6.2 specifies a lot >>> about the representation of integer types. I think this is a defect that needs >>> to be corrected, by moving 6.2.6.1p1 to 6.2.6p1. However, that defect doesn't >>> have any impact on my argument. >>> >>> In particular, the C standard doesn't impose any requirements upon the location >>> of the sign, value, and padding bits of a given integer type. It therefore says >>> nothing to prohibit having an entire byte consisting of nothing but padding >>> bits. Now, I would consider it to be entirely reasonable to describe such a >>> byte as a "padding byte" - but if for some reason you obstinately refuse to >>> describe it that way, that's OK with me. Nothing I say below depends upon >>> calling it a padding byte; the only thing my argument requires is that the >>> number of padding bits is not prohibited from being larger than CHAR_BIT. >>> >>> An implementation could have a short int consisting of 1 sign bit, 15 value >>> bits, and 8 padding bits, and CHAR_BIT==8. It therefore requires exactly 3 >>> bytes to store such an object, no matter which bytes contain the padding bits. >>> It might not have a single byte that consists entirely of padding bits - all >>> that matters is that there are 8 of them. We could also have an int type >>> consisting of 1 sign bit and 15 value bits. That would fit in exactly 2 bytes. >>> If you think there's any requirement imposed by the C standard that would be >>> violated by such an implementation, you'll have to identify it. My claim is >>> that there is no such requirement - and as such, it's impossible for me to cite >>> the locations where the C standard doesn't disallow it. Your claim that there >>> is such a requirement should, if it were valid, be trivial to prove, by citing >>> the requirement. So prove it. >>> >> >> Standards say what is allowed, not what is prohibited. ... > > I'm not familiar with any other standard, but I would describe the C standard as consisting primarily of conditional requirements: requirements on the behavior of a program which are conditioned on the source code meeting other requirements. However, anything that meets a requirement is allowed, while anything that doesn't meet a requirement is prohibited, so it's not really an important distinction between "required", "allowed", or "prohibited". They all are different ways of expressing the same thing. > >> ... If a standard >> tried to list everything that was prohibited it never could get >> finished. There would be no way to cover all of the basis. > > The C standard addresses that with general rules that prohibit large categories of things that are prohibited, rather than trying to list each one explicitly. It also addresses that issue by FAILING to prohibit an incredibly large number of things, such as padding bytes in integers. > >> But your claim of a short having 1 sign bit, 15 value bits and 8 padding >> bits with CHAR_BIT=8 would require a padding byte - which is not allowed. > > A, B, and C, following, are three independent responses to that argument. Any one of them would be sufficient to refute your argument. If you fail to address any one of the three responses, I'm entitled to assume that you're conceding that it's valid. > > A. As I see it, padding bytes are allowed by 6.2.6.1p1: "The representations of all types are unspecified except as stated in this subclause." In particular, it's unspecified whether the representation of a given type includes an entire byte consisting of padding bits, because nothing to the contrary is said in that subclause (Note: I'm fairly certain that the meaning of 6.2.6.1p1 was intended to refer to sub-clause 6.2.6, rather than sub-clause 6.2.6.1 - but this argument hold up either way). > Yes, the representations of types are unspecified. But that does not say you can have padding bytes. The reason for padding bits is that the type may not take up the entire space allocated. Not all processors have 8 bit bytes. The PDP-11 had 43 bit bytes (36 data + 7 optionally for ecc). That does not mean a short had to be 43 bits long. It very well could have been 16 bits plus padding. And many DSP chips use 10 or 12 bits bytes. An integer on these may still be 32 bits (4 10-bit bytes including 8 bits of padding). > B. Just because it has 8 padding bits doesn't mean that it contains any padding bytes. One of the things not specified by 6.2.6 was the locations where the bits are stored. Therefore, 6.2.6.1p1 allows an implementation to have a type with 8 padding bits distributed as 3 in the first byte, 2 in the second byte, and 3 in the third byte. Which of those three bytes you would consider a padding byte? > I never said it would contain padding bytes. However, your example makes absolutely no sense at all - and is therefore complete BS. > C. Your argument seems to be that you cannot have a byte consisting entirely of padding bits, because the standard never explicitly states that such a byte is allowed (my argument is that it's allowed because the standard says nothing to prohibit it). However, if your argument were valid, then the same would be true of value bits - nowhere does the standard explicitly allow the existence of a byte consisting entirely of value bits. In real life, where padding bits are extremely rare, bytes consisting entirely of value bits are extremely common. Yet, if your argument were valid, that would not be allowed. I'll offer you a trade: you tell me where the standard explicitly allows value bytes, and I'll show you where it explicitly allows padding bytes. > The standard does not state it is legal to have padding bytes. The rest of your argument is more BS. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-25 10:31 -0700 |
| Message-ID | <50710ffb-d289-4345-8c42-778ea824df74@googlegroups.com> |
| In reply to | #91014 |
On Monday, July 25, 2016 at 11:59:25 AM UTC-4, Jerry Stuckle wrote: > On 7/25/2016 10:31 AM, jameskuyper@verizon.net wrote: > > On Monday, July 25, 2016 at 8:15:28 AM UTC-4, Jerry Stuckle wrote: ... > >> But your claim of a short having 1 sign bit, 15 value bits and 8 padding > >> bits with CHAR_BIT=8 would require a padding byte - which is not allowed. > > > > A, B, and C, following, are three independent responses to that argument. > > Any one of them would be sufficient to refute your argument. If you fail to > > address any one of the three responses, I'm entitled to assume that you're > > conceding that it's valid. > > > > A. As I see it, padding bytes are allowed by 6.2.6.1p1: "The > > representations of all types are unspecified except as stated in this > > subclause." In particular, it's unspecified whether the representation of a > > given type includes an entire byte consisting of padding bits, because > > nothing to the contrary is said in that subclause (Note: I'm fairly certain > > that the meaning of 6.2.6.1p1 was intended to refer to sub-clause 6.2.6, > > rather than sub-clause 6.2.6.1 - but this argument hold up either way). > > > > Yes, the representations of types are unspecified. But that does not > say you can have padding bytes. Yes, it does. Padding bytes are one aspect of how a type is represented, and are therefore allowed by 6.2.6.1p1 unless explicitly disallowed by some other specification made in "this subclause", and there is no contrary specification there. > The reason for padding bits is that the type may not take up the entire > space allocated. Not all processors have 8 bit bytes. The PDP-11 had > 43 bit bytes (36 data + 7 optionally for ecc). That does not mean a > short had to be 43 bits long. It very well could have been 16 bits plus > padding. And many DSP chips use 10 or 12 bits bytes. An integer on > these may still be 32 bits (4 10-bit bytes including 8 bits of padding). That's one possible reason for the standard to allow padding bits, but the standard simply allows padding bits, without imposing any requirements on them that would be violated by inserting padding bits for any other reason (or, for that matter, no reason at all). > > B. Just because it has 8 padding bits doesn't mean that it contains any > > padding bytes. One of the things not specified by 6.2.6 was the locations > > where the bits are stored. Therefore, 6.2.6.1p1 allows an implementation to > > have a type with 8 padding bits distributed as 3 in the first byte, 2 in > > the second byte, and 3 in the third byte. Which of those three bytes you > > would consider a padding byte? > > > > I never said it would contain padding bytes. Correct - you said "a short having 1 sign bit, 15 value bits and 8 padding bits with CHAR_BIT=8 would require a padding byte." So, where is this padding byte in the described format that is "required", but not "contained"? And what precisely does it mean for a type to require a padding byte without containing one? > > However, your example > > makes absolutely no sense at all - and is therefore complete BS. Your claim that it makes no sense probably is based upon some misconceptions about what makes sense. My best guess is that you think that padding bits have to be contiguous with each other. That's a detail about how a type is represented, a detail that section 6.2.6 imposes no requirements about. And, per 6.2.6.1p1, any details about how a type is represented that aren't specified in that sub-section are explicitly unspecified. > > C. Your argument seems to be that you cannot have a byte consisting > > entirely of padding bits, because the standard never explicitly states that > > such a byte is allowed (my argument is that it's allowed because the > > standard says nothing to prohibit it). However, if your argument were > > valid, then the same would be true of value bits - nowhere does the > > standard explicitly allow the existence of a byte consisting entirely of > > value bits. In real life, where padding bits are extremely rare, bytes > > consisting entirely of value bits are extremely common. Yet, if your > > argument were valid, that would not be allowed. I'll offer you a trade: you > > tell me where the standard explicitly allows value bytes, and I'll show you > > where it explicitly allows padding bytes. > The standard does not state it is legal to have padding bytes. Yes it does, in 6.2.6.1p1. I'll accept your refusal to cite a clause that explicitly allows value bytes, as an implicit concession that there is no such clause - even though I'm quite sure it would require torture to make you admit that this is the case.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-25 18:57 +0100 |
| Message-ID | <nn5ju1$lt5$1@dont-email.me> |
| In reply to | #91037 |
On 25/07/16 18:31, jameskuyper@verizon.net wrote: > On Monday, July 25, 2016 at 11:59:25 AM UTC-4, Jerry Stuckle wrote: >> However, your example >> makes absolutely no sense at all - and is therefore complete BS. > > Your claim that it makes no sense probably is based upon some > misconceptions about what makes sense. My best guess is that > you think that padding bits have to be contiguous with each > other. That's a detail about how a type is represented, a > detail that section 6.2.6 imposes no requirements about. Well, 6.2.6.1(2) does impose one requirement - that of documentation; "objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined", which when taken with the definition of IDB in 3.4.1(1): "unspecified behavior where each implementation documents how the choice is made", requires that the implementation must document the number, order, and encoding of objects (except where the Standard imposes the choice, such as with sizeof(char), for example). -- 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-25 15:04 -0400 |
| Message-ID | <nn5nrg$5a5$1@jstuckle.eternal-september.org> |
| In reply to | #91037 |
On 7/25/2016 1:31 PM, jameskuyper@verizon.net wrote: > On Monday, July 25, 2016 at 11:59:25 AM UTC-4, Jerry Stuckle wrote: >> On 7/25/2016 10:31 AM, jameskuyper@verizon.net wrote: >>> On Monday, July 25, 2016 at 8:15:28 AM UTC-4, Jerry Stuckle wrote: > ... >>>> But your claim of a short having 1 sign bit, 15 value bits and 8 padding >>>> bits with CHAR_BIT=8 would require a padding byte - which is not allowed. >>> >>> A, B, and C, following, are three independent responses to that argument. >>> Any one of them would be sufficient to refute your argument. If you fail to >>> address any one of the three responses, I'm entitled to assume that you're >>> conceding that it's valid. >>> >>> A. As I see it, padding bytes are allowed by 6.2.6.1p1: "The >>> representations of all types are unspecified except as stated in this >>> subclause." In particular, it's unspecified whether the representation of a >>> given type includes an entire byte consisting of padding bits, because >>> nothing to the contrary is said in that subclause (Note: I'm fairly certain >>> that the meaning of 6.2.6.1p1 was intended to refer to sub-clause 6.2.6, >>> rather than sub-clause 6.2.6.1 - but this argument hold up either way). >>> >> >> Yes, the representations of types are unspecified. But that does not >> say you can have padding bytes. > > Yes, it does. Padding bytes are one aspect of how a type is represented, and are therefore allowed by 6.2.6.1p1 unless explicitly disallowed by some other specification made in "this subclause", and there is no contrary specification there. > Keep thinking that. There is nothing in the standard which agrees with you. And in fact, padding BITS are specifically allowed. Padding BYTES are specifically allowed - for structs and unions. But not ints. >> The reason for padding bits is that the type may not take up the entire >> space allocated. Not all processors have 8 bit bytes. The PDP-11 had >> 43 bit bytes (36 data + 7 optionally for ecc). That does not mean a >> short had to be 43 bits long. It very well could have been 16 bits plus >> padding. And many DSP chips use 10 or 12 bits bytes. An integer on >> these may still be 32 bits (4 10-bit bytes including 8 bits of padding). > > That's one possible reason for the standard to allow padding bits, but the standard simply allows padding bits, without imposing any requirements on them that would be violated by inserting padding bits for any other reason (or, for that matter, no reason at all). > Yes, but it does not allow for padding bytes. >>> B. Just because it has 8 padding bits doesn't mean that it contains any >>> padding bytes. One of the things not specified by 6.2.6 was the locations >>> where the bits are stored. Therefore, 6.2.6.1p1 allows an implementation to >>> have a type with 8 padding bits distributed as 3 in the first byte, 2 in >>> the second byte, and 3 in the third byte. Which of those three bytes you >>> would consider a padding byte? >>> >> >> I never said it would contain padding bytes. > > Correct - you said "a short having 1 sign bit, 15 value bits and 8 padding bits with CHAR_BIT=8 would require a padding byte." > > So, where is this padding byte in the described format that is "required", but not "contained"? And what precisely does it mean for a type to require a padding byte without containing one? > I never said it could have 1 sign bit, 15 value bits and 8 padding bits with CHAR_BIT=8. Those are YOUR words. >>> However, your example >>> makes absolutely no sense at all - and is therefore complete BS. > > Your claim that it makes no sense probably is based upon some misconceptions about what makes sense. My best guess is that you think that padding bits have to be contiguous with each other. That's a detail about how a type is represented, a detail that section 6.2.6 imposes no requirements about. And, per 6.2.6.1p1, any details about how a type is represented that aren't specified in that sub-section are explicitly unspecified. > Your claim is absurd. And the fact you have to try such an absurd claim shows you have no intelligent response. >>> C. Your argument seems to be that you cannot have a byte consisting >>> entirely of padding bits, because the standard never explicitly states that >>> such a byte is allowed (my argument is that it's allowed because the >>> standard says nothing to prohibit it). However, if your argument were >>> valid, then the same would be true of value bits - nowhere does the >>> standard explicitly allow the existence of a byte consisting entirely of >>> value bits. In real life, where padding bits are extremely rare, bytes >>> consisting entirely of value bits are extremely common. Yet, if your >>> argument were valid, that would not be allowed. I'll offer you a trade: you >>> tell me where the standard explicitly allows value bytes, and I'll show you >>> where it explicitly allows padding bytes. > >> The standard does not state it is legal to have padding bytes. > > Yes it does, in 6.2.6.1p1. I'll accept your refusal to cite a clause that explicitly allows value bytes, as an implicit concession that there is no such clause - even though I'm quite sure it would require torture to make you admit that this is the case. > And exactly where does it say you can have padding BYTES for an int or short? it does for structs and unions, for instance. But only bits for ints and short. Your extension of the standard is as absurd as your example. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-24 19:14 -0700 |
| Message-ID | <lna8h6ea6i.fsf@kst-u.example.com> |
| In reply to | #90922 |
jameskuyper@verizon.net writes:
[...]
> There are CHAR_BIT padding bits in a padding byte.
[...]
As I just mentioned in response to Richard Heathfield, the standard
(almost) consistently uses the the term "padding bits" to refer to
bits within the representation of an integer that do not contribute
to its value, and "padding bytes" to refer to bytes within the
representation of a structure or union that are not part of the
representation of any member.
A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits.
The collection, though it happens to be the same size as a byte,
might not even be addressible, which means it would not meet the
standard's definition of a "byte".
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-24 22:49 -0400 |
| Message-ID | <nn3un0$k81$1@dont-email.me> |
| In reply to | #90946 |
On 07/24/2016 10:14 PM, Keith Thompson wrote: > jameskuyper@verizon.net writes: > [...] >> There are CHAR_BIT padding bits in a padding byte. > [...] > > As I just mentioned in response to Richard Heathfield, the standard > (almost) consistently uses the the term "padding bits" to refer to > bits within the representation of an integer that do not contribute > to its value, and "padding bytes" to refer to bytes within the > representation of a structure or union that are not part of the > representation of any member. > > A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits. > The collection, though it happens to be the same size as a byte, > might not even be addressible, which means it would not meet the > standard's definition of a "byte". The standard never provides it's own definition of "padding bit" or "padding byte", so we're left to rely upon the rules of ordinary English usage. As far as I'm concerned, it's entirely reasonable to refer to an entire byte consisting of padding bits as a padding byte. The standard never says anything about padding bytes that is inconsistent with that belief. More importantly, the point we're trying to convince Jerry about also does not depend upon whether or not "padding byte" is an appropriate term to use for such a byte. All that matters is the fact that the standard imposes no upper limit on the number of padding bits. Whether or not the type has any bytes that consist entirely of padding bits is irrelevant to that argument.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-24 21:12 -0700 |
| Message-ID | <ln60rue4q6.fsf@kst-u.example.com> |
| In reply to | #90955 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 07/24/2016 10:14 PM, Keith Thompson wrote:
>> jameskuyper@verizon.net writes:
>> [...]
>>> There are CHAR_BIT padding bits in a padding byte.
>> [...]
>>
>> As I just mentioned in response to Richard Heathfield, the standard
>> (almost) consistently uses the the term "padding bits" to refer to
>> bits within the representation of an integer that do not contribute
>> to its value, and "padding bytes" to refer to bytes within the
>> representation of a structure or union that are not part of the
>> representation of any member.
>>
>> A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits.
>> The collection, though it happens to be the same size as a byte,
>> might not even be addressible, which means it would not meet the
>> standard's definition of a "byte".
>
> The standard never provides it's own definition of "padding bit" or
> "padding byte", so we're left to rely upon the rules of ordinary English
> usage. As far as I'm concerned, it's entirely reasonable to refer to an
> entire byte consisting of padding bits as a padding byte. The standard
> never says anything about padding bytes that is inconsistent with that
> belief.
Only if that byte is addressible. The standard's definition of a
"byte" is
addressable unit of data storage large enough to hold any member of
the basic character set of the execution environment
So (assuming CHAR_BIT==8), if 8 padding bits happen to occupy an
addressible byte of memory, then we might call them a "padding byte",
but 8 bits straddling a byte boundary are not strictly speaking a
"byte".
Not that it matters, of course.
> More importantly, the point we're trying to convince Jerry about also
> does not depend upon whether or not "padding byte" is an appropriate
> term to use for such a byte. All that matters is the fact that the
> standard imposes no upper limit on the number of padding bits. Whether
> or not the type has any bytes that consist entirely of padding bits is
> irrelevant to that argument.
Right. I don't read Jerry's posts (he's buried so deeply in my
killfile/scorefile I never even see them unless someone else quotes
him), but certainly the question of whether padding bits can gather
into bytes is irrelevant to the current discussion. Clearly the
standard places no upper bound on the number of padding bits a
(non-char) integer type can have, and clearly the standard permits
sizeof (short) > sizeof (int).
A conforming implementation could have:
CHAR_BIT == 8
sizeof (unsigned short) == 4
USHRT_MAX == 65535
// implying that unsigned short has 16 value bits and 16 padding bits
sizeof (unsigned int) == 2
UINT_MAX == 65535
// implying that unsigned int has 16 value bits and no padding bits
(I've omitted signed short and signed int. I don't think they're
necessary to make the point.)
Those 16 padding bits in type unsigned short may or may not occupy
2 bytes. The standard doesn't call them "padding bytes" because
it doesn't matter whether they do or not.
I can't think of a good reason that a real implementation would do
that, but nothing in the standard forbids it.
--
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]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web