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 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 22:14 -0400 |
| Message-ID | <nn3smf$ehj$4@jstuckle.eternal-september.org> |
| In reply to | #90941 |
On 7/24/2016 10:01 PM, Keith Thompson wrote: > 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. > > [...] > No argument there. I just want to see where the standard says you can pad an int with 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 20:58 -0400 |
| Message-ID | <nn3o6f$6ca$2@jstuckle.eternal-september.org> |
| In reply to | #90926 |
On 7/24/2016 7:28 PM, 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. > He's saying you can have an arbitrary number of bits, equating to more bytes. That is not in the standard. -- ================== 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:14 +0100 |
| Message-ID | <nn3p5n$8on$2@dont-email.me> |
| In reply to | #90930 |
On 25/07/16 01:58, Jerry Stuckle wrote: > On 7/24/2016 7:28 PM, 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. >> > > He's saying you can have an arbitrary number of bits, That's right. > equating to more bytes. That's not an unreasonable claim, although it isn't actually a claim I made in the above-quoted text. > That is not in the standard. The Standard places no limit on the number of padding bits allowed in integer types (other than char, unsigned char, signed char). This has now been explained to you by several different people, with reference to the Standard, and you have yet to provide a shred of counter-evidence. That's not surprising, because no such evidence exists. -- 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:16 -0400 |
| Message-ID | <nn3son$ehj$5@jstuckle.eternal-september.org> |
| In reply to | #90935 |
On 7/24/2016 9:14 PM, Richard Heathfield wrote: > On 25/07/16 01:58, Jerry Stuckle wrote: >> On 7/24/2016 7:28 PM, 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. >>> >> >> He's saying you can have an arbitrary number of bits, > > That's right. > >> equating to more bytes. > > That's not an unreasonable claim, although it isn't actually a claim I > made in the above-quoted text. > Yes it is. Nowhere in the standard does it allow for padding of bytes. >> That is not in the standard. > > The Standard places no limit on the number of padding bits allowed in > integer types (other than char, unsigned char, signed char). > > This has now been explained to you by several different people, with > reference to the Standard, and you have yet to provide a shred of > counter-evidence. That's not surprising, because no such evidence exists. > You have yet to show where the standard says you can pad BYTES. The standard says what you CAN do - not what you CAN'T do. So show where it says you can pad BYTES. -- ================== 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 19:35 -0600 |
| Message-ID | <1blh0qh53s.fsf@pfeifferfamily.net> |
| In reply to | #90930 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 7/24/2016 7:28 PM, 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. >> > > He's saying you can have an arbitrary number of bits, equating to more > bytes. That is not in the standard. So is your claim that the maximum number of padding bits is CHAR_BIT-1 (else you'd be padding by a full byte, as in Richard's example)? Where is that limit set?
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-24 09:38 -0700 |
| Message-ID | <e6800575-389b-4789-8c8d-a2526e30d68e@googlegroups.com> |
| In reply to | #90901 |
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. 6.2.6.2p1 gives permission for a unsigned integer types other than unsigned char to have padding bits. p2 gives the same permission to signed integer types other than signed char. There are real-world implementations that take advantage of that permission. 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? The most extreme case I've heard of with is a platform which had no native support for any kind of arithmetic that wasn't floating point arithmetic. It emulated long integers using the mantissa and sign bits of a floating point type - the exponent portion was ignored, and was effectively just padding. But in that case, the exponent was, IIRC, something like 10 bits, so failing to include the padding bits in the size would still have required reporting the size in fractional bytes. 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? Keep in mind that, given the following declaration: int array[2]; it's mandatory that (char*)(array+1) == (char*)(array) + sizeof array[0]. If sizeof array[0] doesn't include the 8 padding bits, how would that work? > And no, sizeof (short) > sizeof (int) is not permitted. Citation, please? The only relevant requirements I can find are "For any two integer types with the same signedness and different integer conversion rank (see 6.3.1.1), the range of values of the type with smaller integer conversion rank is a subrange of the values of the other type." Thus, INT_MIN <= SHRT_MIN && SHRT_MAX <= INT_MAX is required. However, it's perfectly permissible for short to be a 24 bit type with 8 padding bits, while int is a 16 bit type with no padding bits. I can't think of any good reason why anyone would want to do that, but the C standard says nothing to prohibit such an implementation. If you had said "sizeof(short) > sizeof(int) never happens on real systems", I might believe you - though I would not believe that you had ever collected enough information to justify absolute certainty in that belief. However, you said "is not permitted" - and in that case, you can only be correct if you can specify the relevant rule that does not permit it.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-24 12:58 -0400 |
| Message-ID | <7db2b3af-2b18-eee0-cd60-8bb995f0b2ee@verizon.net> |
| In reply to | #90905 |
On 07/24/2016 12:38 PM, jameskuyper@verizon.net wrote: > On Sunday, July 24, 2016 at 11:06:43 AM UTC-4, Jerry Stuckle wrote: ... >> It is also the size in bytes. Size of an int does not include any padding. > > 6.2.6.2p1 gives permission for a unsigned integer types other than > unsigned char to have padding bits. p2 gives the same permission to > signed integer types other than signed char. There are real-world > implementations that take advantage of that permission. That last sentence implies the wrong order of cause and effect. What I should have said was: "This permission was given because there were real-world implementations that needed it." As a general rule: if the C standard goes out of it's way to allow a special case that doesn't apply to any any implementation you've ever heard of, it's usually because there's already one or more existing implementations that you never heard of which do need that special case. The committee does not just invent these things for the fun of it, no matter what some of it's critics say to the contrary.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 17:28 -0400 |
| Message-ID | <nn3bud$4ps$2@jstuckle.eternal-september.org> |
| In reply to | #90905 |
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. > > 6.2.6.2p1 gives permission for a unsigned integer types other than unsigned char to have padding bits. p2 gives the same permission to signed integer types other than signed char. There are real-world implementations that take advantage of that permission. > > 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? > The most extreme case I've heard of with is a platform which had no native support for any kind of arithmetic that wasn't floating point arithmetic. It emulated long integers using the mantissa and sign bits of a floating point type - the exponent portion was ignored, and was effectively just padding. But in that case, the exponent was, IIRC, something like 10 bits, so failing to include the padding bits in the size would still have required reporting the size in fractional bytes. > > 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? > > Keep in mind that, given the following declaration: > > int array[2]; > > it's mandatory that (char*)(array+1) == (char*)(array) + sizeof array[0]. If sizeof array[0] doesn't include the 8 padding bits, how would that work? > >> And no, sizeof (short) > sizeof (int) is not permitted. > > Citation, please? > The only relevant requirements I can find are > > "For any two integer types with the same signedness and different integer conversion rank (see 6.3.1.1), the range of values of the type with smaller integer conversion rank is a subrange of the values of the other type." Thus, INT_MIN <= SHRT_MIN && SHRT_MAX <= INT_MAX is required. However, it's perfectly permissible for short to be a 24 bit type with 8 padding bits, while int is a 16 bit type with no padding bits. I can't think of any good reason why anyone would want to do that, but the C standard says nothing to prohibit such an implementation. > > If you had said "sizeof(short) > sizeof(int) never happens on real systems", I might believe you - though I would not believe that you had ever collected enough information to justify absolute certainty in that belief. However, you said "is not permitted" - and in that case, you can only be correct if you can specify the relevant rule that does not permit it. > Which would make as much sense as your first comment. Sheesh. Language lawyers who don't know language or law. -- ================== 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-24 23:01 +0100 |
| Message-ID | <nn3dsc$dvk$1@dont-email.me> |
| In reply to | #90916 |
On 24/07/16 22:28, 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. >> >> 6.2.6.2p1 gives permission for a unsigned integer types other than unsigned char to have padding bits. p2 gives the same permission to signed integer types other than signed char. There are real-world implementations that take advantage of that permission. >> >> 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? Don't be such an ass. James Kuyper is a very experienced and knowledgeable C programmer. Of course he knows the difference between bits and bytes. But in this case it doesn't matter, because padding bytes are just rather CHAR_BIT-wide collections of padding bits. His point stands either way. > >> The most extreme case I've heard of with is a platform which had no native support for any kind of arithmetic that wasn't floating point arithmetic. It emulated long integers using the mantissa and sign bits of a floating point type - the exponent portion was ignored, and was effectively just padding. But in that case, the exponent was, IIRC, something like 10 bits, so failing to include the padding bits in the size would still have required reporting the size in fractional bytes. >> >> 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? >> >> Keep in mind that, given the following declaration: >> >> int array[2]; >> >> it's mandatory that (char*)(array+1) == (char*)(array) + sizeof array[0]. If sizeof array[0] doesn't include the 8 padding bits, how would that work? >> >>> And no, sizeof (short) > sizeof (int) is not permitted. >> >> Citation, please? >> The only relevant requirements I can find are >> >> "For any two integer types with the same signedness and different integer conversion rank (see 6.3.1.1), the range of values of the type with smaller integer conversion rank is a subrange of the values of the other type." Thus, INT_MIN <= SHRT_MIN && SHRT_MAX <= INT_MAX is required. However, it's perfectly permissible for short to be a 24 bit type with 8 padding bits, while int is a 16 bit type with no padding bits. I can't think of any good reason why anyone would want to do that, but the C standard says nothing to prohibit such an implementation. >> >> If you had said "sizeof(short) > sizeof(int) never happens on real systems", I might believe you - though I would not believe that you had ever collected enough information to justify absolute certainty in that belief. However, you said "is not permitted" - and in that case, you can only be correct if you can specify the relevant rule that does not permit it. >> > > Which would make as much sense as your first comment. > > Sheesh. Language lawyers who don't know language or law. When you're wrong, the best course is to stand up, say sorry, sit down, and shut up. Aggressive posturing from an indefensible position is a losing strategy. -- 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 15:13 -0700 |
| Message-ID | <1afccdd2-e9c5-43cf-8cf6-ad4ee310d438@googlegroups.com> |
| In reply to | #90918 |
On Sunday, July 24, 2016 at 11:01:56 PM UTC+1, Richard Heathfield wrote: > On 24/07/16 22:28, Jerry Stuckle wrote: > > On 7/24/2016 12:38 PM, jameskuyper@verizon.net wrote: > > >> 6.2.6.2p1 gives permission for a unsigned integer types other than unsigned char to have padding bits. p2 gives the same permission to signed integer types other than signed char. There are real-world implementations that take advantage of that permission. > > Yes - BITS, not BYTES. Do you know the difference? > > Don't be such an ass. James Kuyper is a very experienced and > knowledgeable C programmer. Of course he knows the difference between > bits and bytes. But in this case it doesn't matter, because padding > bytes are just rather CHAR_BIT-wide collections of padding bits. His > point stands either way. > Though the Nintendo 64 actually had a "secret" ninth bit for each char. You could access it via special machine instructions.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 18:20 -0400 |
| Message-ID | <nn3euv$ge2$2@jstuckle.eternal-september.org> |
| In reply to | #90918 |
On 7/24/2016 6:01 PM, Richard Heathfield wrote: > On 24/07/16 22:28, 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. >>> >>> 6.2.6.2p1 gives permission for a unsigned integer types other than >>> unsigned char to have padding bits. p2 gives the same permission to >>> signed integer types other than signed char. There are real-world >>> implementations that take advantage of that permission. >>> >>> 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? > > Don't be such an ass. James Kuyper is a very experienced and > knowledgeable C programmer. Of course he knows the difference between > bits and bytes. But in this case it doesn't matter, because padding > bytes are just rather CHAR_BIT-wide collections of padding bits. His > point stands either way. > You're the one being an ass. Claiming padding bits can extend to padding bytes. Your citation? >> >>> The most extreme case I've heard of with is a platform which had no >>> native support for any kind of arithmetic that wasn't floating point >>> arithmetic. It emulated long integers using the mantissa and sign >>> bits of a floating point type - the exponent portion was ignored, and >>> was effectively just padding. But in that case, the exponent was, >>> IIRC, something like 10 bits, so failing to include the padding bits >>> in the size would still have required reporting the size in >>> fractional bytes. >>> >>> 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? >>> >>> Keep in mind that, given the following declaration: >>> >>> int array[2]; >>> >>> it's mandatory that (char*)(array+1) == (char*)(array) + sizeof >>> array[0]. If sizeof array[0] doesn't include the 8 padding bits, how >>> would that work? >>> >>>> And no, sizeof (short) > sizeof (int) is not permitted. >>> >>> Citation, please? >>> The only relevant requirements I can find are >>> >>> "For any two integer types with the same signedness and different >>> integer conversion rank (see 6.3.1.1), the range of values of the >>> type with smaller integer conversion rank is a subrange of the values >>> of the other type." Thus, INT_MIN <= SHRT_MIN && SHRT_MAX <= INT_MAX >>> is required. However, it's perfectly permissible for short to be a 24 >>> bit type with 8 padding bits, while int is a 16 bit type with no >>> padding bits. I can't think of any good reason why anyone would want >>> to do that, but the C standard says nothing to prohibit such an >>> implementation. >>> >>> If you had said "sizeof(short) > sizeof(int) never happens on real >>> systems", I might believe you - though I would not believe that you >>> had ever collected enough information to justify absolute certainty >>> in that belief. However, you said "is not permitted" - and in that >>> case, you can only be correct if you can specify the relevant rule >>> that does not permit it. >>> >> >> Which would make as much sense as your first comment. >> >> Sheesh. Language lawyers who don't know language or law. > > When you're wrong, the best course is to stand up, say sorry, sit down, > and shut up. Aggressive posturing from an indefensible position is a > losing strategy. > Yes, you really should do that. But I know you're incapable of admitting you are wrong on anything. -- ================== 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-24 23:46 +0100 |
| Message-ID | <nn3gg9$kp0$2@dont-email.me> |
| In reply to | #90921 |
On 24/07/16 23:20, Jerry Stuckle wrote: > On 7/24/2016 6:01 PM, Richard Heathfield wrote: >> On 24/07/16 22:28, 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. >>>> >>>> 6.2.6.2p1 gives permission for a unsigned integer types other than >>>> unsigned char to have padding bits. p2 gives the same permission to >>>> signed integer types other than signed char. There are real-world >>>> implementations that take advantage of that permission. >>>> >>>> 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? >> >> Don't be such an ass. James Kuyper is a very experienced and >> knowledgeable C programmer. Of course he knows the difference between >> bits and bytes. But in this case it doesn't matter, because padding >> bytes are just rather CHAR_BIT-wide collections of padding bits. His >> point stands either way. >> > > You're the one being an ass. Claiming padding bits can extend to > padding bytes. Your citation? Already given. Yours? <nonsense snipped> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 20:59 -0400 |
| Message-ID | <nn3o90$6ca$3@jstuckle.eternal-september.org> |
| In reply to | #90924 |
On 7/24/2016 6:46 PM, Richard Heathfield wrote: > On 24/07/16 23:20, Jerry Stuckle wrote: >> On 7/24/2016 6:01 PM, Richard Heathfield wrote: >>> On 24/07/16 22:28, 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. >>>>> >>>>> 6.2.6.2p1 gives permission for a unsigned integer types other than >>>>> unsigned char to have padding bits. p2 gives the same permission to >>>>> signed integer types other than signed char. There are real-world >>>>> implementations that take advantage of that permission. >>>>> >>>>> 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? >>> >>> Don't be such an ass. James Kuyper is a very experienced and >>> knowledgeable C programmer. Of course he knows the difference between >>> bits and bytes. But in this case it doesn't matter, because padding >>> bytes are just rather CHAR_BIT-wide collections of padding bits. His >>> point stands either way. >>> >> >> You're the one being an ass. Claiming padding bits can extend to >> padding bytes. Your citation? > > Already given. Yours? > > <nonsense snipped> > No, you have given no citation that the number of bytes can be larger. Only bits. Where in the standard does it say you can have padding 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 02:21 +0100 |
| Message-ID | <nn3phv$9u0$1@dont-email.me> |
| In reply to | #90931 |
On 25/07/16 01:59, Jerry Stuckle wrote: > On 7/24/2016 6:46 PM, Richard Heathfield wrote: >> On 24/07/16 23:20, Jerry Stuckle wrote: >>> On 7/24/2016 6:01 PM, Richard Heathfield wrote: >>>> On 24/07/16 22:28, 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. >>>>>> >>>>>> 6.2.6.2p1 gives permission for a unsigned integer types other than >>>>>> unsigned char to have padding bits. p2 gives the same permission to >>>>>> signed integer types other than signed char. There are real-world >>>>>> implementations that take advantage of that permission. >>>>>> >>>>>> 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? >>>> >>>> Don't be such an ass. James Kuyper is a very experienced and >>>> knowledgeable C programmer. Of course he knows the difference between >>>> bits and bytes. But in this case it doesn't matter, because padding >>>> bytes are just rather CHAR_BIT-wide collections of padding bits. His >>>> point stands either way. >>>> >>> >>> You're the one being an ass. Claiming padding bits can extend to >>> padding bytes. Your citation? >> >> Already given. Yours? >> >> <nonsense snipped> >> > > No, you have given no citation that the number of bytes can be larger. > Only bits. Bits is enough. Consider: CHAR_BIT: 13 short: 1 sign bit, 21 value bits, 17 padding bits. 39 bits altogether. sizeof(short): 3 int: 1 sign bit, 22 value bits, 3 padding bits. 26 bits altogether. sizeof(int): 2 > Where in the standard does it say you can have padding BYTES? You seem to believe (wrongly) that the Standard forbids more than (CHAR_BIT - 1) padding bits in an integer. The Standard imposes no such limitation. You have had plenty of time to track down such a limitation, and yet you have not done so. Either you have tried and failed, or you have not tried. If you have not tried, I suggest you try now. Then you will fail, and then - just /maybe/ - you might learn something about C. But as long as you continue (metaphorically speaking) to put your fingers in your ears, you're not going to learn anything. Your loss, not mine. -- 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:17 -0400 |
| Message-ID | <nn3sqi$ehj$6@jstuckle.eternal-september.org> |
| In reply to | #90936 |
On 7/24/2016 9:21 PM, Richard Heathfield wrote: > On 25/07/16 01:59, Jerry Stuckle wrote: >> On 7/24/2016 6:46 PM, Richard Heathfield wrote: >>> On 24/07/16 23:20, Jerry Stuckle wrote: >>>> On 7/24/2016 6:01 PM, Richard Heathfield wrote: >>>>> On 24/07/16 22:28, 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. >>>>>>> >>>>>>> 6.2.6.2p1 gives permission for a unsigned integer types other than >>>>>>> unsigned char to have padding bits. p2 gives the same permission to >>>>>>> signed integer types other than signed char. There are real-world >>>>>>> implementations that take advantage of that permission. >>>>>>> >>>>>>> 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? >>>>> >>>>> Don't be such an ass. James Kuyper is a very experienced and >>>>> knowledgeable C programmer. Of course he knows the difference between >>>>> bits and bytes. But in this case it doesn't matter, because padding >>>>> bytes are just rather CHAR_BIT-wide collections of padding bits. His >>>>> point stands either way. >>>>> >>>> >>>> You're the one being an ass. Claiming padding bits can extend to >>>> padding bytes. Your citation? >>> >>> Already given. Yours? >>> >>> <nonsense snipped> >>> >> >> No, you have given no citation that the number of bytes can be larger. >> Only bits. > > Bits is enough. Consider: > > CHAR_BIT: 13 > short: 1 sign bit, 21 value bits, 17 padding bits. 39 bits altogether. > sizeof(short): 3 > int: 1 sign bit, 22 value bits, 3 padding bits. 26 bits altogether. > sizeof(int): 2 > >> Where in the standard does it say you can have padding BYTES? > > You seem to believe (wrongly) that the Standard forbids more than > (CHAR_BIT - 1) padding bits in an integer. The Standard imposes no such > limitation. You have had plenty of time to track down such a limitation, > and yet you have not done so. Either you have tried and failed, or you > have not tried. If you have not tried, I suggest you try now. Then you > will fail, and then - just /maybe/ - you might learn something about C. > But as long as you continue (metaphorically speaking) to put your > fingers in your ears, you're not going to learn anything. Your loss, not > mine. > The standard says what you can do - not what you can't do. For instance, it says you can pad BITS. But nowhere 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 03:34 +0100 |
| Message-ID | <nn3ts1$imf$1@dont-email.me> |
| In reply to | #90949 |
On 25/07/16 03:17, Jerry Stuckle wrote: <snip> > The standard says what you can do - not what you can't do. For > instance, it says you can pad BITS. But nowhere does it say you can pad > BYTES. And what upper limit does the Standard place on an implementation's freedom to place padding bits in an integer type (that is not a char type)? That is, what is the maximum number of padding bits that may be added? Chapter and verse, please. -- 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:09 -0400 |
| Message-ID | <nn4vhi$aql$2@jstuckle.eternal-september.org> |
| In reply to | #90953 |
On 7/24/2016 10:34 PM, Richard Heathfield wrote: > On 25/07/16 03:17, Jerry Stuckle wrote: > <snip> > >> The standard says what you can do - not what you can't do. For >> instance, it says you can pad BITS. But nowhere does it say you can pad >> BYTES. > > And what upper limit does the Standard place on an implementation's > freedom to place padding bits in an integer type (that is not a char > type)? That is, what is the maximum number of padding bits that may be > added? Chapter and verse, please. > Where does it say you can pad BYTES? The standard makes a distinction between bits and bytes; it says you can pad with bits, but does not say you can pad with 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:21 +0100 |
| Message-ID | <nn508i$eat$1@dont-email.me> |
| In reply to | #90972 |
On 25/07/16 13:09, Jerry Stuckle wrote: > On 7/24/2016 10:34 PM, Richard Heathfield wrote: >> On 25/07/16 03:17, Jerry Stuckle wrote: >> <snip> >> >>> The standard says what you can do - not what you can't do. For >>> instance, it says you can pad BITS. But nowhere does it say you can pad >>> BYTES. >> >> And what upper limit does the Standard place on an implementation's >> freedom to place padding bits in an integer type (that is not a char >> type)? That is, what is the maximum number of padding bits that may be >> added? Chapter and verse, please. >> > > Where does it say you can pad BYTES? Change the record, and do please try to learn to read for comprehension. > The standard makes a distinction > between bits and bytes; it says you can pad with bits, but does not say > you can pad with bytes. Perhaps we need to break this down a little for you - or even a /lot/. The Standard does indeed make a distinction between bits and bytes. That has never been in question. That you keep banging on about a question to which everyone else already knows the answer is very strange, but that's life, I suppose. The Standard /does/ say that an implementation /can/ add padding /bits/ to non-char integer types. Can we agree on that, at least? Assuming we can, we are then faced with the question of /how many/ bits an implementation can pad non-char integer types with with. Now, the Standard uses the plural form (as someone already pointed out), so we can certainly assume it's not just 1. What we /can't/ assume, because the Standard gives us no licence to assume it, is that there is some upper limit to the number of padding bits that an implementation may choose to add. If there is an arbitrary upper limit of CHAR_BIT - 1 (as you seem to think), then the Standard will tell us that. If there is no such limit, the Standard will not tell us that there is an arbitrary upper limit. So the question is: /does/ the Standard impose on implementations a maximum number of bits that they may use to pad a non-char integer type? I think the answer is no. Presumably you think the answer is yes. If the answer /is/ no, the Standard doesn't need to say so, because the absence of a stated limit clearly implies that the Standard imposes no limit. But if the answer is /yes/, the Standard /must/ say so, because to fail to document the limit is to fail to impose it. So - where does the Standard impose this arbitrary upper limit of CHAR_BIT - 1 bits of padding in non-char integer types? I anticipate that your most likely answer to this question is "where does it say you can pad with BYTES?" yet again. If that /is/ your answer, you are only demonstrating that you have misunderstood the question. Over to you. -- 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:50 -0400 |
| Message-ID | <nn5cf7$p3t$2@jstuckle.eternal-september.org> |
| In reply to | #90982 |
On 7/25/2016 8:21 AM, Richard Heathfield wrote: > On 25/07/16 13:09, Jerry Stuckle wrote: >> On 7/24/2016 10:34 PM, Richard Heathfield wrote: >>> On 25/07/16 03:17, Jerry Stuckle wrote: >>> <snip> >>> >>>> The standard says what you can do - not what you can't do. For >>>> instance, it says you can pad BITS. But nowhere does it say you can >>>> pad >>>> BYTES. >>> >>> And what upper limit does the Standard place on an implementation's >>> freedom to place padding bits in an integer type (that is not a char >>> type)? That is, what is the maximum number of padding bits that may be >>> added? Chapter and verse, please. >>> >> >> Where does it say you can pad BYTES? > > Change the record, and do please try to learn to read for comprehension. > You should take your own advice. >> The standard makes a distinction >> between bits and bytes; it says you can pad with bits, but does not say >> you can pad with bytes. > > Perhaps we need to break this down a little for you - or even a /lot/. > > The Standard does indeed make a distinction between bits and bytes. That > has never been in question. That you keep banging on about a question to > which everyone else already knows the answer is very strange, but that's > life, I suppose. > > The Standard /does/ say that an implementation /can/ add padding /bits/ > to non-char integer types. Can we agree on that, at least? > Yes. > Assuming we can, we are then faced with the question of /how many/ bits > an implementation can pad non-char integer types with with. Now, the > Standard uses the plural form (as someone already pointed out), so we > can certainly assume it's not just 1. What we /can't/ assume, because > the Standard gives us no licence to assume it, is that there is some > upper limit to the number of padding bits that an implementation may > choose to add. > > If there is an arbitrary upper limit of CHAR_BIT - 1 (as you seem to > think), then the Standard will tell us that. If there is no such limit, > the Standard will not tell us that there is an arbitrary upper limit. > > So the question is: /does/ the Standard impose on implementations a > maximum number of bits that they may use to pad a non-char integer type? > It does not allow for padding bytes. > I think the answer is no. Presumably you think the answer is yes. If the > answer /is/ no, the Standard doesn't need to say so, because the absence > of a stated limit clearly implies that the Standard imposes no limit. > But if the answer is /yes/, the Standard /must/ say so, because to fail > to document the limit is to fail to impose it. > > So - where does the Standard impose this arbitrary upper limit of > CHAR_BIT - 1 bits of padding in non-char integer types? > > I anticipate that your most likely answer to this question is "where > does it say you can pad with BYTES?" yet again. If that /is/ your > answer, you are only demonstrating that you have misunderstood the > question. > > Over to you. > So whatever you think is wrong - until you show where the standard allows padding 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 17:38 +0100 |
| Message-ID | <nn5faf$43q$1@dont-email.me> |
| In reply to | #91012 |
On 25/07/16 16:50, Jerry Stuckle wrote: > On 7/25/2016 8:21 AM, Richard Heathfield wrote: >> On 25/07/16 13:09, Jerry Stuckle wrote: >>> On 7/24/2016 10:34 PM, Richard Heathfield wrote: >>>> On 25/07/16 03:17, Jerry Stuckle wrote: >>>> <snip> >>>> >>>>> The standard says what you can do - not what you can't do. For >>>>> instance, it says you can pad BITS. But nowhere does it say you can >>>>> pad >>>>> BYTES. >>>> >>>> And what upper limit does the Standard place on an implementation's >>>> freedom to place padding bits in an integer type (that is not a char >>>> type)? That is, what is the maximum number of padding bits that may be >>>> added? Chapter and verse, please. >>>> >>> >>> Where does it say you can pad BYTES? >> >> Change the record, and do please try to learn to read for comprehension. > > You should take your own advice. I have done so, which is why I am confident of my reading of the Standard, which agrees with that of many C experts, several of whom have contributed to this very thread. We can lead you to information, but we can't make you think. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web