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 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-27 03:12 +0100 |
| Message-ID | <8737mvq15m.fsf@bsb.me.uk> |
| In reply to | #91104 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 7/26/2016 3:25 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 7/25/2016 8:08 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 7/25/2016 12:07 PM, Ben Bacarisse wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>> >>>>>>> On 7/24/2016 7:24 PM, Ben Bacarisse wrote: >>>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>> <snip> >>>>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>>>> >>>>>>>> Yes it is because there is no limit placed on the number of padding bits >>>>>>>> an integer type can have -- int might have none and short might have >>>>>>>> dozens. There's no reason I can see for an implementation to do this, >>>>>>>> but it's not prohibited by the language. >>>>>>> >>>>>>> There is no allowance for padding BYTES. Only BITS. >>>>>> >>>>>> If there are enough padding bits, sizeof (short) can be > sizeof (int). >>>>>> The padding bits may or may not be consecutive, but they all contribute >>>>>> to the overall size, just as the sign bit and value bits do. This >>>>>> layout, for a four (8-bit) byte short, appears to have nothing that >>>>>> could be called a padding byte, but sizeof (short) must report 4: >>>>>> >>>>>> SPVPVPVP VPVPVPVP VPVPVPVP VPVPVPVP >>>>>> >>>>>> If you don't accept this possibility, please indicate the padding bytes. >>>>> >>>>> So you, too, are going into the realm of the totally absurd. >>>> >>>> Ah. Were you only saying that having sizeof (short) > sizeof (int) is >>>> totally absurd? If so, we agree. I was only disagreeing with the >>>> incorrect statement that it is not permitted. >>> >>> Not at all. I'm saying your example is totally absurd. >> >> Yes it is, but you seem to be reluctant to say if it is permitted or not >> (which, remember, is the only difference of fact as far as I can see). >> Presumably you don't think it is permitted, but since you don't say why >> I can't say much more than it is. The sections the permit is are clear >> and have been cited several times now so there's not much point in going >> over that again. >> >> If you think it is not permitted *because* it is absurd, that introduces >> an unfortunate degree of subjectivity to the standard. Someone else >> might think that having sizeof (void *) > sizeof (int *) is absurd, or >> any of a large number of other permitted peculiarities, and then the >> discussion about what a C implementation may do will become far too >> subjective for my taste (not to say very likely not at all what the >> committee intended). >> >> <snip> > > At least you are admitting your example is absurd. I've said that right from the first correction. sizeof (short) > sizeof (int) is permitted but is not in any way practical or even reasonable. > And no, I will not > say anything so absurd is permitted. None the less it is permitted by the C standard. Your say-so is not required for a conforming implementation. <snip> > But then people with intelligence don't need to make up stupid examples > like that to try to prove a point. The example doesn't prove the point. The point is proved by the text of the language standard that I (and others) have cited. The example was chosen only to find out what you meant by "padding BYTES". You once claimed that this was why sizeof (short) > sizeof (int) was not permitted, so an example without anything that I would call a padding byte was called for to see what on earth it was you meant. At least I now know that "padding BYTES" are not the problem in this one case. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-26 23:35 -0400 |
| Message-ID | <nn9a5o$86m$2@jstuckle.eternal-september.org> |
| In reply to | #91118 |
On 7/26/2016 10:12 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 7/26/2016 3:25 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 7/25/2016 8:08 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 7/25/2016 12:07 PM, Ben Bacarisse wrote: >>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>>> >>>>>>>> On 7/24/2016 7:24 PM, Ben Bacarisse wrote: >>>>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>>> <snip> >>>>>>>>>> And no, sizeof (short) > sizeof (int) is not permitted. >>>>>>>>> >>>>>>>>> Yes it is because there is no limit placed on the number of padding bits >>>>>>>>> an integer type can have -- int might have none and short might have >>>>>>>>> dozens. There's no reason I can see for an implementation to do this, >>>>>>>>> but it's not prohibited by the language. >>>>>>>> >>>>>>>> There is no allowance for padding BYTES. Only BITS. >>>>>>> >>>>>>> If there are enough padding bits, sizeof (short) can be > sizeof (int). >>>>>>> The padding bits may or may not be consecutive, but they all contribute >>>>>>> to the overall size, just as the sign bit and value bits do. This >>>>>>> layout, for a four (8-bit) byte short, appears to have nothing that >>>>>>> could be called a padding byte, but sizeof (short) must report 4: >>>>>>> >>>>>>> SPVPVPVP VPVPVPVP VPVPVPVP VPVPVPVP >>>>>>> >>>>>>> If you don't accept this possibility, please indicate the padding bytes. >>>>>> >>>>>> So you, too, are going into the realm of the totally absurd. >>>>> >>>>> Ah. Were you only saying that having sizeof (short) > sizeof (int) is >>>>> totally absurd? If so, we agree. I was only disagreeing with the >>>>> incorrect statement that it is not permitted. >>>> >>>> Not at all. I'm saying your example is totally absurd. >>> >>> Yes it is, but you seem to be reluctant to say if it is permitted or not >>> (which, remember, is the only difference of fact as far as I can see). >>> Presumably you don't think it is permitted, but since you don't say why >>> I can't say much more than it is. The sections the permit is are clear >>> and have been cited several times now so there's not much point in going >>> over that again. >>> >>> If you think it is not permitted *because* it is absurd, that introduces >>> an unfortunate degree of subjectivity to the standard. Someone else >>> might think that having sizeof (void *) > sizeof (int *) is absurd, or >>> any of a large number of other permitted peculiarities, and then the >>> discussion about what a C implementation may do will become far too >>> subjective for my taste (not to say very likely not at all what the >>> committee intended). >>> >>> <snip> >> >> At least you are admitting your example is absurd. > > I've said that right from the first correction. sizeof (short) > sizeof > (int) is permitted but is not in any way practical or even reasonable. > And I'm saying you are wrong, for the reasons I have stated. >> And no, I will not >> say anything so absurd is permitted. > > None the less it is permitted by the C standard. Your say-so is not > required for a conforming implementation. > Not when you read the standard completely - AND UNDERSTAND WHAT IT SAYS AND DOES NOT SAY. > <snip> >> But then people with intelligence don't need to make up stupid examples >> like that to try to prove a point. > > The example doesn't prove the point. The point is proved by the text of > the language standard that I (and others) have cited. The example was > chosen only to find out what you meant by "padding BYTES". You once > claimed that this was why sizeof (short) > sizeof (int) was not > permitted, so an example without anything that I would call a padding > byte was called for to see what on earth it was you meant. At least I > now know that "padding BYTES" are not the problem in this one case. > And you added padding bits which required additional bytes to store the value, when the purpose of padding bits is only to fill out an incompletely used type, as in the PDP-10 and many DSP chips available today. -- ================== 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-26 20:41 -0700 |
| Message-ID | <a582fc85-babf-4512-9f52-676fa856b5ac@googlegroups.com> |
| In reply to | #91118 |
On Wednesday, July 27, 2016 at 3:33:08 AM UTC+1, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > > > At least you are admitting your example is absurd. > > I've said that right from the first correction. sizeof (short) > sizeof > (int) is permitted but is not in any way practical or even reasonable. > > > And no, I will not > > say anything so absurd is permitted. > > None the less it is permitted by the C standard. Your say-so is not > required for a conforming implementation. > I did vaguely remember some requirement that short be "optimised for memory usage". Presumably "relative to int". So that would seem to forbid sizeof(short) > sizeof(int). But I couldn't find it in an old online standard. > > <snip> > > But then people with intelligence don't need to make up stupid examples > > like that to try to prove a point. > > The example doesn't prove the point. The point is proved by the text of > the language standard that I (and others) have cited. The example was > chosen only to find out what you meant by "padding BYTES". You once > claimed that this was why sizeof (short) > sizeof (int) was not > permitted, so an example without anything that I would call a padding > byte was called for to see what on earth it was you meant. At least I > now know that "padding BYTES" are not the problem in this one case. > Jerry is one of those people who takes a very aggressive stance over nothing. The standard uses the term "padding bits" for unused bits in an type. Clearly they can occupy a contiguous byte, but they are still termed "padding bits" because the information that we occupy 32 bits of memory but have only 24 bits of precision is generally useful, and remains true however those bits are distributed, the information that the trailing octet is padding is only of use if you bypass the C type system and treat the object as raw memory. But this is all very straightforwards. It's maybe worth pointing out, as a curiosity, that shorts are permitted to be larger than ints, but the topic as a whole is so simple as to be scarcely worth discussing.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-07-27 15:04 +0000 |
| Message-ID | <5798cc2d.2785250@news.xs4all.nl> |
| In reply to | #91122 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > I did vaguely remember some requirement that short be "optimised for > memory usage". Presumably "relative to int". So that would seem to > forbid sizeof(short) > sizeof(int). But I couldn't find it in an > old online standard. That would be because it isn't there. The C99 rationale, in its discussion of long long section 6.2.5, does say some things about the reason for short's existence, but nothing on the line of short having to be shorter than int (quite the contrary), nor that short _has_ to be optimised for anything. (It also does away with the notion that it's reasonable to expect ints to be the same size everywhere, so that's nice, too.) Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-27 16:05 +0100 |
| Message-ID | <87bn1jf7et.fsf@bsb.me.uk> |
| In reply to | #91122 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > ... The standard uses the term "padding bits" for unused bits > in an type. I know what you mean but I wouldn't call them unused because they might be very important. They don't contribute to the value, that's all. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-27 08:17 -0700 |
| Message-ID | <731964a8-0f1e-4028-8570-85812226b611@googlegroups.com> |
| In reply to | #91140 |
On Wednesday, July 27, 2016 at 4:05:38 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > <snip> > > ... The standard uses the term "padding bits" for unused bits > > in an type. > > I know what you mean but I wouldn't call them unused because they might > be very important. They don't contribute to the value, that's all. > They could be parity bits. What's not allowed is "longs runs of zero breaking up bits" (some hardware doesn't like long runs of identical bits, for electronics reasons, you need a "rising edge" every so often to keep the clock happy). All bits zero has to mean 0, including padding.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-27 09:21 -0700 |
| Message-ID | <lnwpk79hlx.fsf@kst-u.example.com> |
| In reply to | #91143 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, July 27, 2016 at 4:05:38 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> <snip>
>> > ... The standard uses the term "padding bits" for unused bits
>> > in an type.
>>
>> I know what you mean but I wouldn't call them unused because they might
>> be very important. They don't contribute to the value, that's all.
And padding bits are defined only for integer types. Other types
might have bits that don't contribute to an object's value, but
the standard doesn't specify any other types' representations in
enough details for it to be necessary to talk about padding bits.
(The term "padding bytes", as I've discussed, is used for gaps in
structures and unions.)
> They could be parity bits.
Yes. Some combinations of values of padding bits can result in trap
representations.
> What's not allowed is "longs runs of zero breaking up bits" (some hardware
> doesn't like long runs of identical bits, for electronics reasons, you need
> a "rising edge" every so often to keep the clock happy).
Please cite the text in the standard that disallows "longs runs of zero
breaking up bits". While you're at it, please explain what "longs runs
of zero breaking up bits" means.
> All bits zero has to mean 0, including padding.
Yes. And the standard requires all-bits-zero to be a valid
representation of 0 for any integer type (that requirement wasn't
explicitly added until one of the post-C99 Technical Corrigenda).
Setting a floating-point or pointer object to all-bits-zero could
result in a trap representation (though it typically doesn't).
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-27 09:37 -0700 |
| Message-ID | <28a49a6a-7e67-441f-853a-2e2ebd84a3d5@googlegroups.com> |
| In reply to | #91154 |
On Wednesday, July 27, 2016 at 5:21:53 PM UTC+1, Keith Thompson wrote: > > Please cite the text in the standard that disallows "longs runs of zero > breaking up bits". While you're at it, please explain what "longs runs > of zero breaking up bits" means. > Sometimes hardware is designed so that the bits are pushed down a wire. Voltage is high for zero, low for set, and each bit takes a microsecond (or whatever). So if we want to send 0x41 we start off with voltage high, then after two microseconds it goes low, then after another microsecond it goes high again, then it stays high for five microseconds, then it goes low again. The receiver has a clock which counts out the bits. But what happens if we send a long run of zero bits? The problem is that the two clocks, the sender and the receiver, might not tick at exactly the same rate. So you won't know if you've sent a thousand or thousand and one zero bits. If you have regular voltage changes, they use that to synch, and they can always distinguish two or three bits from one bit or four bits. So a solution is to have a few unused bits which are set to alternating values. So whatever the data, you don't get long runs of identical bits being sent. Padding bits could be part of that strategy, but not in C, because of the "all bits clear = zero" rule. If user wants to represent an array of zero integer values, C allows him to memset a buffer to zero.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-27 10:11 -0700 |
| Message-ID | <lnd1lz9fbi.fsf@kst-u.example.com> |
| In reply to | #91157 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, July 27, 2016 at 5:21:53 PM UTC+1, Keith Thompson wrote:
>> Please cite the text in the standard that disallows "longs runs of zero
>> breaking up bits". While you're at it, please explain what "longs runs
>> of zero breaking up bits" means.
>>
> Sometimes hardware is designed so that the bits are pushed down a wire.
> Voltage is high for zero, low for set, and each bit takes a microsecond
> (or whatever). So if we want to send 0x41 we start off with voltage high,
> then after two microseconds it goes low, then after another microsecond it
> goes high again, then it stays high for five microseconds, then it goes low
> again. The receiver has a clock which counts out the bits.
> But what happens if we send a long run of zero bits? The problem is that
> the two clocks, the sender and the receiver, might not tick at exactly the
> same rate. So you won't know if you've sent a thousand or thousand and one
> zero bits. If you have regular voltage changes, they use that to synch,
> and they can always distinguish two or three bits from one bit or four bits.
>
> So a solution is to have a few unused bits which are set to alternating values.
> So whatever the data, you don't get long runs of identical bits being sent.
> Padding bits could be part of that strategy, but not in C, because of the
> "all bits clear = zero" rule. If user wants to represent an array of zero
> integer values, C allows him to memset a buffer to zero.
I have no idea how or whether that was intended to answer
my question. If you're just saying that all-bits-zero must be
a valid representation of 0 for any integer type, then that's
correct. If you're saying that that has something to do with data
transmission, it sounds like nonsense to me. Communication protocols
just have to be designed to work correctly for any sequence of bits.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-27 10:21 -0700 |
| Message-ID | <93322761-a388-4b8e-8e17-7449b9321a14@googlegroups.com> |
| In reply to | #91163 |
On Wednesday, July 27, 2016 at 6:11:23 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Have no idea how or whether that was intended to answer > my question. If you're just saying that all-bits-zero must be > a valid representation of 0 for any integer type, then that's > correct. If you're saying that that has something to do with data > transmission, it sounds like nonsense to me. Communication protocols > just have to be designed to work correctly for any sequence of bits. > You also often pass data about internally. You can add bits at a lower level, and in fact that's what you have to do if you allow arbitrary, standards-compliant C programs to run on your device. But of course you're adding complexity and slowing data transfer down.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-27 11:34 -0700 |
| Message-ID | <ln8twn9bh7.fsf@kst-u.example.com> |
| In reply to | #91165 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, July 27, 2016 at 6:11:23 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> Have no idea how or whether that was intended to answer
>> my question. If you're just saying that all-bits-zero must be
>> a valid representation of 0 for any integer type, then that's
>> correct. If you're saying that that has something to do with data
>> transmission, it sounds like nonsense to me. Communication protocols
>> just have to be designed to work correctly for any sequence of bits.
>>
> You also often pass data about internally.
> You can add bits at a lower level, and in fact that's what you have to do
> if you allow arbitrary, standards-compliant C programs to run on your
> device. But of course you're adding complexity and slowing data
> transfer down.
Malcolm, I'm trying (and so far failing) to understand what you're
talking about.
I *think* you're saying that there is some advantage in avoiding
long sequences of zero bits, because they can make it difficult to
transmit data correctly in some contexts. I don't believe that,
but perhaps it's based on something you know about low-level hardware
that I don't. As far as I know, communication protocols, on whatever
level, are required to work correctly regardless of whether the
data being transmitted is all zeros, all 1s, alternating 0s and 1s,
or whatever. A protocol that can't reliably tell the difference
between 99 consecutive 0 bits and 100 consecutive 0 bits is quite
simply broken.
I think you're also saying that this has some relevance to how
types are represented. I don't believe that either. No doubt some
communication protocols use some kind of in-band synchronization, but
there's no reason for that to influence how values are represented
in memory.
--
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 | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-07-27 14:46 -0700 |
| Message-ID | <20755fc2-a421-47d2-bae9-f7451f9fb7f8@googlegroups.com> |
| In reply to | #91167 |
On Wednesday, July 27, 2016 at 1:34:17 PM UTC-5, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > On Wednesday, July 27, 2016 at 6:11:23 PM UTC+1, Keith Thompson wrote: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> Have no idea how or whether that was intended to answer > >> my question. If you're just saying that all-bits-zero must be > >> a valid representation of 0 for any integer type, then that's > >> correct. If you're saying that that has something to do with data > >> transmission, it sounds like nonsense to me. Communication protocols > >> just have to be designed to work correctly for any sequence of bits. > >> > > You also often pass data about internally. > > You can add bits at a lower level, and in fact that's what you have to do > > if you allow arbitrary, standards-compliant C programs to run on your > > device. But of course you're adding complexity and slowing data > > transfer down. > > Malcolm, I'm trying (and so far failing) to understand what you're > talking about. > > I *think* you're saying that there is some advantage in avoiding > long sequences of zero bits, because they can make it difficult to > transmit data correctly in some contexts. I don't believe that, > but perhaps it's based on something you know about low-level hardware > that I don't. As far as I know, communication protocols, on whatever > level, are required to work correctly regardless of whether the > data being transmitted is all zeros, all 1s, alternating 0s and 1s, > or whatever. A protocol that can't reliably tell the difference > between 99 consecutive 0 bits and 100 consecutive 0 bits is quite > simply broken. AIUI paper tape could lose structural integrity if too many holes were punched. But it seems you can always select a set of safe physical representation and devise a higher-level encoding over that alphabet. cf. eg. Iverson and Brooks, Automatic Data Processing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-27 22:29 +0200 |
| Message-ID | <nnb5ic$fjg$1@dont-email.me> |
| In reply to | #91167 |
On 27/07/16 20:34, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> On Wednesday, July 27, 2016 at 6:11:23 PM UTC+1, Keith Thompson wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> Have no idea how or whether that was intended to answer >>> my question. If you're just saying that all-bits-zero must be >>> a valid representation of 0 for any integer type, then that's >>> correct. If you're saying that that has something to do with data >>> transmission, it sounds like nonsense to me. Communication protocols >>> just have to be designed to work correctly for any sequence of bits. >>> >> You also often pass data about internally. >> You can add bits at a lower level, and in fact that's what you have to do >> if you allow arbitrary, standards-compliant C programs to run on your >> device. But of course you're adding complexity and slowing data >> transfer down. > > Malcolm, I'm trying (and so far failing) to understand what you're > talking about. > > I *think* you're saying that there is some advantage in avoiding > long sequences of zero bits, because they can make it difficult to > transmit data correctly in some contexts. I don't believe that, > but perhaps it's based on something you know about low-level hardware > that I don't. As far as I know, communication protocols, on whatever > level, are required to work correctly regardless of whether the > data being transmitted is all zeros, all 1s, alternating 0s and 1s, > or whatever. A protocol that can't reliably tell the difference > between 99 consecutive 0 bits and 100 consecutive 0 bits is quite > simply broken. You are entirely correct (about communication protocols - I can't be sure if you are correct about what Malcolm is saying, but it sounds plausible). For example, if you are going to send a string of 100 consecutive 0 bits over Ethernet as part of a telegram, then as far as the cpu is concerned - and therefore as far as C is concerned - there are 100 zeros sitting in a row. This even applies in the Ethernet driver software. The Ethernet MAC, the digital part of the Ethernet hardware, will do some encoding and padding such as 8b/10b or 63b/64b (I don't remember the details - they vary depending on the Ethernet speed) in order to avoid long runs of unchanged values (long runs of zeros or long runs of ones), to keep a roughly 0.5 DC bias, and to add special control signals for start of frame, and so on. The Ethernet PHY (the analogue part of the hardware, which varies according to media type) will translate that into something else, which might be combining several bits into a multi-level signal, flashes of light, Manchester encoded pulses, or whatever. At the other end, the process is reversed. At no point does the cpu or the C code see the coding or padding - it just sees the string of 100 consecutive 0 bits. This applies regardless of what padding bits the particular machine might use in the cpu. So Malcolm is describing a type of padding bit that is relevant in electronics and communications protocols, but completely irrelevant in a discussion of C or of cpu details. > > I think you're also saying that this has some relevance to how > types are represented. I don't believe that either. No doubt some > communication protocols use some kind of in-band synchronization, but > there's no reason for that to influence how values are represented > in memory. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-27 20:32 +0200 |
| Message-ID | <nnaunl$lii$1@dont-email.me> |
| In reply to | #91157 |
On 27/07/16 18:37, Malcolm McLean wrote: > On Wednesday, July 27, 2016 at 5:21:53 PM UTC+1, Keith Thompson wrote: >> >> Please cite the text in the standard that disallows "longs runs of zero >> breaking up bits". While you're at it, please explain what "longs runs >> of zero breaking up bits" means. >> > Sometimes hardware is designed so that the bits are pushed down a wire. > Voltage is high for zero, low for set, and each bit takes a microsecond > (or whatever). So if we want to send 0x41 we start off with voltage high, > then after two microseconds it goes low, then after another microsecond it > goes high again, then it stays high for five microseconds, then it goes low > again. The receiver has a clock which counts out the bits. > But what happens if we send a long run of zero bits? The problem is that > the two clocks, the sender and the receiver, might not tick at exactly the > same rate. So you won't know if you've sent a thousand or thousand and one > zero bits. If you have regular voltage changes, they use that to synch, > and they can always distinguish two or three bits from one bit or four bits. > > So a solution is to have a few unused bits which are set to alternating values. > So whatever the data, you don't get long runs of identical bits being sent. > Padding bits could be part of that strategy, but not in C, because of the > "all bits clear = zero" rule. If user wants to represent an array of zero > integer values, C allows him to memset a buffer to zero. > This all sounds like you read something about UARTs (good old-fashioned serial ports) many eons ago, and somewhere along the line you heard of terms such as "bit stuffing" or perhaps "8b/10b encoding". While it is certainly true that bit stuffing or other encoding techniques are often used in serial communication to ensure a minimum rate of transitions, it is not remotely related to C or the format used for storing integers in processors. Even in processors that shuffle their data around serially rather than in parallel (such processors do exist), you would not have extra padding bits in order to ensure extra transitions.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-28 00:22 -0700 |
| Message-ID | <72841c31-8c5a-4e65-affa-23376c48128f@googlegroups.com> |
| In reply to | #91166 |
On Wednesday, July 27, 2016 at 7:32:30 PM UTC+1, David Brown wrote: > > This all sounds like you read something about UARTs (good old-fashioned > serial ports) many eons ago, and somewhere along the line you heard of > terms such as "bit stuffing" or perhaps "8b/10b encoding". > > While it is certainly true that bit stuffing or other encoding > techniques are often used in serial communication to ensure a minimum > rate of transitions, it is not remotely related to C or the format used > for storing integers in processors. Even in processors that shuffle > their data around serially rather than in parallel (such processors do > exist), you would not have extra padding bits in order to ensure extra > transitions. > Apparently the problem has resurfaced again. I read an article describing how some modern consumer electronics had failed for that reason.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-07-28 13:01 +0200 |
| Message-ID | <nncomo$vd8$1@dont-email.me> |
| In reply to | #91210 |
On 28/07/16 09:22, Malcolm McLean wrote: > On Wednesday, July 27, 2016 at 7:32:30 PM UTC+1, David Brown wrote: >> >> This all sounds like you read something about UARTs (good old-fashioned >> serial ports) many eons ago, and somewhere along the line you heard of >> terms such as "bit stuffing" or perhaps "8b/10b encoding". >> >> While it is certainly true that bit stuffing or other encoding >> techniques are often used in serial communication to ensure a minimum >> rate of transitions, it is not remotely related to C or the format used >> for storing integers in processors. Even in processors that shuffle >> their data around serially rather than in parallel (such processors do >> exist), you would not have extra padding bits in order to ensure extra >> transitions. >> > Apparently the problem has resurfaced again. I read an article describing > how some modern consumer electronics had failed for that reason. > Without a good deal more detail, that post is of no help to anyone. What problem? When did it exist before, how was it solved, why has it resurfaced? What article? What consumer electronics? How did it fail, why did it fail, and what are the consequences of the failure? And with appropriate detail, it would be completely off-topic for this newsgroup and this thread. It might still be interesting, at least to me - communication and codings are part of my line of work. But it certainly has nothing to do with C. Why not simply post a link to the article for those who might be interested, and leave it at that?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-28 04:46 -0700 |
| Message-ID | <48762306-c064-4787-aaf7-05adb4afac9d@googlegroups.com> |
| In reply to | #91219 |
On Thursday, July 28, 2016 at 12:01:50 PM UTC+1, David Brown wrote: > On 28/07/16 09:22, Malcolm McLean wrote: > > On Wednesday, July 27, 2016 at 7:32:30 PM UTC+1, David Brown wrote: > >> > >> This all sounds like you read something about UARTs (good old-fashioned > >> serial ports) many eons ago, and somewhere along the line you heard of > >> terms such as "bit stuffing" or perhaps "8b/10b encoding". > >> > >> While it is certainly true that bit stuffing or other encoding > >> techniques are often used in serial communication to ensure a minimum > >> rate of transitions, it is not remotely related to C or the format used > >> for storing integers in processors. Even in processors that shuffle > >> their data around serially rather than in parallel (such processors do > >> exist), you would not have extra padding bits in order to ensure extra > >> transitions. > >> > > Apparently the problem has resurfaced again. I read an article describing > > how some modern consumer electronics had failed for that reason. > > > > Without a good deal more detail, that post is of no help to anyone. > What problem? When did it exist before, how was it solved, why has it > resurfaced? What article? What consumer electronics? How did it fail, > why did it fail, and what are the consequences of the failure? > > And with appropriate detail, it would be completely off-topic for this > newsgroup and this thread. It might still be interesting, at least to > me - communication and codings are part of my line of work. But it > certainly has nothing to do with C. > > Why not simply post a link to the article for those who might be > interested, and leave it at that? > I can't remember the article exactly. I think it was something to do with a digital camera taking very dark pictures, which created long runs of zero bytes. They then used NRZ (the form of binary encoding that creates the problem) to page out core to backing store. But I couldn't find it and I might have misremembered.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-26 12:57 -0700 |
| Message-ID | <471ad0e8-597e-4f13-85c4-5584010be0fb@googlegroups.com> |
| In reply to | #91103 |
On Tuesday, July 26, 2016 at 2:26:09 PM UTC-5, Ben Bacarisse wrote: > If you think it is not permitted *because* it is absurd, that introduces > an unfortunate degree of subjectivity to the standard. The authors of the Standard recognized the possibility that an implementation could be fully compliant and yet be of such poor quality as to be useless, but for whatever reason make almost no effort to describe what is necessary for an implementation to be considered "good". For over a decade before the C89 Standard was written, compiler writers had demonstrated a substantial degree of common sense in how platform constructs mapped to language constructs. In cases where it would make sense for different platforms to define things different ways, or for some platforms to define behaviors that are left undefined in others, the authors of the Standard probably expected that compilers writers didn't need to be told that if compilers targeting a certain platform though it made sense to define things a certain way before C89 was published, they would continue to do so afterward whether or not the Standard mandated it, and labeling the behavior as "undefined" would merely maintain the status quo in which good compilers for the platform would support the behavior. I haven't been able to find a whole lot of detail about the history of gcc between the time development forked and when the branches were merged, but it seems some major philosophical change happened during that time which assumed that the compiler shouldn't try to make any behavioral guarantees beyond those mandated by the Standard, regardless of what any prior norms for the target platform might have been.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-07-26 16:00 -0400 |
| Message-ID | <e04dc7f1-2f0a-4612-1a49-3216ca1e7d47@verizon.net> |
| In reply to | #91103 |
On 07/26/2016 03:25 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: ... >> Not at all. I'm saying your example is totally absurd. > > Yes it is, but you seem to be reluctant to say if it is permitted or not > (which, remember, is the only difference of fact as far as I can see). > Presumably you don't think it is permitted, but since you don't say why > I can't say much more than it is. The sections the permit is are clear > and have been cited several times now so there's not much point in going > over that again. > > If you think it is not permitted *because* it is absurd, that introduces > an unfortunate degree of subjectivity to the standard. It's not subjective - whatever Joe Stuckle considers absurd is not permitted; no one else's opinions matter unless they agree with him. Those who don't agree with him, by definition, don't have what he considers to be "the modicum of intelligence" needed for C. What the standard actually says is completely irrelevant. I'm quite comfortable in the assumption that if the C committee itself issued a formal ruling that he disagreed with, he'd simply reject that ruling with the claim that this was due the committee's lacking that same modicum of intelligence. It might be enlightening to see what his opinions might be of the decisions they've already made: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm> - or perhaps not. I've disagreed with some committee rulings, but I also recognize that the committee (and no one else) has the legitimate authority to make such rulings, and that their decision to rule in a given way on a given issue must be coped with unless and until someone convinces them to change that decision.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-07-24 00:08 -0700 |
| Message-ID | <e94cfe83-cb96-4a83-9a10-6fb5b76a9941@googlegroups.com> |
| In reply to | #90883 |
On Saturday, July 23, 2016 at 10:53:41 PM UTC+1, Jerry Stuckle wrote: > On 7/23/2016 4:38 PM, Malcolm McLean wrote: > > > magptr = malloc(40 * sizeof(int)) > > > > means allocate 160 bytes and assign to magptr. Which almost always > > will be a buffer of 40 ints. Possible bugs, someone has changed > > magptr to use a type other than int, someone has changed the > > algorithm to require more than 40 integers. > > > > 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. > Often, an int is necessarily 4 bytes. In the context of the program. sizeof() allows the code to work on machines where that isn't true, and documents that the purpose of the allocation is to hold ints. Often it's helpful to have see-through wrappers. Many people have minds that work that way. It's easier to think in terms of known quantities rather than more abstract ones. If we can see an expression and there's an automatic, trivial translation to a number, it's easier to read than if there is not. Whilst sizeof() allows code to be agnostic about the width of an int, it doesn't guarantee it. Most programs will probably break if the width of int is redefined.
[toc] | [prev] | [next] | [standalone]
Page 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web