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 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-24 21:58 -0600 |
| Message-ID | <1bd1m2gyhc.fsf@pfeifferfamily.net> |
| In reply to | #90946 |
Keith Thompson <kst-u@mib.org> writes: > jameskuyper@verizon.net writes: > [...] >> There are CHAR_BIT padding bits in a padding byte. > [...] > > As I just mentioned in response to Richard Heathfield, the standard > (almost) consistently uses the the term "padding bits" to refer to > bits within the representation of an integer that do not contribute > to its value, and "padding bytes" to refer to bytes within the > representation of a structure or union that are not part of the > representation of any member. > > A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits. > The collection, though it happens to be the same size as a byte, > might not even be addressible, which means it would not meet the > standard's definition of a "byte". IIRC, you've (wisely -- why did I let myself get drawn into this?) killfiled Jerry. He seems to be clinging to a notion that adding enough padding bits to make a byte is adding padding bytes, and then arguing that the standard somehow doesn't allow this. Several people have been trying to get him to explain this logic, with (not surprisingly) no luck so far.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 08:19 -0400 |
| Message-ID | <nn503a$d9r$2@jstuckle.eternal-september.org> |
| In reply to | #90958 |
On 7/24/2016 11:58 PM, Joe Pfeiffer wrote: > Keith Thompson <kst-u@mib.org> writes: > >> jameskuyper@verizon.net writes: >> [...] >>> There are CHAR_BIT padding bits in a padding byte. >> [...] >> >> As I just mentioned in response to Richard Heathfield, the standard >> (almost) consistently uses the the term "padding bits" to refer to >> bits within the representation of an integer that do not contribute >> to its value, and "padding bytes" to refer to bytes within the >> representation of a structure or union that are not part of the >> representation of any member. >> >> A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits. >> The collection, though it happens to be the same size as a byte, >> might not even be addressible, which means it would not meet the >> standard's definition of a "byte". > > IIRC, you've (wisely -- why did I let myself get drawn into this?) > killfiled Jerry. He seems to be clinging to a notion that adding enough > padding bits to make a byte is adding padding bytes, and then arguing > that the standard somehow doesn't allow this. Several people have been > trying to get him to explain this logic, with (not surprisingly) no luck > so far. > No, I never said anything of the sort. What I said was adding enough bits to require additional bytes only used for padding is not allowed. A huge difference. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-07-25 08:34 -0600 |
| Message-ID | <1b8twphjmb.fsf@pfeifferfamily.net> |
| In reply to | #90978 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 7/24/2016 11:58 PM, Joe Pfeiffer wrote: >> Keith Thompson <kst-u@mib.org> writes: >> >>> jameskuyper@verizon.net writes: >>> [...] >>>> There are CHAR_BIT padding bits in a padding byte. >>> [...] >>> >>> As I just mentioned in response to Richard Heathfield, the standard >>> (almost) consistently uses the the term "padding bits" to refer to >>> bits within the representation of an integer that do not contribute >>> to its value, and "padding bytes" to refer to bytes within the >>> representation of a structure or union that are not part of the >>> representation of any member. >>> >>> A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits. >>> The collection, though it happens to be the same size as a byte, >>> might not even be addressible, which means it would not meet the >>> standard's definition of a "byte". >> >> IIRC, you've (wisely -- why did I let myself get drawn into this?) >> killfiled Jerry. He seems to be clinging to a notion that adding enough >> padding bits to make a byte is adding padding bytes, and then arguing >> that the standard somehow doesn't allow this. Several people have been >> trying to get him to explain this logic, with (not surprisingly) no luck >> so far. >> > > No, I never said anything of the sort. What I said was adding enough > bits to require additional bytes only used for padding is not allowed. > A huge difference. You see a difference between "...adding padding bytes..." and "...require additional bytes only used for padding..."? How is a padding byte anything other than an additional byte used only for padding?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 12:01 -0400 |
| Message-ID | <nn5d3l$r6q$2@jstuckle.eternal-september.org> |
| In reply to | #90997 |
On 7/25/2016 10:34 AM, Joe Pfeiffer wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 7/24/2016 11:58 PM, Joe Pfeiffer wrote: >>> Keith Thompson <kst-u@mib.org> writes: >>> >>>> jameskuyper@verizon.net writes: >>>> [...] >>>>> There are CHAR_BIT padding bits in a padding byte. >>>> [...] >>>> >>>> As I just mentioned in response to Richard Heathfield, the standard >>>> (almost) consistently uses the the term "padding bits" to refer to >>>> bits within the representation of an integer that do not contribute >>>> to its value, and "padding bytes" to refer to bytes within the >>>> representation of a structure or union that are not part of the >>>> representation of any member. >>>> >>>> A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits. >>>> The collection, though it happens to be the same size as a byte, >>>> might not even be addressible, which means it would not meet the >>>> standard's definition of a "byte". >>> >>> IIRC, you've (wisely -- why did I let myself get drawn into this?) >>> killfiled Jerry. He seems to be clinging to a notion that adding enough >>> padding bits to make a byte is adding padding bytes, and then arguing >>> that the standard somehow doesn't allow this. Several people have been >>> trying to get him to explain this logic, with (not surprisingly) no luck >>> so far. >>> >> >> No, I never said anything of the sort. What I said was adding enough >> bits to require additional bytes only used for padding is not allowed. >> A huge difference. > > You see a difference between "...adding padding bytes..." and > "...require additional bytes only used for padding..."? How is a > padding byte anything other than an additional byte used only for > padding? > That is not what you claimed I said. Do you see the difference? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-25 08:32 -0700 |
| Message-ID | <96a68283-3c5d-4052-9f1e-37442a59e0a5@googlegroups.com> |
| In reply to | #90978 |
On Monday, July 25, 2016 at 8:18:58 AM UTC-4, Jerry Stuckle wrote: > On 7/24/2016 11:58 PM, Joe Pfeiffer wrote: > > Keith Thompson <kst-u@mib.org> writes: > > > >> jameskuyper@verizon.net writes: > >> [...] > >>> There are CHAR_BIT padding bits in a padding byte. > >> [...] > >> > >> As I just mentioned in response to Richard Heathfield, the standard > >> (almost) consistently uses the the term "padding bits" to refer to > >> bits within the representation of an integer that do not contribute > >> to its value, and "padding bytes" to refer to bytes within the > >> representation of a structure or union that are not part of the > >> representation of any member. > >> > >> A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits. > >> The collection, though it happens to be the same size as a byte, > >> might not even be addressible, which means it would not meet the > >> standard's definition of a "byte". > > > > IIRC, you've (wisely -- why did I let myself get drawn into this?) > > killfiled Jerry. He seems to be clinging to a notion that adding enough > > padding bits to make a byte is adding padding bytes, and then arguing > > that the standard somehow doesn't allow this. Several people have been > > trying to get him to explain this logic, with (not surprisingly) no luck > > so far. > > > > No, I never said anything of the sort. What I said was adding enough > bits to require additional bytes only used for padding is not allowed. > A huge difference. But no one has yet suggesting adding that many bits. 8 bits can be added to 1 sign bit and 15 value bits without putting all 8 bits in a single byte. The minimum number of padding bits required to force the existence of a padding byte is 120: 1 byte containing 1 sign bit and 7 padding bits, 15 bytes each containing one value bit and 7 padding bits, and 1 byte containing 8 padding bits. While I do believe such a type is permitted by the C standard, no one has yet discussed that fact in this thread. Obviously, no real implementation would use such a type - but your claim was not merely that "no one would ever do this", but the much more extreme claim "it is not permitted".
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 12:03 -0400 |
| Message-ID | <nn5d86$r6q$3@jstuckle.eternal-september.org> |
| In reply to | #91007 |
On 7/25/2016 11:32 AM, jameskuyper@verizon.net wrote: > On Monday, July 25, 2016 at 8:18:58 AM UTC-4, Jerry Stuckle wrote: >> On 7/24/2016 11:58 PM, Joe Pfeiffer wrote: >>> Keith Thompson <kst-u@mib.org> writes: >>> >>>> jameskuyper@verizon.net writes: >>>> [...] >>>>> There are CHAR_BIT padding bits in a padding byte. >>>> [...] >>>> >>>> As I just mentioned in response to Richard Heathfield, the standard >>>> (almost) consistently uses the the term "padding bits" to refer to >>>> bits within the representation of an integer that do not contribute >>>> to its value, and "padding bytes" to refer to bytes within the >>>> representation of a structure or union that are not part of the >>>> representation of any member. >>>> >>>> A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits. >>>> The collection, though it happens to be the same size as a byte, >>>> might not even be addressible, which means it would not meet the >>>> standard's definition of a "byte". >>> >>> IIRC, you've (wisely -- why did I let myself get drawn into this?) >>> killfiled Jerry. He seems to be clinging to a notion that adding enough >>> padding bits to make a byte is adding padding bytes, and then arguing >>> that the standard somehow doesn't allow this. Several people have been >>> trying to get him to explain this logic, with (not surprisingly) no luck >>> so far. >>> >> >> No, I never said anything of the sort. What I said was adding enough >> bits to require additional bytes only used for padding is not allowed. >> A huge difference. > > But no one has yet suggesting adding that many bits. 8 bits can be added to 1 sign bit and 15 value bits without putting all 8 bits in a single byte. The minimum number of padding bits required to force the existence of a padding byte is 120: 1 byte containing 1 sign bit and 7 padding bits, 15 bytes each containing one value bit and 7 padding bits, and 1 byte containing 8 padding bits. While I do believe such a type is permitted by the C standard, no one has yet discussed that fact in this thread. Obviously, no real implementation would use such a type - but your claim was not merely that "no one would ever do this", but the much more extreme claim "it is not permitted". > How about coming back from your trip to Wonderland with Alice and join the real world? Show me ONE COMPILER in the entire world - in ANY language - which implements such a stupid concept? Otherwise your argument is more of the same BS. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-25 00:24 +0100 |
| Message-ID | <87wpkar54r.fsf@bsb.me.uk> |
| In reply to | #90901 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 7/23/2016 8:52 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 7/23/2016 4:38 PM, Malcolm McLean wrote: >> <snip> >>>> 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. >> >> That last bit true of what C calls the width of the types (the number of >> value bits plus one for signed types) but, because of the possibility of >> padding bits, it's not true of the size in bytes. Of course it's almost >> inconceivable that any real implementation would have, for example, >> sizeof (short) > sizeof (int) but it is permitted. >> >> <snip> > > It is also the size in bytes. Size of an int does not include any > padding. No, see 6.2.6.2 -- particularly paragraphs 1 and 2. int objects may have padding bits, and these must be included in the size (in bytes) given by sizeof (int). It follows that an integer type's width plus the number of padding bits is always a multiple of CHAR_BIT. > 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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-24 21:01 -0400 |
| Message-ID | <nn3odc$6ca$5@jstuckle.eternal-september.org> |
| In reply to | #90925 |
On 7/24/2016 7:24 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 7/23/2016 8:52 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 7/23/2016 4:38 PM, Malcolm McLean wrote: >>> <snip> >>>>> 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. >>> >>> That last bit true of what C calls the width of the types (the number of >>> value bits plus one for signed types) but, because of the possibility of >>> padding bits, it's not true of the size in bytes. Of course it's almost >>> inconceivable that any real implementation would have, for example, >>> sizeof (short) > sizeof (int) but it is permitted. >>> >>> <snip> >> >> It is also the size in bytes. Size of an int does not include any >> padding. > > No, see 6.2.6.2 -- particularly paragraphs 1 and 2. int objects may > have padding bits, and these must be included in the size (in bytes) > given by sizeof (int). It follows that an integer type's width plus the > number of padding bits is always a multiple of CHAR_BIT. > Exactly. The implementation may have padding BITS. Nothing says it can have padding BYTES. >> 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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-07-25 17:08 +1200 |
| Message-ID | <dvll5gFfb5cU2@mid.individual.net> |
| In reply to | #90933 |
On 07/25/16 01:01 PM, Jerry Stuckle wrote: > > There is no allowance for padding BYTES. Only BITS. C99 3.6 note 2: "A byte is composed of a contiguous sequence of bits, the number of which is implementation-defined." -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 08:19 -0400 |
| Message-ID | <nn504e$d9r$3@jstuckle.eternal-september.org> |
| In reply to | #90961 |
On 7/25/2016 1:08 AM, Ian Collins wrote: > On 07/25/16 01:01 PM, Jerry Stuckle wrote: >> >> There is no allowance for padding BYTES. Only BITS. > > C99 3.6 note 2: > > "A byte is composed of a contiguous sequence of bits, the number of > which is implementation-defined." > So what? Other than showing you have no idea what the discussion is about. But that's not unusual for you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-25 17:07 +0100 |
| Message-ID | <87d1m1r99c.fsf@bsb.me.uk> |
| In reply to | #90933 |
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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 12:36 -0400 |
| Message-ID | <nn5f61$310$1@jstuckle.eternal-september.org> |
| In reply to | #91019 |
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. Show me ONE compiler - in ANY language - which supports such a ridiculous concept. Otherwise, you're as full of BS as some others here. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-25 10:34 -0700 |
| Message-ID | <89792b7f-b4a6-423a-951b-036317820e45@googlegroups.com> |
| In reply to | #91026 |
On Monday, July 25, 2016 at 12:36:26 PM UTC-4, Jerry Stuckle wrote: > On 7/25/2016 12:07 PM, Ben Bacarisse wrote: ... > > 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. Show me > ONE compiler - in ANY language - which supports such a ridiculous > concept. No one has suggested that any real compiler uses such a representation, just as no one has suggested that any real compiler has sizeof(short) > sizeof(int). All that we are disputing is your claim that it is not permitted. The representation described above is, in fact, permitted - but nobody in their right minds would ever use it.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 15:05 -0400 |
| Message-ID | <nn5nu8$5a5$2@jstuckle.eternal-september.org> |
| In reply to | #91038 |
On 7/25/2016 1:34 PM, jameskuyper@verizon.net wrote: > On Monday, July 25, 2016 at 12:36:26 PM UTC-4, Jerry Stuckle wrote: >> On 7/25/2016 12:07 PM, Ben Bacarisse wrote: > ... >>> 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. Show me >> ONE compiler - in ANY language - which supports such a ridiculous >> concept. > > No one has suggested that any real compiler uses such a representation, just as no one has suggested that any real compiler has sizeof(short) > sizeof(int). All that we are disputing is your claim that it is not permitted. The representation described above is, in fact, permitted - but nobody in their right minds would ever use it. > Then you admit your example is totally absurd. The fact you resulted to such an absurd example shows you have nothing relevant to add to the discussion. The standard assumes a modicum of intelligence from the readers. I see that is lacking in you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-07-25 12:18 -0700 |
| Message-ID | <60b1cdae-d828-4a68-9cf9-1f32575e9413@googlegroups.com> |
| In reply to | #91048 |
On Monday, July 25, 2016 at 3:05:50 PM UTC-4, Jerry Stuckle wrote: > On 7/25/2016 1:34 PM, jameskuyper@verizon.net wrote: > > On Monday, July 25, 2016 at 12:36:26 PM UTC-4, Jerry Stuckle wrote: > >> On 7/25/2016 12:07 PM, Ben Bacarisse wrote: > > ... > >>> 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. Show me > >> ONE compiler - in ANY language - which supports such a ridiculous > >> concept. > > > > No one has suggested that any real compiler uses such a representation, just as no one has suggested that any real compiler has sizeof(short) > sizeof(int). All that we are disputing is your claim that it is not permitted. The representation described above is, in fact, permitted - but nobody in their right minds would ever use it. > > > > Then you admit your example is totally absurd. The fact you resulted to > such an absurd example shows you have nothing relevant to add to the > discussion. The question is about what's permitted. What's permitted includes absurdities. That's because the standard's requirements are extremely lenient, far more so than you believe they are. Pointing out that such representations are absurd doesn't change the fact that they are in fact permitted. If you had claimed from the beginning only that "sizeof(short) > sizeof(int) is absurd", most people would have agreed with you, and I doubt that anyone would have objected. I would never write code that assumes "sizeof(short)<=sizeof(int)", because making assumptions not guaranteed by applicable standards goes against my grain. However, I don't expect to ever see such an assumption fail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-25 16:05 -0400 |
| Message-ID | <nn5rd4$ijh$1@jstuckle.eternal-september.org> |
| In reply to | #91050 |
On 7/25/2016 3:18 PM, jameskuyper@verizon.net wrote: > On Monday, July 25, 2016 at 3:05:50 PM UTC-4, Jerry Stuckle wrote: >> On 7/25/2016 1:34 PM, jameskuyper@verizon.net wrote: >>> On Monday, July 25, 2016 at 12:36:26 PM UTC-4, Jerry Stuckle wrote: >>>> On 7/25/2016 12:07 PM, Ben Bacarisse wrote: >>> ... >>>>> 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. Show me >>>> ONE compiler - in ANY language - which supports such a ridiculous >>>> concept. >>> >>> No one has suggested that any real compiler uses such a representation, just as no one has suggested that any real compiler has sizeof(short) > sizeof(int). All that we are disputing is your claim that it is not permitted. The representation described above is, in fact, permitted - but nobody in their right minds would ever use it. >>> >> >> Then you admit your example is totally absurd. The fact you resulted to >> such an absurd example shows you have nothing relevant to add to the >> discussion. > > The question is about what's permitted. What's permitted includes absurdities. That's because the standard's requirements are extremely lenient, far more so than you believe they are. Pointing out that such representations are absurd doesn't change the fact that they are in fact permitted. If you had claimed from the beginning only that "sizeof(short) > sizeof(int) is absurd", most people would have agreed with you, and I doubt that anyone would have objected. > > I would never write code that assumes "sizeof(short)<=sizeof(int)", because making assumptions not guaranteed by applicable standards goes against my grain. However, I don't expect to ever see such an assumption fail. > The standard assumes a modicum of intelligence from the reader. The fact you propose such an absurd example shows you lack even that. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-26 01:08 +0100 |
| Message-ID | <871t2hqn06.fsf@bsb.me.uk> |
| In reply to | #91026 |
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. However, if you *sill* think my example is not permitted (rather than just being totally absurd) please indicate what you are calling the padding BYTES in it. > Show me > ONE compiler - in ANY language - which supports such a ridiculous > concept. Otherwise, you're as full of BS as some others here. Many totally absurd choices are permitted by the language standard but never implemented. This is, to the best of my knowledge, one of them. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-26 12:29 -0400 |
| Message-ID | <nn834o$elo$1@jstuckle.eternal-september.org> |
| In reply to | #91073 |
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. > However, if you *sill* think my example is not permitted (rather than > just being totally absurd) please indicate what you are calling the > padding BYTES in it. > >> Show me >> ONE compiler - in ANY language - which supports such a ridiculous >> concept. Otherwise, you're as full of BS as some others here. > > Many totally absurd choices are permitted by the language standard but > never implemented. This is, to the best of my knowledge, one of them. > Yes, the standards committee assumes a modicum of intelligence by those who read the standards. I see you can't even reach that level. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-07-26 09:41 -0700 |
| Message-ID | <db671584-10a6-4bb9-9f78-a5178847b770@googlegroups.com> |
| In reply to | #91094 |
On Tuesday, July 26, 2016 at 11:29:20 AM UTC-5, Jerry Stuckle wrote:
> Yes, the standards committee assumes a modicum of intelligence by those
> who read the standards. I see you can't even reach that level.
Why is the same attitude not expressed when compilers take something like:
unsigned mul(unsigned short x, unsighed short y) { return x*y; }
and produce code that doesn't work when the product is in the range
INT_MAX+1u and UINT_MAX? The C89 rationale notes that on the majority
of current implementations computations yielding values in that range
would work identically with signed and unsigned types except when the
results were used in certain specific ways, and I don't think they would
have said that if they didn't expect non-obtuse implementations on two's-
complement silent-wraparound hardware to continue behaving likewise?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-07-26 10:50 -0700 |
| Message-ID | <ln8twob85w.fsf@kst-u.example.com> |
| In reply to | #91095 |
supercat@casperkitty.com writes:
> On Tuesday, July 26, 2016 at 11:29:20 AM UTC-5, Jerry Stuckle wrote:
>> Yes, the standards committee assumes a modicum of intelligence by those
>> who read the standards. I see you can't even reach that level.
>
> Why is the same attitude not expressed when compilers take something like:
>
> unsigned mul(unsigned short x, unsighed short y) { return x*y; }
>
> and produce code that doesn't work when the product is in the range
> INT_MAX+1u and UINT_MAX?
Where have I heard that before? Oh, that's right, in every thread you
post in. Do you have a new point that you haven't made before?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web