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 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 14:59 -0400 |
| Message-ID | <nn5nhd$37q$2@jstuckle.eternal-september.org> |
| In reply to | #91029 |
On 7/25/2016 12:38 PM, Richard Heathfield wrote: > 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. > Yea, right. Keep on thinking that. You're wrong - as usual. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-25 05:28 -0700 |
| Message-ID | <d4f70c98-954f-4de6-a93e-37f75e97be07@googlegroups.com> |
| In reply to | #90972 |
On Monday, July 25, 2016 at 1:09:30 PM UTC+1, 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? 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. > Normally I would say that a byte is a unit of data, not of memory. Apparently C defines byte as and addressible unit of memory. So in order to "pad bytes", we'd have to be able to write an expression/ function short x; unsigned char *paddingptr = foo(&x); where paddingptr is set reliably to a valid dereferenceable address that access no data, only unused bits. On most implementations, that won't be problematic, but I'm not sure it's guaranteed.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 11:52 -0400 |
| Message-ID | <nn5ck7$p3t$3@jstuckle.eternal-september.org> |
| In reply to | #90985 |
On 7/25/2016 8:28 AM, Malcolm McLean wrote: > On Monday, July 25, 2016 at 1:09:30 PM UTC+1, 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? 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. >> > Normally I would say that a byte is a unit of data, not of memory. > Apparently C defines byte as and addressible unit of memory. > So in order to "pad bytes", we'd have to be able to write an expression/ function > > short x; > unsigned char *paddingptr = foo(&x); > > where paddingptr is set reliably to a valid dereferenceable address that access > no data, only unused bits. > On most implementations, that won't be problematic, but I'm not sure it's > guaranteed. > No, by definition, a byte is the smallest addressable unit of memory. In Intel-based processors, that is 8 bits. But there are any number of other processors which have different sizes. They are also bytes, but to avoid confusion, many programmers on these chips use the term "words" to differentiate them from 8 bit bytes. But they are still the smallest addressable unit of memory. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-25 08:59 -0700 |
| Message-ID | <ed5df603-3283-4280-aa8e-fbed69eabc73@googlegroups.com> |
| In reply to | #91013 |
On Monday, July 25, 2016 at 4:52:45 PM UTC+1, Jerry Stuckle wrote: > > No, by definition, a byte is the smallest addressable unit of memory. > In Intel-based processors, that is 8 bits. But there are any number of > other processors which have different sizes. They are also bytes, but > to avoid confusion, many programmers on these chips use the term "words" > to differentiate them from 8 bit bytes. But they are still the smallest > addressable unit of memory. > Basically a byte is the smallest unit of data that carries a meaning without context. Which is a single character on a character-based symbol manipulation system. However programming has moved on.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 12:29 -0400 |
| Message-ID | <nn5epo$11m$1@jstuckle.eternal-september.org> |
| In reply to | #91015 |
On 7/25/2016 11:59 AM, Malcolm McLean wrote: > On Monday, July 25, 2016 at 4:52:45 PM UTC+1, Jerry Stuckle wrote: >> >> No, by definition, a byte is the smallest addressable unit of memory. >> In Intel-based processors, that is 8 bits. But there are any number of >> other processors which have different sizes. They are also bytes, but >> to avoid confusion, many programmers on these chips use the term "words" >> to differentiate them from 8 bit bytes. But they are still the smallest >> addressable unit of memory. >> > Basically a byte is the smallest unit of data that carries a meaning without > context. Which is a single character on a character-based symbol > manipulation system. > However programming has moved on. > Incorrect. A bit would be the smallest unit of data that carries a meaning without context. A byte is the smallest addressable unit of memory. And in many processors, a byte is not 8 bits. But it is still considered a byte. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-25 09:39 -0700 |
| Message-ID | <270bd22d-d1e9-497d-8ab9-a430275c6db2@googlegroups.com> |
| In reply to | #91023 |
On Monday, July 25, 2016 at 5:29:52 PM UTC+1, Jerry Stuckle wrote: > On 7/25/2016 11:59 AM, Malcolm McLean wrote: > > > Basically a byte is the smallest unit of data that carries a meaning without > > context. Which is a single character on a character-based symbol > > manipulation system. > > However programming has moved on. > > > > Incorrect. A bit would be the smallest unit of data that carries a > meaning without context. A byte is the smallest addressable unit of > memory. And in many processors, a byte is not 8 bits. But it is still > considered a byte. > Not all computers use 1 = true, 0 = false. That's the modern way, every modern system does so. But you can also use 'T' = true and empty or absence of 'T' means no condition of truth. Binary is used to encode the characters, but for no other purpose. It's purely symbolic.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 15:00 -0400 |
| Message-ID | <nn5njs$37q$3@jstuckle.eternal-september.org> |
| In reply to | #91030 |
On 7/25/2016 12:39 PM, Malcolm McLean wrote: > On Monday, July 25, 2016 at 5:29:52 PM UTC+1, Jerry Stuckle wrote: >> On 7/25/2016 11:59 AM, Malcolm McLean wrote: >>>> Basically a byte is the smallest unit of data that carries a meaning without >>> context. Which is a single character on a character-based symbol >>> manipulation system. >>> However programming has moved on. >>> >> >> Incorrect. A bit would be the smallest unit of data that carries a >> meaning without context. A byte is the smallest addressable unit of >> memory. And in many processors, a byte is not 8 bits. But it is still >> considered a byte. >> > Not all computers use 1 = true, 0 = false. > That's the modern way, every modern system does so. > But you can also use 'T' = true and empty or absence of 'T' means > no condition of truth. > Binary is used to encode the characters, but for no other purpose. > It's purely symbolic. > And your point is? You don't have one, as usual. But there are many modern processors where a byte is not 8 bits. -- ================== 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:09 -0700 |
| Message-ID | <lneg6ieadw.fsf@kst-u.example.com> |
| In reply to | #90918 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> 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.
Richard, I regret that I must correct you. The standard does not use
the term "padding bytes" when discussing storage within an integer
object that does not contribute to its value. It consistently uses
the term "padding bits", without reference to whether the number
of such bits may or may not be a multiple of CHAR_BIT.
"Padding bytes" are bytes within a structure or union that are
not part of one of its members, typically added to meet alignment
requirements.
A footnote says that "structure assignment need not copy any padding
bits". I believe that is an error; it should say "padding bytes".
(I haven't read what JS wrote other than the part you quoted,
but I feel reasonably confident that this distinction doesn't help
his case, whatever it may be.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 22:19 -0400 |
| Message-ID | <nn3suf$ehj$7@jstuckle.eternal-september.org> |
| In reply to | #90942 |
On 7/24/2016 10:09 PM, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > [...] >> 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. > > Richard, I regret that I must correct you. The standard does not use > the term "padding bytes" when discussing storage within an integer > object that does not contribute to its value. It consistently uses > the term "padding bits", without reference to whether the number > of such bits may or may not be a multiple of CHAR_BIT. > > "Padding bytes" are bytes within a structure or union that are > not part of one of its members, typically added to meet alignment > requirements. > > A footnote says that "structure assignment need not copy any padding > bits". I believe that is an error; it should say "padding bytes". > > (I haven't read what JS wrote other than the part you quoted, > but I feel reasonably confident that this distinction doesn't help > his case, whatever it may be.) > Keith, I have no problem with byte padding in structures. But the structure can also have padding bits, i.e. in the case of bit fields. So while the footnote may not be entire correct, it is also not entirely incorrect. -- ================== 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:31 +0100 |
| Message-ID | <nn3tmk$i9s$1@dont-email.me> |
| In reply to | #90942 |
On 25/07/16 03:09, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > [...] >> 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. > > Richard, I regret that I must correct you. Go for it. :-) > The standard does not use > the term "padding bytes" when discussing storage within an integer > object that does not contribute to its value. Yes, I know that. It does use the term "padding bytes" in connection with unions and structs, but not in connection with integers. But the term "padding bytes" is neither important nor indeed relevant. The claim Mr Stuckle made is that sizeof(short) cannot exceed sizeof(int), and it is this claim that I am addressing. > It consistently uses > the term "padding bits", without reference to whether the number > of such bits may or may not be a multiple of CHAR_BIT. Correct. > "Padding bytes" are bytes within a structure or union that are > not part of one of its members, typically added to meet alignment > requirements. Correct. > A footnote says that "structure assignment need not copy any padding > bits". I believe that is an error; it should say "padding bytes". <shrug> It's non-normative, and unlikely to cause anyone to lie awake at night worrying about it. I think you're right, though. > (I haven't read what JS wrote other than the part you quoted, > but I feel reasonably confident that this distinction doesn't help > his case, whatever it may be.) It doesn't. His case, as far as I can make it out, is that he must be right because he's Jerry Stuckle. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-24 21:20 -0700 |
| Message-ID | <ln1t2ie4bj.fsf@kst-u.example.com> |
| In reply to | #90952 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 25/07/16 03:09, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> [...]
>>> 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.
>>
>> Richard, I regret that I must correct you.
>
> Go for it. :-)
>
>> The standard does not use
>> the term "padding bytes" when discussing storage within an integer
>> object that does not contribute to its value.
>
> Yes, I know that. It does use the term "padding bytes" in connection
> with unions and structs, but not in connection with integers. But the
> term "padding bytes" is neither important nor indeed relevant. The claim
> Mr Stuckle made is that sizeof(short) cannot exceed sizeof(int), and it
> is this claim that I am addressing.
Oh, well of course he's wrong about that.
Sounds like the issue of "padding bytes" was introduced (deliberately
or not) as a red herring. There can be arbitrarily many padding
*bits* (which may or may not form bytes).
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 08:10 -0400 |
| Message-ID | <nn4vk2$aql$3@jstuckle.eternal-september.org> |
| In reply to | #90960 |
On 7/25/2016 12:20 AM, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 25/07/16 03:09, Keith Thompson wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: >>> [...] >>>> 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. >>> >>> Richard, I regret that I must correct you. >> >> Go for it. :-) >> >>> The standard does not use >>> the term "padding bytes" when discussing storage within an integer >>> object that does not contribute to its value. >> >> Yes, I know that. It does use the term "padding bytes" in connection >> with unions and structs, but not in connection with integers. But the >> term "padding bytes" is neither important nor indeed relevant. The claim >> Mr Stuckle made is that sizeof(short) cannot exceed sizeof(int), and it >> is this claim that I am addressing. > > Oh, well of course he's wrong about that. > > Sounds like the issue of "padding bytes" was introduced (deliberately > or not) as a red herring. There can be arbitrarily many padding > *bits* (which may or may not form bytes). > > [...] > No, I'm right because that's what the standard allows. But you're too stoopid to understand that, or too proud to admit you could be wrong. -- ================== 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-25 08:12 -0400 |
| Message-ID | <nn4vn6$aql$4@jstuckle.eternal-september.org> |
| In reply to | #90974 |
On 7/25/2016 8:10 AM, Jerry Stuckle wrote: > On 7/25/2016 12:20 AM, Keith Thompson wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >>> On 25/07/16 03:09, Keith Thompson wrote: >>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>> [...] >>>>> 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. >>>> >>>> Richard, I regret that I must correct you. >>> >>> Go for it. :-) >>> >>>> The standard does not use >>>> the term "padding bytes" when discussing storage within an integer >>>> object that does not contribute to its value. >>> >>> Yes, I know that. It does use the term "padding bytes" in connection >>> with unions and structs, but not in connection with integers. But the >>> term "padding bytes" is neither important nor indeed relevant. The claim >>> Mr Stuckle made is that sizeof(short) cannot exceed sizeof(int), and it >>> is this claim that I am addressing. >> >> Oh, well of course he's wrong about that. >> >> Sounds like the issue of "padding bytes" was introduced (deliberately >> or not) as a red herring. There can be arbitrarily many padding >> *bits* (which may or may not form bytes). >> >> [...] >> > > No, I'm right because that's what the standard allows. But you're too > stoopid to understand that, or too proud to admit you could be wrong. > Sorry, the previous message was meant in response to Richard. But it was Richard who claimed the padding bytes - it's the only way sizeof(int) could be smaller than sizeof(short). -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-27 09:09 -0700 |
| Message-ID | <kfnfuqvoyf5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #90942 |
Keith Thompson <kst-u@mib.org> writes: > Richard Heathfield <rjh@cpax.org.uk> writes: > [...] >> 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. > > Richard, I regret that I must correct you. The standard does not use > the term "padding bytes" when discussing storage within an integer > object that does not contribute to its value. It consistently uses > the term "padding bits", without reference to whether the number > of such bits may or may not be a multiple of CHAR_BIT. > > "Padding bytes" are bytes within a structure or union that are > not part of one of its members, typically added to meet alignment > requirements. > > A footnote says that "structure assignment need not copy any padding > bits". I believe that is an error; it should say "padding bytes". I have a different reaction to the phrasing used here. Let me try to explain. The Standard allows padding between two consecutive members of a struct. It also allows padding after the last member of a struct, and "before" the first member in the sense that a struct whose first member is a bitfield might not occupy any of the first byte of the struct object. (To keep things simple I am ignoring flexible array members.) When two consecutive members are both non-bitfield members, any padding between them is necessarily an integral number of bytes, and aligned on byte boundaries. In this case "between" has its ordinary meaning in terms of addresses of the bytes involved. When two consecutive members have at least one bitfield member, there may be padding consisting of a set of bits less than a full byte, or there may be padding consisting of a set of bits at least as large as a full byte. In the latter case it is possible for a byte-size subset of those bits to occupy memory aligned on a byte boundary. When a bitfield member is involved "between" may be slightly different than the meaning in the previous case, because of how bitfields are packed in addressable units. (Note: I think an argument could be made that when the set of padding bits is at least as big as a full byte then there will necessarily be one or more subsets that occupy memory aligned on byte boundaries. But that result isn't needed for what I say further, so I stipulate only the weaker result that it is possible.) A key observation is that the important word is padding. Used in connection with structs (and unions), "padding bytes" has no meaning beyond "padding that happens to occupy byte-sized units and is aligned on byte boundaries". That may be between two non-bitfield members, or it may be between two members at least one of which is a bitfield. The term "padding bit", /used in connection with structs and unions/, means any bit that does not participate in the value of the struct (or any member of the union). Thus less-than-byte-sized padding "next to" a bitfield member, and also all the bits of any "padding byte", both can be referred to as "padding bits", ie, a bit that is used only for padding and has no effect on the value of the struct (or union) object. The situation with objects of integer type is different. Here "padding bit" is a specialized term with a specific meaning, beyond that of "a bit used only for padding". A padding bit in an integer-type object representation does not participate in the value of the object, but neither is it completely irrelevant, for changing it may produce a trap representation. The same words are used, but with a different meaning. To me it makes sense to use the term "padding bit" in connection with structs/unions, to mean any bit used for padding, regardless of whether all other bits in the same byte are also used for padding. Surely the Standard does not expect that storing into a bitfield member will preserve the values of any bits used for padding that happen to occupy less than a full byte. When storing into a member, the values of any "padding bytes" take unspecified values. The Standard surely also intends that the value of any bit used for padding, even those "byte companion bits" are not all used for padding, take unspecified values when any member is stored into. Performing struct assignment requires copying any bits that participate in the value of the struct object. But it does not require copying any bits that do not participate in the value of the struct. These bits are exactly the "padding bits", ie those bits of the struct object representation that do not correspond to any member. (In the foregoing I have ignored unnamed bitfields and bitfields of zero width, to keep the discussion simple.) All of which leads to this conclusion: IMO the term "padding bits" in the aforementioned footnote is appropriate (and also may have been intended, but that's only speculation). The statement that "padding bytes" may take unspecified values when assigning to a struct member is right, but incomplete: it should be broadened to include bits of padding that do not happen to occupy full bytes, as may occur when there are bitfield members. And finally, used in connection with objects of integer type, "padding bits" is a specialized term that applies only in connection with objects of these types, and means something different than the generic term "padding" used in connection with structs and unions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-27 09:57 -0700 |
| Message-ID | <lnoa5j9fxq.fsf@kst-u.example.com> |
| In reply to | #91150 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> [...]
>>> 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.
>>
>> Richard, I regret that I must correct you. The standard does not use
>> the term "padding bytes" when discussing storage within an integer
>> object that does not contribute to its value. It consistently uses
>> the term "padding bits", without reference to whether the number
>> of such bits may or may not be a multiple of CHAR_BIT.
>>
>> "Padding bytes" are bytes within a structure or union that are
>> not part of one of its members, typically added to meet alignment
>> requirements.
>>
>> A footnote says that "structure assignment need not copy any padding
>> bits". I believe that is an error; it should say "padding bytes".
>
> I have a different reaction to the phrasing used here. Let
> me try to explain.
[BIG SNIP]
> All of which leads to this conclusion: IMO the term "padding
> bits" in the aforementioned footnote is appropriate (and also may
> have been intended, but that's only speculation). The statement
> that "padding bytes" may take unspecified values when assigning
> to a struct member is right, but incomplete: it should be
> broadened to include bits of padding that do not happen to occupy
> full bytes, as may occur when there are bitfield members. And
> finally, used in connection with objects of integer type,
> "padding bits" is a specialized term that applies only in
> connection with objects of these types, and means something
> different than the generic term "padding" used in connection
> with structs and unions.
Just one point: The standard *almost* consistently uses the phrase
"padding bits" to refer to bits in an integer representation that
don't contribute to the value, and "padding bytes" to refer to gaps
in structs or unions. That footnote is the only place that uses
"padding bits" referring to structures (and not unions).
You make a good point about bit fields (I had pretty much ignored
them), and the standard probably should acknowledge more explicitly
that, in the presence of bit fields, padding in structures does not
necessarily consist only of bytes. But I'm skeptical that the use
of the phrase "padding bits" in that footnote (with no reference
to bit fields) was intended to make that point. I think it was
merely a mistake. (And not a particularly egregious one.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-28 11:15 -0700 |
| Message-ID | <kfn37mtpr1x.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91161 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Richard Heathfield <rjh@cpax.org.uk> writes: >>> [...] >>>> 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. >>> >>> Richard, I regret that I must correct you. The standard does not use >>> the term "padding bytes" when discussing storage within an integer >>> object that does not contribute to its value. It consistently uses >>> the term "padding bits", without reference to whether the number >>> of such bits may or may not be a multiple of CHAR_BIT. >>> >>> "Padding bytes" are bytes within a structure or union that are >>> not part of one of its members, typically added to meet alignment >>> requirements. >>> >>> A footnote says that "structure assignment need not copy any padding >>> bits". I believe that is an error; it should say "padding bytes". >> >> I have a different reaction to the phrasing used here. Let >> me try to explain. > > [BIG SNIP] > >> All of which leads to this conclusion: IMO the term "padding >> bits" in the aforementioned footnote is appropriate (and also may >> have been intended, but that's only speculation). The statement >> that "padding bytes" may take unspecified values when assigning >> to a struct member is right, but incomplete: it should be >> broadened to include bits of padding that do not happen to occupy >> full bytes, as may occur when there are bitfield members. And >> finally, used in connection with objects of integer type, >> "padding bits" is a specialized term that applies only in >> connection with objects of these types, and means something >> different than the generic term "padding" used in connection >> with structs and unions. > > Just one point: The standard *almost* consistently uses the phrase > "padding bits" to refer to bits in an integer representation that > don't contribute to the value, and "padding bytes" to refer to gaps > in structs or unions. That footnote is the only place that uses > "padding bits" referring to structures (and not unions). I agree about "padding bits". I believe this phrase is always used in connection with integer types, with just one exception in the aforementioned footnote. I do not agree about "padding bytes". IIANM the phrase "padding bytes" occurs in the Standard exactly twice: once in 6.2.6.1 p6, and again in J.1 p1, summarizing exactly the other occurrence. In most places where the Standard talks about padding in structs (or unions), it uses the more generic term "padding". The usual term is just "padding". The term "padding bytes" is the exception (and nearly a singular one at that), not the rule. > You make a good point about bit fields (I had pretty much ignored > them), and the standard probably should acknowledge more explicitly > that, in the presence of bit fields, padding in structures does not > necessarily consist only of bytes. But I'm skeptical that the use > of the phrase "padding bits" in that footnote (with no reference > to bit fields) was intended to make that point. I think it was > merely a mistake. (And not a particularly egregious one.) Usually I don't think such cases are errors unless there is some sort of other evidence to support such a conclusion. Here I don't know of any. Looking at other passages that talk about padding in structs, to me it looks more likely that "padding bits" is what is meant here. (This assumes "padding bits" is understood to mean those bits in a struct or union object representation that do not participate in the value of any member.) Certainly that description is more complete than just saying "padding bytes" need not be copied. Wouldn't you agree?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-28 15:18 -0700 |
| Message-ID | <lnoa5h76fd.fsf@kst-u.example.com> |
| In reply to | #91258 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> You make a good point about bit fields (I had pretty much ignored
>> them), and the standard probably should acknowledge more explicitly
>> that, in the presence of bit fields, padding in structures does not
>> necessarily consist only of bytes. But I'm skeptical that the use
>> of the phrase "padding bits" in that footnote (with no reference
>> to bit fields) was intended to make that point. I think it was
>> merely a mistake. (And not a particularly egregious one.)
>
> Usually I don't think such cases are errors unless there is some
> sort of other evidence to support such a conclusion. Here I
> don't know of any. Looking at other passages that talk about
> padding in structs, to me it looks more likely that "padding
> bits" is what is meant here. (This assumes "padding bits" is
> understood to mean those bits in a struct or union object
> representation that do not participate in the value of any
> member.) Certainly that description is more complete than just
> saying "padding bytes" need not be copied. Wouldn't you agree?
Sure.
If the standard is going to use the term "padding bits" for both integer
types and structs/unions, IMHO it should be clearer and more consistent
about the terminology. Perhaps there's no need for the phrase "padding
bytes" at all, and it should just be called "padding".
In any case, I don't think anyone outside my killfile really
misunderstands the intended meaning.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-30 11:59 -0700 |
| Message-ID | <kfnd1lvne92.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91283 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: > > [...] > >>> You make a good point about bit fields (I had pretty much ignored >>> them), and the standard probably should acknowledge more explicitly >>> that, in the presence of bit fields, padding in structures does not >>> necessarily consist only of bytes. But I'm skeptical that the use >>> of the phrase "padding bits" in that footnote (with no reference >>> to bit fields) was intended to make that point. I think it was >>> merely a mistake. (And not a particularly egregious one.) >> >> Usually I don't think such cases are errors unless there is some >> sort of other evidence to support such a conclusion. Here I >> don't know of any. Looking at other passages that talk about >> padding in structs, to me it looks more likely that "padding >> bits" is what is meant here. (This assumes "padding bits" is >> understood to mean those bits in a struct or union object >> representation that do not participate in the value of any >> member.) Certainly that description is more complete than just >> saying "padding bytes" need not be copied. Wouldn't you agree? > > Sure. > > If the standard is going to use the term "padding bits" for both > integer types and structs/unions, IMHO it should be clearer and > more consistent about the terminology. Yes, certainly there is some room for improvement here. > Perhaps there's no need for the phrase "padding bytes" at all, and > it should just be called "padding". I think the reason the term "padding bytes" is used is to identify those bytes whose values are fully unspecified. Any byte that has fewer than CHAR_BIT padding bits is at most only partially unspecified (ie, the padding bits are allowed to take on unspecified values, the non-padding bits are not). An exact statement is not easy to formulate. Maybe the comment in the footnote was put in to make up for the inexactness of the normative text. I think most people understand what is meant, even if it is somewhat inexactly expressed. > In any case, I don't think anyone outside my killfile really > misunderstands the intended meaning. Check. My comment was only about the phrasing used to describe the meaning.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-28 21:02 -0400 |
| Message-ID | <nne9ur$bju$1@jstuckle.eternal-september.org> |
| In reply to | #91258 |
On 7/28/2016 2:15 PM, Tim Rentsch wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: >>> Keith Thompson <kst-u@mib.org> writes: >>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>> [...] >>>>> 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. >>>> >>>> Richard, I regret that I must correct you. The standard does not use >>>> the term "padding bytes" when discussing storage within an integer >>>> object that does not contribute to its value. It consistently uses >>>> the term "padding bits", without reference to whether the number >>>> of such bits may or may not be a multiple of CHAR_BIT. >>>> >>>> "Padding bytes" are bytes within a structure or union that are >>>> not part of one of its members, typically added to meet alignment >>>> requirements. >>>> >>>> A footnote says that "structure assignment need not copy any padding >>>> bits". I believe that is an error; it should say "padding bytes". >>> >>> I have a different reaction to the phrasing used here. Let >>> me try to explain. >> >> [BIG SNIP] >> >>> All of which leads to this conclusion: IMO the term "padding >>> bits" in the aforementioned footnote is appropriate (and also may >>> have been intended, but that's only speculation). The statement >>> that "padding bytes" may take unspecified values when assigning >>> to a struct member is right, but incomplete: it should be >>> broadened to include bits of padding that do not happen to occupy >>> full bytes, as may occur when there are bitfield members. And >>> finally, used in connection with objects of integer type, >>> "padding bits" is a specialized term that applies only in >>> connection with objects of these types, and means something >>> different than the generic term "padding" used in connection >>> with structs and unions. >> >> Just one point: The standard *almost* consistently uses the phrase >> "padding bits" to refer to bits in an integer representation that >> don't contribute to the value, and "padding bytes" to refer to gaps >> in structs or unions. That footnote is the only place that uses >> "padding bits" referring to structures (and not unions). > > I agree about "padding bits". I believe this phrase is always > used in connection with integer types, with just one exception > in the aforementioned footnote. > > I do not agree about "padding bytes". IIANM the phrase "padding > bytes" occurs in the Standard exactly twice: once in 6.2.6.1 p6, > and again in J.1 p1, summarizing exactly the other occurrence. In > most places where the Standard talks about padding in structs (or > unions), it uses the more generic term "padding". The usual term > is just "padding". The term "padding bytes" is the exception (and > nearly a singular one at that), not the rule. > At last - someone who actually UNDERSTANDS the standard! -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-30 12:09 -0700 |
| Message-ID | <kfn8twjndsf.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91291 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 7/28/2016 2:15 PM, Tim Rentsch wrote: >> Keith Thompson <kst-u@mib.org> writes: >> >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>> Keith Thompson <kst-u@mib.org> writes: >>>>> Richard Heathfield <rjh@cpax.org.uk> writes: >>>>> [...] >>>>>> 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. >>>>> >>>>> Richard, I regret that I must correct you. The standard does not use >>>>> the term "padding bytes" when discussing storage within an integer >>>>> object that does not contribute to its value. It consistently uses >>>>> the term "padding bits", without reference to whether the number >>>>> of such bits may or may not be a multiple of CHAR_BIT. >>>>> >>>>> "Padding bytes" are bytes within a structure or union that are >>>>> not part of one of its members, typically added to meet alignment >>>>> requirements. >>>>> >>>>> A footnote says that "structure assignment need not copy any padding >>>>> bits". I believe that is an error; it should say "padding bytes". >>>> >>>> I have a different reaction to the phrasing used here. Let >>>> me try to explain. >>> >>> [BIG SNIP] >>> >>>> All of which leads to this conclusion: IMO the term "padding >>>> bits" in the aforementioned footnote is appropriate (and also may >>>> have been intended, but that's only speculation). The statement >>>> that "padding bytes" may take unspecified values when assigning >>>> to a struct member is right, but incomplete: it should be >>>> broadened to include bits of padding that do not happen to occupy >>>> full bytes, as may occur when there are bitfield members. And >>>> finally, used in connection with objects of integer type, >>>> "padding bits" is a specialized term that applies only in >>>> connection with objects of these types, and means something >>>> different than the generic term "padding" used in connection >>>> with structs and unions. >>> >>> Just one point: The standard *almost* consistently uses the phrase >>> "padding bits" to refer to bits in an integer representation that >>> don't contribute to the value, and "padding bytes" to refer to gaps >>> in structs or unions. That footnote is the only place that uses >>> "padding bits" referring to structures (and not unions). >> >> I agree about "padding bits". I believe this phrase is always >> used in connection with integer types, with just one exception >> in the aforementioned footnote. >> >> I do not agree about "padding bytes". IIANM the phrase "padding >> bytes" occurs in the Standard exactly twice: once in 6.2.6.1 p6, >> and again in J.1 p1, summarizing exactly the other occurrence. In >> most places where the Standard talks about padding in structs (or >> unions), it uses the more generic term "padding". The usual term >> is just "padding". The term "padding bytes" is the exception (and >> nearly a singular one at that), not the rule. > > At last - someone who actually UNDERSTANDS the standard! Most so-called language lawyers don't have to deal with the sobering consequences that real lawyers experience when they go through a trial and have a verdict delivered. I try not to get too invested in language-lawyer type arguments, because usually they are pretty much pointless. The key governing body for ISO C is WG14. Unless those arguing about what the Standard "really means" are willing to have their opinions adjudicated by WG14, for the most part it's all just a lot of hot air. And that goes for my comments as well as anyone else's.
[toc] | [prev] | [next] | [standalone]
Page 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web