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 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 22:12 -0400 |
| Message-ID | <nn3si6$ehj$1@jstuckle.eternal-september.org> |
| In reply to | #90934 |
On 7/24/2016 9:11 PM, Richard Heathfield wrote: > On 25/07/16 01:57, Jerry Stuckle wrote: >> On 7/24/2016 6:44 PM, Richard Heathfield wrote: >>> On 24/07/16 23:19, Jerry Stuckle wrote: >>>> On 7/24/2016 5:58 PM, Richard Heathfield wrote: >>>>> On 24/07/16 22:27, Jerry Stuckle wrote: >>>>>> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>>>>>> On 24/07/16 16:06, Jerry Stuckle wrote: > <snip> >>>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>>> >>>>>>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed >>>>>>> INT_MAX >>>>>>> (see 6.2.5(8), which says the same thing in different words). >>>>>>> >>>>>>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>>>>>> (with no padding) and short to be 24 bits (with 8 bits of padding). > <snip> >>> >>> The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed >>> (6.2.6.2(2)) integer types. ISO could easily have defined the >>> relationship of integer types by size including padding, but it chose >>> instead to define that relationship in terms of ranks and value ranges. >>> >> >> It also does not say you can pad BYTES. > > The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed > (6.2.6.2(2)) integer types. ISO could easily have defined the > relationship of integer types by size including padding, but it chose > instead to define that relationship in terms of ranks and value ranges. > > Which bit of this don't you understand? > Where does it say you can pad BYTES? >>> Now, your claim is that sizeof(short) cannot exceed sizeof(int) - that >>> it is *not permitted*. I have shown why I think it /is/ permitted. What >>> you have not done is shown why you think it isn't. >> >> No, the only thing you have shown is an incorrect interpretation. > > I presume you mean it's an interpretation that disagrees with yours. But > no, it's not incorrect. > No, it's an interpretation which does not agree with the STANDARDS. >>>>> That is, it doesn't matter either way. It's perfectly possible and >>>>> legal >>>>> for sizeof(short) to exceed sizeof(int). What is /not/ legal is for >>>>> SHRT_MAX to exceed INT_MAX. >>>>> >>>> >>>> Again, citation? Where does it say sizeof(short) can exceed >>>> sizeof(int)? >>> >>> The Standard allows padding bits in unsigned (6.2.6.2(1)) and signed >>> (6.2.6.2(2)) integer types. ISO could easily have defined the >>> relationship of integer types by size including padding, but it chose >>> instead to define that relationship in terms of ranks and value ranges. >>> >> >> And where does it say you can pad BYTES? > > It's a silly question. Implementations may use as many padding bits as > they like in integer types, and they are under no obligation to ensure > that that padding results in the integer sizes obeying any kind of > relational ordering. The /range/ of short must not exceed the /range/ of > int, but there's no such limitation on /size/. > > More to the point, where does it say sizeof(short) must not exceed > sizeof(int)? That was your claim, that was the claim I was gainsaying, > and you have yet to provide even a shred of evidence to support it. > > <nonsense snipped> > Not a silly question at all. Nowhere in the standard does it say you can pad BYTES. That's something YOU made up. Once you agree that nowhere in the standard does it say you can pad BYTES, then you've got the answer to your question. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-24 17:28 -0600 |
| Message-ID | <1btwfehaze.fsf@pfeifferfamily.net> |
| In reply to | #90915 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 7/24/2016 11:32 AM, Richard Heathfield wrote: >> On 24/07/16 16:06, Jerry Stuckle wrote: >> >>> And no, sizeof (short) > sizeof (int) is not permitted. >> >> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >> (see 6.2.5(8), which says the same thing in different words). >> >> It is, for example, legal (albeit rather daft) for int to be 16 bits >> (with no padding) and short to be 24 bits (with 8 bits of padding). >> > > No, these paragraphs refer to padding BITS, not bytes. Is there anything forbidding padding by a number of bits divisible by CHAR_BIT? Richard's example doesn't mention bytes at all.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-25 00:37 +0100 |
| Message-ID | <nn3jg5$s3k$1@dont-email.me> |
| In reply to | #90926 |
On 25/07/16 00:28, Joe Pfeiffer wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>> On 24/07/16 16:06, Jerry Stuckle wrote: >>> >>>> And no, sizeof (short) > sizeof (int) is not permitted. >>> >>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >>> (see 6.2.5(8), which says the same thing in different words). >>> >>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>> (with no padding) and short to be 24 bits (with 8 bits of padding). >>> >> >> No, these paragraphs refer to padding BITS, not bytes. > > Is there anything forbidding padding by a number of bits divisible by > CHAR_BIT? No. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-24 16:59 -0700 |
| Message-ID | <24edcb3c-25f2-4ee3-8839-c0830b280a79@googlegroups.com> |
| In reply to | #90926 |
On Monday, July 25, 2016 at 12:28:45 AM UTC+1, Joe Pfeiffer wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > > > On 7/24/2016 11:32 AM, Richard Heathfield wrote: > >> On 24/07/16 16:06, Jerry Stuckle wrote: > >> > >>> And no, sizeof (short) > sizeof (int) is not permitted. > >> > >> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX > >> (see 6.2.5(8), which says the same thing in different words). > >> > >> It is, for example, legal (albeit rather daft) for int to be 16 bits > >> (with no padding) and short to be 24 bits (with 8 bits of padding). > >> > > > > No, these paragraphs refer to padding BITS, not bytes. > > Is there anything forbidding padding by a number of bits divisible by > CHAR_BIT? Richard's example doesn't mention bytes at all. > No. But a bit is a unit of memory, a byte is a unit of data. So 8 padding bits wouldn't make up a byte, unless you were able to insert some data into it, which is sometimes the case but more often disallowed.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-24 19:32 -0600 |
| Message-ID | <1bpoq2h58o.fsf@pfeifferfamily.net> |
| In reply to | #90928 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, July 25, 2016 at 12:28:45 AM UTC+1, Joe Pfeiffer wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >> > On 7/24/2016 11:32 AM, Richard Heathfield wrote: >> >> On 24/07/16 16:06, Jerry Stuckle wrote: >> >> >> >>> And no, sizeof (short) > sizeof (int) is not permitted. >> >> >> >> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >> >> (see 6.2.5(8), which says the same thing in different words). >> >> >> >> It is, for example, legal (albeit rather daft) for int to be 16 bits >> >> (with no padding) and short to be 24 bits (with 8 bits of padding). >> >> >> > >> > No, these paragraphs refer to padding BITS, not bytes. >> >> Is there anything forbidding padding by a number of bits divisible by >> CHAR_BIT? Richard's example doesn't mention bytes at all. >> > No. But a bit is a unit of memory, a byte is a unit of data. > So 8 padding bits wouldn't make up a byte, unless you were able to > insert some data into it, which is sometimes the case but more often > disallowed. Yes, but Jerry appears to be claiming that Richard's example is invalid because the standard refers to padding by bits and not bytes. Richard didn't pad by bytes; he padded by a number of bits that is coincidentally a byte on most systems. I'm asking "what's wrong with that?", and getting the (expected) answer so far of "nothing".
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-25 02:35 +0100 |
| Message-ID | <nn3qdg$b7c$2@dont-email.me> |
| In reply to | #90938 |
On 25/07/16 02:32, Joe Pfeiffer wrote: <snip> > > Yes, but Jerry appears to be claiming that Richard's example is invalid > because the standard refers to padding by bits and not bytes. Richard > didn't pad by bytes; he padded by a number of bits that is > coincidentally a byte on most systems. I'm asking "what's wrong with > that?", and getting the (expected) answer so far of "nothing". I have since provided other worked examples that pad by numbers of bits that are not multiples of CHAR_BIT, all of which would be legal according to the C Standard (albeit rather silly). I can think of no good reason why an implementation /would/ make sizeof(short) > sizeof(int), but there's no rule forbidding it. Mr Stuckle appears to believe that the maximum number of padding bits in an integer is CHAR_BIT - 1, but he has not yet provided a citation to back up this belief. (Nor can he.) -- 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:14 -0400 |
| Message-ID | <nn3sl5$ehj$3@jstuckle.eternal-september.org> |
| In reply to | #90940 |
On 7/24/2016 9:35 PM, Richard Heathfield wrote: > On 25/07/16 02:32, Joe Pfeiffer wrote: > <snip> >> >> Yes, but Jerry appears to be claiming that Richard's example is invalid >> because the standard refers to padding by bits and not bytes. Richard >> didn't pad by bytes; he padded by a number of bits that is >> coincidentally a byte on most systems. I'm asking "what's wrong with >> that?", and getting the (expected) answer so far of "nothing". > > I have since provided other worked examples that pad by numbers of bits > that are not multiples of CHAR_BIT, all of which would be legal > according to the C Standard (albeit rather silly). I can think of no > good reason why an implementation /would/ make sizeof(short) > > sizeof(int), but there's no rule forbidding it. > > Mr Stuckle appears to believe that the maximum number of padding bits in > an integer is CHAR_BIT - 1, but he has not yet provided a citation to > back up this belief. (Nor can he.) > I never said anything of the sort. All I said was the standard does not say you can pad BYTES. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 22:13 -0400 |
| Message-ID | <nn3sk2$ehj$2@jstuckle.eternal-september.org> |
| In reply to | #90938 |
On 7/24/2016 9:32 PM, Joe Pfeiffer wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Monday, July 25, 2016 at 12:28:45 AM UTC+1, Joe Pfeiffer wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>>>> On 24/07/16 16:06, Jerry Stuckle wrote: >>>>> >>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>> >>>>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >>>>> (see 6.2.5(8), which says the same thing in different words). >>>>> >>>>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>>>> (with no padding) and short to be 24 bits (with 8 bits of padding). >>>>> >>>> >>>> No, these paragraphs refer to padding BITS, not bytes. >>> >>> Is there anything forbidding padding by a number of bits divisible by >>> CHAR_BIT? Richard's example doesn't mention bytes at all. >>> >> No. But a bit is a unit of memory, a byte is a unit of data. >> So 8 padding bits wouldn't make up a byte, unless you were able to >> insert some data into it, which is sometimes the case but more often >> disallowed. > > Yes, but Jerry appears to be claiming that Richard's example is invalid > because the standard refers to padding by bits and not bytes. Richard > didn't pad by bytes; he padded by a number of bits that is > coincidentally a byte on most systems. I'm asking "what's wrong with > that?", and getting the (expected) answer so far of "nothing". > No, Richard is saying you can pad bits which will also add bytes to the type. But nowhere in the standard does it say that is legitimate. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-24 21:54 -0600 |
| Message-ID | <1bh9begyo0.fsf@pfeifferfamily.net> |
| In reply to | #90944 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 7/24/2016 9:32 PM, Joe Pfeiffer wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Monday, July 25, 2016 at 12:28:45 AM UTC+1, Joe Pfeiffer wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>>>>> On 24/07/16 16:06, Jerry Stuckle wrote: >>>>>> >>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>> >>>>>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >>>>>> (see 6.2.5(8), which says the same thing in different words). >>>>>> >>>>>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>>>>> (with no padding) and short to be 24 bits (with 8 bits of padding). >>>>>> >>>>> >>>>> No, these paragraphs refer to padding BITS, not bytes. >>>> >>>> Is there anything forbidding padding by a number of bits divisible by >>>> CHAR_BIT? Richard's example doesn't mention bytes at all. >>>> >>> No. But a bit is a unit of memory, a byte is a unit of data. >>> So 8 padding bits wouldn't make up a byte, unless you were able to >>> insert some data into it, which is sometimes the case but more often >>> disallowed. >> >> Yes, but Jerry appears to be claiming that Richard's example is invalid >> because the standard refers to padding by bits and not bytes. Richard >> didn't pad by bytes; he padded by a number of bits that is >> coincidentally a byte on most systems. I'm asking "what's wrong with >> that?", and getting the (expected) answer so far of "nothing". >> > > No, Richard is saying you can pad bits which will also add bytes to the > type. But nowhere in the standard does it say that is legitimate. You're claiming it isn't legitimate, and I can't find any limit to how many bits you can pad with. As I've asked you before, where does it say you can't add more than CHAR_BIT-1 bits of padding?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 08:08 -0400 |
| Message-ID | <nn4vg7$aql$1@jstuckle.eternal-september.org> |
| In reply to | #90957 |
On 7/24/2016 11:54 PM, Joe Pfeiffer wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 7/24/2016 9:32 PM, Joe Pfeiffer wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> >>>> On Monday, July 25, 2016 at 12:28:45 AM UTC+1, Joe Pfeiffer wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>>>>>> On 24/07/16 16:06, Jerry Stuckle wrote: >>>>>>> >>>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>>> >>>>>>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >>>>>>> (see 6.2.5(8), which says the same thing in different words). >>>>>>> >>>>>>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>>>>>> (with no padding) and short to be 24 bits (with 8 bits of padding). >>>>>>> >>>>>> >>>>>> No, these paragraphs refer to padding BITS, not bytes. >>>>> >>>>> Is there anything forbidding padding by a number of bits divisible by >>>>> CHAR_BIT? Richard's example doesn't mention bytes at all. >>>>> >>>> No. But a bit is a unit of memory, a byte is a unit of data. >>>> So 8 padding bits wouldn't make up a byte, unless you were able to >>>> insert some data into it, which is sometimes the case but more often >>>> disallowed. >>> >>> Yes, but Jerry appears to be claiming that Richard's example is invalid >>> because the standard refers to padding by bits and not bytes. Richard >>> didn't pad by bytes; he padded by a number of bits that is >>> coincidentally a byte on most systems. I'm asking "what's wrong with >>> that?", and getting the (expected) answer so far of "nothing". >>> >> >> No, Richard is saying you can pad bits which will also add bytes to the >> type. But nowhere in the standard does it say that is legitimate. > > You're claiming it isn't legitimate, and I can't find any limit to how > many bits you can pad with. As I've asked you before, where does it say > you can't add more than CHAR_BIT-1 bits of padding? > Where does it say you can pad BYTES? -- ================== 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 13:09 +0100 |
| Message-ID | <nn4vih$big$2@dont-email.me> |
| In reply to | #90971 |
On 25/07/16 13:08, Jerry Stuckle wrote: > On 7/24/2016 11:54 PM, Joe Pfeiffer wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 7/24/2016 9:32 PM, Joe Pfeiffer wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> >>>>> On Monday, July 25, 2016 at 12:28:45 AM UTC+1, Joe Pfeiffer wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>> >>>>>>> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>>>>>>> On 24/07/16 16:06, Jerry Stuckle wrote: >>>>>>>> >>>>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>>>> >>>>>>>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed INT_MAX >>>>>>>> (see 6.2.5(8), which says the same thing in different words). >>>>>>>> >>>>>>>> It is, for example, legal (albeit rather daft) for int to be 16 bits >>>>>>>> (with no padding) and short to be 24 bits (with 8 bits of padding). >>>>>>>> >>>>>>> >>>>>>> No, these paragraphs refer to padding BITS, not bytes. >>>>>> >>>>>> Is there anything forbidding padding by a number of bits divisible by >>>>>> CHAR_BIT? Richard's example doesn't mention bytes at all. >>>>>> >>>>> No. But a bit is a unit of memory, a byte is a unit of data. >>>>> So 8 padding bits wouldn't make up a byte, unless you were able to >>>>> insert some data into it, which is sometimes the case but more often >>>>> disallowed. >>>> >>>> Yes, but Jerry appears to be claiming that Richard's example is invalid >>>> because the standard refers to padding by bits and not bytes. Richard >>>> didn't pad by bytes; he padded by a number of bits that is >>>> coincidentally a byte on most systems. I'm asking "what's wrong with >>>> that?", and getting the (expected) answer so far of "nothing". >>>> >>> >>> No, Richard is saying you can pad bits which will also add bytes to the >>> type. But nowhere in the standard does it say that is legitimate. >> >> You're claiming it isn't legitimate, and I can't find any limit to how >> many bits you can pad with. As I've asked you before, where does it say >> you can't add more than CHAR_BIT-1 bits of padding? >> > > Where does it say you can pad BYTES? When you have discovered the answer to his question, you will automatically learn the answer to your question. -- 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 08:22 -0400 |
| Message-ID | <nn508t$d9r$4@jstuckle.eternal-september.org> |
| In reply to | #90973 |
On 7/25/2016 8:09 AM, Richard Heathfield wrote: > On 25/07/16 13:08, Jerry Stuckle wrote: >> On 7/24/2016 11:54 PM, Joe Pfeiffer wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 7/24/2016 9:32 PM, Joe Pfeiffer wrote: >>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>>> >>>>>> On Monday, July 25, 2016 at 12:28:45 AM UTC+1, Joe Pfeiffer wrote: >>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>>> >>>>>>>> On 7/24/2016 11:32 AM, Richard Heathfield wrote: >>>>>>>>> On 24/07/16 16:06, Jerry Stuckle wrote: >>>>>>>>> >>>>>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>>>>> >>>>>>>>> It's not forbidden. What is forbidden is for SHRT_MAX to exceed >>>>>>>>> INT_MAX >>>>>>>>> (see 6.2.5(8), which says the same thing in different words). >>>>>>>>> >>>>>>>>> It is, for example, legal (albeit rather daft) for int to be 16 >>>>>>>>> bits >>>>>>>>> (with no padding) and short to be 24 bits (with 8 bits of >>>>>>>>> padding). >>>>>>>>> >>>>>>>> >>>>>>>> No, these paragraphs refer to padding BITS, not bytes. >>>>>>> >>>>>>> Is there anything forbidding padding by a number of bits >>>>>>> divisible by >>>>>>> CHAR_BIT? Richard's example doesn't mention bytes at all. >>>>>>> >>>>>> No. But a bit is a unit of memory, a byte is a unit of data. >>>>>> So 8 padding bits wouldn't make up a byte, unless you were able to >>>>>> insert some data into it, which is sometimes the case but more often >>>>>> disallowed. >>>>> >>>>> Yes, but Jerry appears to be claiming that Richard's example is >>>>> invalid >>>>> because the standard refers to padding by bits and not bytes. Richard >>>>> didn't pad by bytes; he padded by a number of bits that is >>>>> coincidentally a byte on most systems. I'm asking "what's wrong with >>>>> that?", and getting the (expected) answer so far of "nothing". >>>>> >>>> >>>> No, Richard is saying you can pad bits which will also add bytes to the >>>> type. But nowhere in the standard does it say that is legitimate. >>> >>> You're claiming it isn't legitimate, and I can't find any limit to how >>> many bits you can pad with. As I've asked you before, where does it say >>> you can't add more than CHAR_BIT-1 bits of padding? >>> >> >> Where does it say you can pad BYTES? > > When you have discovered the answer to his question, you will > automatically learn the answer to your question. > You claimed the standard allows it. Show where. And don't go by the claim that the standard allows padding bits. That is not the same as padding bytes. Standards state what is allowed. There is no way for a standard to state everything that is disallowed. And no where does the standard state padding bytes are allowed. -- ================== 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 13:50 +0100 |
| Message-ID | <nn51uo$jt2$1@dont-email.me> |
| In reply to | #90983 |
On 25/07/16 13:22, Jerry Stuckle wrote: > On 7/25/2016 8:09 AM, Richard Heathfield wrote: >> On 25/07/16 13:08, Jerry Stuckle wrote: >>> On 7/24/2016 11:54 PM, Joe Pfeiffer wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> >>>>> No, Richard is saying you can pad bits which will also add bytes to the >>>>> type. But nowhere in the standard does it say that is legitimate. >>>> >>>> You're claiming it isn't legitimate, and I can't find any limit to how >>>> many bits you can pad with. As I've asked you before, where does it say >>>> you can't add more than CHAR_BIT-1 bits of padding? >>>> >>> >>> Where does it say you can pad BYTES? >> >> When you have discovered the answer to his question, you will >> automatically learn the answer to your question. >> > > You claimed the standard allows it. Show where. I have done so already. > And don't go by the > claim that the standard allows padding bits. "Tell me what 3 + 4 is, and let's not have any of that nonsense about it being 7." The right answer is the right answer, even when you don't like it. > That is not the same as padding bytes. The Standard allows implementations to add multiple padding bits, and imposes no limit on how many may be added. > Standards state what is allowed. There is no way for a standard to > state everything that is disallowed. And no where does the standard > state padding bytes are allowed. The Standard very frequently states what is not allowed. For example, see 6.2.6.2(2), which says that "signed char shall not have any padding bits". But let's see what the Standard explicitly allows, shall we? 6.2.6.1(2) says: "Except for bit-fields, 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." Implementations are, therefore, entitled to construct objects using more than one byte, and they are allowed to define the number of bytes, the order of the bytes, and the encoding of the bytes. An implementation may thus choose (for whatever daft reason) to define that a short int will consist of three bytes, and an int will consist of two bytes, /as long as/ it observes any explicit constraints that the Standard imposes. The implementation may also define the encoding of the bytes. It is thus free to choose /which/ bit of an int will be the sign bit, /which/ bits of the int (if any) will be padding, and /which/ bits of the int will be value bits - so long as it: * provides enough value bits to meet the minimum requirements for the type; * provides a sign bit if the type is signed; * maintains the value range relationships imposed upon it by the ranking schema. The implementation is even free to mix everything up! Using S as the sign bit, P as a padding bit, and V as a value bit, the Standard permits (by the above wording) an implementation to construct ints like this: PPPVVVVPPPVVVVSVVVVPPPVVVVPPP with twelve padding bits, sixteen value bits, one sign bit, making 29 bits altogether - on such a system, CHAR_BIT would have to be 29, because an int must be at least one byte, so CHAR_BIT can't exceed the int's width, and all bytes must be the same size, but 29 is prime, so there is no way to subdivide it into smaller bytes. Of course, no sane implementation would do this - but the Standard permits it anyway. The Standard gives just as much freedom for short, and the following would be a perfectly legal construction of a short: PPPPPPPVVPPPPPPPVVPPPPPPPVVVSVVVPPPPPPPVVPPPPPPPVVVPPPPPPP 15 value bits, one sign bit, and 42 padding bits, making 58 altogether. The Standard clearly permits both of these encodings. The only question is whether the Standard permits them /in the same implementation/, and there is only one reason why it might not - SHRT_MAX must not exceed INT_MAX. But these encodings give an INT_MAX of 65535 and a SHRT_MAX of 32767, so all is well. Conclusion: the Standard leaves the encoding of integer types up to the implementation, so long as some basic rules are observed (minimum value ranges, signedness, and ranking). There is therefore no /requirement/ that sizeof(short) must be <= sizeof(int). It usually will be, but it's not a /requirement/. -- 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 11:48 -0400 |
| Message-ID | <nn5ccp$p3t$1@jstuckle.eternal-september.org> |
| In reply to | #90988 |
On 7/25/2016 8:50 AM, Richard Heathfield wrote: > On 25/07/16 13:22, Jerry Stuckle wrote: >> On 7/25/2016 8:09 AM, Richard Heathfield wrote: >>> On 25/07/16 13:08, Jerry Stuckle wrote: >>>> On 7/24/2016 11:54 PM, Joe Pfeiffer wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >>>>>> No, Richard is saying you can pad bits which will also add bytes >>>>>> to the >>>>>> type. But nowhere in the standard does it say that is legitimate. >>>>> >>>>> You're claiming it isn't legitimate, and I can't find any limit to how >>>>> many bits you can pad with. As I've asked you before, where does >>>>> it say >>>>> you can't add more than CHAR_BIT-1 bits of padding? >>>>> >>>> >>>> Where does it say you can pad BYTES? >>> >>> When you have discovered the answer to his question, you will >>> automatically learn the answer to your question. >>> >> >> You claimed the standard allows it. Show where. > > I have done so already. > No, you haven't. You've only shown were padding BITS are allowed. >> And don't go by the >> claim that the standard allows padding bits. > > "Tell me what 3 + 4 is, and let's not have any of that nonsense about it > being 7." The right answer is the right answer, even when you don't like > it. > You've only shown where padding BITS are allowed. >> That is not the same as padding bytes. > > The Standard allows implementations to add multiple padding bits, and > imposes no limit on how many may be added. > It says nothing about allowing padding BYTES. >> Standards state what is allowed. There is no way for a standard to >> state everything that is disallowed. And no where does the standard >> state padding bytes are allowed. > > The Standard very frequently states what is not allowed. For example, > see 6.2.6.2(2), which says that "signed char shall not have any padding > bits". > > But let's see what the Standard explicitly allows, shall we? > > 6.2.6.1(2) says: "Except for bit-fields, 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." > > Implementations are, therefore, entitled to construct objects using more > than one byte, and they are allowed to define the number of bytes, the > order of the bytes, and the encoding of the bytes. > > An implementation may thus choose (for whatever daft reason) to define > that a short int will consist of three bytes, and an int will consist of > two bytes, /as long as/ it observes any explicit constraints that the > Standard imposes. > > The implementation may also define the encoding of the bytes. It is thus > free to choose /which/ bit of an int will be the sign bit, /which/ bits > of the int (if any) will be padding, and /which/ bits of the int will be > value bits - so long as it: > > * provides enough value bits to meet the minimum requirements for the type; > * provides a sign bit if the type is signed; > * maintains the value range relationships imposed upon it by the ranking > schema. > > The implementation is even free to mix everything up! Using S as the > sign bit, P as a padding bit, and V as a value bit, the Standard permits > (by the above wording) an implementation to construct ints like this: > > PPPVVVVPPPVVVVSVVVVPPPVVVVPPP > > with twelve padding bits, sixteen value bits, one sign bit, making 29 > bits altogether - on such a system, CHAR_BIT would have to be 29, > because an int must be at least one byte, so CHAR_BIT can't exceed the > int's width, and all bytes must be the same size, but 29 is prime, so > there is no way to subdivide it into smaller bytes. > > Of course, no sane implementation would do this - but the Standard > permits it anyway. > And nowhere does it say padding BYTES are allowed. > The Standard gives just as much freedom for short, and the following > would be a perfectly legal construction of a short: > > PPPPPPPVVPPPPPPPVVPPPPPPPVVVSVVVPPPPPPPVVPPPPPPPVVVPPPPPPP > > 15 value bits, one sign bit, and 42 padding bits, making 58 altogether. > > The Standard clearly permits both of these encodings. The only question > is whether the Standard permits them /in the same implementation/, and > there is only one reason why it might not - SHRT_MAX must not exceed > INT_MAX. But these encodings give an INT_MAX of 65535 and a SHRT_MAX of > 32767, so all is well. > > Conclusion: the Standard leaves the encoding of integer types up to the > implementation, so long as some basic rules are observed (minimum value > ranges, signedness, and ranking). There is therefore no /requirement/ > that sizeof(short) must be <= sizeof(int). It usually will be, but it's > not a /requirement/. > Nowhere have you shown where padding BYTES are allowed. This is probably a great surprise to your limited intellect, but not all processors use an 8 bit byte. The PDP-11, for instance, used 36 bits (plus 7 ECC bits for a total of 43 bits) in the smallest addressable unit of memory. Many DSP chips use 10 or 12 bits per word. What the standard is saying is that compilers do not have to use all of the bits. For instance, in a PDP-11, the compiler could very well use 16 bit shorts and 32 bit ints - with the remainder of the word being padding bits. And in a DSP chip with 10 bit words, the compiler could use 4 words but only 32 bits for an int. These things are perfectly legal according to the standard. Your interpretation is not. -- ================== 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 17:32 +0100 |
| Message-ID | <nn5euf$2po$1@dont-email.me> |
| In reply to | #91011 |
On 25/07/16 16:48, Jerry Stuckle wrote: > On 7/25/2016 8:50 AM, Richard Heathfield wrote: >> On 25/07/16 13:22, Jerry Stuckle wrote: >>> On 7/25/2016 8:09 AM, Richard Heathfield wrote: >>>> On 25/07/16 13:08, Jerry Stuckle wrote: >>>>> On 7/24/2016 11:54 PM, Joe Pfeiffer wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >> <snip> >>>>>>> No, Richard is saying you can pad bits which will also add bytes >>>>>>> to the >>>>>>> type. But nowhere in the standard does it say that is legitimate. >>>>>> >>>>>> You're claiming it isn't legitimate, and I can't find any limit to how >>>>>> many bits you can pad with. As I've asked you before, where does >>>>>> it say >>>>>> you can't add more than CHAR_BIT-1 bits of padding? >>>>>> >>>>> >>>>> Where does it say you can pad BYTES? >>>> >>>> When you have discovered the answer to his question, you will >>>> automatically learn the answer to your question. >>>> >>> >>> You claimed the standard allows it. Show where. >> >> I have done so already. >> > > No, you haven't. You've only shown were padding BITS are allowed. You don't read so good, do you? I have shown how the Standard allows the possibility that sizeof(short) > sizeof(int) using padding bits, which you agree are allowed by the Standard. You, on the other hand, have shown nothing but contempt, ignorance, and a woeful inability to read for comprehension. >>> And don't go by the >>> claim that the standard allows padding bits. >> >> "Tell me what 3 + 4 is, and let's not have any of that nonsense about it >> being 7." The right answer is the right answer, even when you don't like >> it. > > You've only shown where padding BITS are allowed. That's sufficient for your claim to fall. >>> That is not the same as padding bytes. >> >> The Standard allows implementations to add multiple padding bits, and >> imposes no limit on how many may be added. >> > > It says nothing about allowing padding BYTES. The provision for padding bits (which you acknowledge the Standard permits) is sufficient. >>> Standards state what is allowed. There is no way for a standard to >>> state everything that is disallowed. And no where does the standard >>> state padding bytes are allowed. >> >> The Standard very frequently states what is not allowed. For example, >> see 6.2.6.2(2), which says that "signed char shall not have any padding >> bits". >> >> But let's see what the Standard explicitly allows, shall we? >> >> 6.2.6.1(2) says: "Except for bit-fields, 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." >> >> Implementations are, therefore, entitled to construct objects using more >> than one byte, and they are allowed to define the number of bytes, the >> order of the bytes, and the encoding of the bytes. >> >> An implementation may thus choose (for whatever daft reason) to define >> that a short int will consist of three bytes, and an int will consist of >> two bytes, /as long as/ it observes any explicit constraints that the >> Standard imposes. >> >> The implementation may also define the encoding of the bytes. It is thus >> free to choose /which/ bit of an int will be the sign bit, /which/ bits >> of the int (if any) will be padding, and /which/ bits of the int will be >> value bits - so long as it: >> >> * provides enough value bits to meet the minimum requirements for the type; >> * provides a sign bit if the type is signed; >> * maintains the value range relationships imposed upon it by the ranking >> schema. >> >> The implementation is even free to mix everything up! Using S as the >> sign bit, P as a padding bit, and V as a value bit, the Standard permits >> (by the above wording) an implementation to construct ints like this: >> >> PPPVVVVPPPVVVVSVVVVPPPVVVVPPP >> >> with twelve padding bits, sixteen value bits, one sign bit, making 29 >> bits altogether - on such a system, CHAR_BIT would have to be 29, >> because an int must be at least one byte, so CHAR_BIT can't exceed the >> int's width, and all bytes must be the same size, but 29 is prime, so >> there is no way to subdivide it into smaller bytes. >> >> Of course, no sane implementation would do this - but the Standard >> permits it anyway. >> > > And nowhere does it say padding BYTES are allowed. You really don't read good, do you? > >> The Standard gives just as much freedom for short, and the following >> would be a perfectly legal construction of a short: >> >> PPPPPPPVVPPPPPPPVVPPPPPPPVVVSVVVPPPPPPPVVPPPPPPPVVVPPPPPPP >> >> 15 value bits, one sign bit, and 42 padding bits, making 58 altogether. >> >> The Standard clearly permits both of these encodings. The only question >> is whether the Standard permits them /in the same implementation/, and >> there is only one reason why it might not - SHRT_MAX must not exceed >> INT_MAX. But these encodings give an INT_MAX of 65535 and a SHRT_MAX of >> 32767, so all is well. >> >> Conclusion: the Standard leaves the encoding of integer types up to the >> implementation, so long as some basic rules are observed (minimum value >> ranges, signedness, and ranking). There is therefore no /requirement/ >> that sizeof(short) must be <= sizeof(int). It usually will be, but it's >> not a /requirement/. >> > > Nowhere have you shown where padding BYTES are allowed. > > This is probably a great surprise to your limited intellect, but not all > processors use an 8 bit byte. What on earth do you think I've been talking about? In this thread, I've given examples using 11-bit bytes, 13-bit bytes, even 29-bit bytes. /Of course/ I know that not all processors use an 8-bit byte. If you knew the first thing about me, you'd know that I have myself pointed out this very fact in this very newsgroup on a number of occasions. > The PDP-11, for instance, used 36 bits > (plus 7 ECC bits for a total of 43 bits) in the smallest addressable > unit of memory. Many DSP chips use 10 or 12 bits per word. Or 32, in fact. > What the > standard is saying is that compilers do not have to use all of the bits. You have said that the Standard defines what is allowed, and that the absence of specific permission to do X means that X is not allowed. (This, in fact, is your entire argument.) Since the term "not have to use all of the bits" doesn't appear in the Standard (and it doesn't - I checked), you cannot reasonably advance it as an argument without contradicting yourself. /I/ can advance it as an argument, because I'm not daft enough to think that the Standard must spell something out in Jerry's exact wording in order for it to be allowed. But you can't, without being inconsistent. > For instance, in a PDP-11, the compiler could very well use 16 bit > shorts and 32 bit ints - with the remainder of the word being padding > bits. And in a DSP chip with 10 bit words, the compiler could use 4 > words but only 32 bits for an int. > > These things are perfectly legal according to the standard. Agreed. > Your interpretation is not. Clearly wrong. -- 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 12:41 -0400 |
| Message-ID | <nn5fev$4n4$1@jstuckle.eternal-september.org> |
| In reply to | #91024 |
On 7/25/2016 12:32 PM, Richard Heathfield wrote: > On 25/07/16 16:48, Jerry Stuckle wrote: >> On 7/25/2016 8:50 AM, Richard Heathfield wrote: >>> On 25/07/16 13:22, Jerry Stuckle wrote: >>>> On 7/25/2016 8:09 AM, Richard Heathfield wrote: >>>>> On 25/07/16 13:08, Jerry Stuckle wrote: >>>>>> On 7/24/2016 11:54 PM, Joe Pfeiffer wrote: >>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> <snip> >>>>>>>> No, Richard is saying you can pad bits which will also add bytes >>>>>>>> to the >>>>>>>> type. But nowhere in the standard does it say that is legitimate. >>>>>>> >>>>>>> You're claiming it isn't legitimate, and I can't find any limit >>>>>>> to how >>>>>>> many bits you can pad with. As I've asked you before, where does >>>>>>> it say >>>>>>> you can't add more than CHAR_BIT-1 bits of padding? >>>>>>> >>>>>> >>>>>> Where does it say you can pad BYTES? >>>>> >>>>> When you have discovered the answer to his question, you will >>>>> automatically learn the answer to your question. >>>>> >>>> >>>> You claimed the standard allows it. Show where. >>> >>> I have done so already. >>> >> >> No, you haven't. You've only shown were padding BITS are allowed. > > You don't read so good, do you? I have shown how the Standard allows the > possibility that sizeof(short) > sizeof(int) using padding bits, which > you agree are allowed by the Standard. You, on the other hand, have > shown nothing but contempt, ignorance, and a woeful inability to read > for comprehension. > I read just fine. You have yet to show where padding BYTES are allowed. And until you do, your statement is pure BS. >>>> And don't go by the >>>> claim that the standard allows padding bits. >>> >>> "Tell me what 3 + 4 is, and let's not have any of that nonsense about it >>> being 7." The right answer is the right answer, even when you don't like >>> it. >> >> You've only shown where padding BITS are allowed. > > That's sufficient for your claim to fall. > Bits are not bytes. You seem to be very confused. >>>> That is not the same as padding bytes. >>> >>> The Standard allows implementations to add multiple padding bits, and >>> imposes no limit on how many may be added. >>> >> >> It says nothing about allowing padding BYTES. > > The provision for padding bits (which you acknowledge the Standard > permits) is sufficient. > Only in your interpretation. But that is not what the standard says. >>>> Standards state what is allowed. There is no way for a standard to >>>> state everything that is disallowed. And no where does the standard >>>> state padding bytes are allowed. >>> >>> The Standard very frequently states what is not allowed. For example, >>> see 6.2.6.2(2), which says that "signed char shall not have any padding >>> bits". >>> >>> But let's see what the Standard explicitly allows, shall we? >>> >>> 6.2.6.1(2) says: "Except for bit-fields, 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." >>> >>> Implementations are, therefore, entitled to construct objects using more >>> than one byte, and they are allowed to define the number of bytes, the >>> order of the bytes, and the encoding of the bytes. >>> >>> An implementation may thus choose (for whatever daft reason) to define >>> that a short int will consist of three bytes, and an int will consist of >>> two bytes, /as long as/ it observes any explicit constraints that the >>> Standard imposes. >>> >>> The implementation may also define the encoding of the bytes. It is thus >>> free to choose /which/ bit of an int will be the sign bit, /which/ bits >>> of the int (if any) will be padding, and /which/ bits of the int will be >>> value bits - so long as it: >>> >>> * provides enough value bits to meet the minimum requirements for the >>> type; >>> * provides a sign bit if the type is signed; >>> * maintains the value range relationships imposed upon it by the ranking >>> schema. >>> >>> The implementation is even free to mix everything up! Using S as the >>> sign bit, P as a padding bit, and V as a value bit, the Standard permits >>> (by the above wording) an implementation to construct ints like this: >>> >>> PPPVVVVPPPVVVVSVVVVPPPVVVVPPP >>> >>> with twelve padding bits, sixteen value bits, one sign bit, making 29 >>> bits altogether - on such a system, CHAR_BIT would have to be 29, >>> because an int must be at least one byte, so CHAR_BIT can't exceed the >>> int's width, and all bytes must be the same size, but 29 is prime, so >>> there is no way to subdivide it into smaller bytes. >>> >>> Of course, no sane implementation would do this - but the Standard >>> permits it anyway. >>> >> >> And nowhere does it say padding BYTES are allowed. > > You really don't read good, do you? > I read just fine. Unlike you, I COMPREHEND what I read. >> >>> The Standard gives just as much freedom for short, and the following >>> would be a perfectly legal construction of a short: >>> >>> PPPPPPPVVPPPPPPPVVPPPPPPPVVVSVVVPPPPPPPVVPPPPPPPVVVPPPPPPP >>> >>> 15 value bits, one sign bit, and 42 padding bits, making 58 altogether. >>> >>> The Standard clearly permits both of these encodings. The only question >>> is whether the Standard permits them /in the same implementation/, and >>> there is only one reason why it might not - SHRT_MAX must not exceed >>> INT_MAX. But these encodings give an INT_MAX of 65535 and a SHRT_MAX of >>> 32767, so all is well. >>> >>> Conclusion: the Standard leaves the encoding of integer types up to the >>> implementation, so long as some basic rules are observed (minimum value >>> ranges, signedness, and ranking). There is therefore no /requirement/ >>> that sizeof(short) must be <= sizeof(int). It usually will be, but it's >>> not a /requirement/. >>> >> >> Nowhere have you shown where padding BYTES are allowed. >> >> This is probably a great surprise to your limited intellect, but not all >> processors use an 8 bit byte. > > What on earth do you think I've been talking about? In this thread, I've > given examples using 11-bit bytes, 13-bit bytes, even 29-bit bytes. /Of > course/ I know that not all processors use an 8-bit byte. If you knew > the first thing about me, you'd know that I have myself pointed out this > very fact in this very newsgroup on a number of occasions. > >> The PDP-11, for instance, used 36 bits >> (plus 7 ECC bits for a total of 43 bits) in the smallest addressable >> unit of memory. Many DSP chips use 10 or 12 bits per word. > > Or 32, in fact. > >> What the >> standard is saying is that compilers do not have to use all of the bits. > > You have said that the Standard defines what is allowed, and that the > absence of specific permission to do X means that X is not allowed. > (This, in fact, is your entire argument.) Since the term "not have to > use all of the bits" doesn't appear in the Standard (and it doesn't - I > checked), you cannot reasonably advance it as an argument without > contradicting yourself. > Wrong again. > /I/ can advance it as an argument, because I'm not daft enough to think > that the Standard must spell something out in Jerry's exact wording in > order for it to be allowed. But you can't, without being inconsistent. > You can advance it as an argument. That does not mean you are correct. >> For instance, in a PDP-11, the compiler could very well use 16 bit >> shorts and 32 bit ints - with the remainder of the word being padding >> bits. And in a DSP chip with 10 bit words, the compiler could use 4 >> words but only 32 bits for an int. >> >> These things are perfectly legal according to the standard. > > Agreed. > >> Your interpretation is not. > > Clearly wrong. > Yes, your interpretation is clearly wrong. If padding bytes were allowed for ints, that would be stated in the standard - like it is for structs. But it only specifies padding bits are allowed. I do know, however, that such a concept is well beyond your limited intellect. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2016-07-25 16:35 +0000 |
| Message-ID | <nn5f4j$13o$1@reader2.panix.com> |
| In reply to | #91011 |
Sigh. I kill-filed Jerry long ago, but hit right-arrow by accident and saw this gem that could not be left unanswered. In article <nn5ccp$p3t$1@jstuckle.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote: >[snip] > >This is probably a great surprise to your limited intellect, but not all >processors use an 8 bit byte. The PDP-11, for instance, used 36 bits >(plus 7 ECC bits for a total of 43 bits) in the smallest addressable >unit of memory. [Snip something about DSPs] No. The PDP-11 was an 8-bit-byte-addressed machine with 16-bit words. You must be thinking of the PDP-10: that was a 36-bit word-oriented machine with variable length bytes. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-07-25 17:50 +0100 |
| Message-ID | <nn5g0c$4t7$2@dont-email.me> |
| In reply to | #91025 |
On 25/07/16 17:35, Dan Cross wrote: > Sigh. I kill-filed Jerry long ago, but hit right-arrow by accident > and saw this gem that could not be left unanswered. > > In article <nn5ccp$p3t$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@attglobal.net> wrote: >> [snip] >> >> This is probably a great surprise to your limited intellect, but not all >> processors use an 8 bit byte. The PDP-11, for instance, used 36 bits >> (plus 7 ECC bits for a total of 43 bits) in the smallest addressable >> unit of memory. [Snip something about DSPs] > > No. The PDP-11 was an 8-bit-byte-addressed machine with 16-bit words. > > You must be thinking of the PDP-10: that was a 36-bit word-oriented > machine with variable length bytes. Dan, you're wrong - by definition - because you are disagreeing with Jerry Stuckle. Never mind what you remember. Never mind the machine's tech specs. Never mind if you were the guy that /designed/ the PDP-11. It doesn't matter. If Jerry says you're wrong, you're wrong. He doesn't need logic, or facts, or reasoning. He only needs assertions and, if they don't seem to be working, insults. Thanks for playing. -- 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 14:57 -0400 |
| Message-ID | <nn5nds$37q$1@jstuckle.eternal-september.org> |
| In reply to | #91025 |
On 7/25/2016 12:35 PM, Dan Cross wrote: > Sigh. I kill-filed Jerry long ago, but hit right-arrow by accident > and saw this gem that could not be left unanswered. > > In article <nn5ccp$p3t$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@attglobal.net> wrote: >> [snip] >> >> This is probably a great surprise to your limited intellect, but not all >> processors use an 8 bit byte. The PDP-11, for instance, used 36 bits >> (plus 7 ECC bits for a total of 43 bits) in the smallest addressable >> unit of memory. [Snip something about DSPs] > > No. The PDP-11 was an 8-bit-byte-addressed machine with 16-bit words. > > You must be thinking of the PDP-10: that was a 36-bit word-oriented > machine with variable length bytes. > > - Dan C. > Sorry, you are correct - it was the PDP-10. It's been a long time since I worked on one. Thanks for the correction. -- ================== 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:01 -0700 |
| Message-ID | <lninvuearz.fsf@kst-u.example.com> |
| In reply to | #90928 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> No. But a bit is a unit of memory, a byte is a unit of data.
Incorrect.
The standard defines a "bit" as a
unit of data storage in the execution environment large enough to
hold an object that may have one of two values
and a "byte" as an
addressable unit of data storage large enough to hold any member of
the basic character set of the execution environment
Since the discussion is about the wording of the C standard, it would be
absurd not to use the standard's definitions of these terms.
[...]
--
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 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web