Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #93363 > unrolled thread
| Started by | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| First post | 2016-09-10 14:23 -0700 |
| Last post | 2016-09-13 07:47 -0700 |
| Articles | 20 on this page of 171 — 17 participants |
Back to article view | Back to comp.lang.c
Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-10 14:23 -0700
Re: Portable 16 bit binary integer write Barry Schwarz <schwarzb@dqel.com> - 2016-09-10 17:11 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 07:00 -0700
Re: Portable 16 bit binary integer write Richard Damon <Richard@Damon-Family.org> - 2016-09-13 08:41 -0400
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-13 06:24 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-13 16:19 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-13 10:20 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-13 11:07 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-13 20:47 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-14 08:24 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 12:17 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 11:27 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 09:03 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 11:21 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 18:39 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 12:26 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 23:12 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 16:17 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 18:35 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 11:10 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 08:43 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 19:59 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 13:34 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-16 16:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 15:31 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-16 19:06 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 23:27 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-17 15:04 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-17 20:35 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 00:09 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 19:36 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 15:29 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-19 01:20 +0100
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-18 09:48 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 19:38 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-18 15:33 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 13:58 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 14:15 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-18 23:15 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 15:46 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-19 17:03 +1200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 07:40 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 10:54 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 10:51 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:03 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 15:44 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 09:02 +0200
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-19 21:12 +0100
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 15:58 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 09:49 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 02:37 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 13:20 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 06:22 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-19 12:46 +0100
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 16:20 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 07:32 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 11:26 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 09:10 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 09:33 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 11:54 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:14 +0200
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:12 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 14:32 -0700
Re: Portable 16 bit binary integer write Robert Wessel <robertwessel2@yahoo.com> - 2016-09-19 22:58 -0500
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 09:45 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-20 07:49 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 19:43 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-20 11:15 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 22:36 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 21:30 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 23:58 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-23 19:45 +1200
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 08:17 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-28 09:59 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-29 07:59 +1300
Re: Portable 16 bit binary integer write Ike Naar <ike@iceland.freeshell.org> - 2016-09-28 19:26 +0000
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-28 12:37 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-09 03:46 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 13:53 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-21 21:03 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-21 22:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-22 08:09 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 10:31 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 10:56 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:03 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-30 07:39 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-22 09:49 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 08:34 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-22 17:44 +0100
Re: Portable 16 bit binary integer write Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-22 17:16 +0000
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-22 18:26 +0100
Re: Portable 16 bit binary integer write Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-22 17:33 +0000
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 10:23 +0200
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-23 13:43 +0100
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 14:58 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 18:14 -0700
Re: Portable 16 bit binary integer write luser droog <luser.droog@gmail.com> - 2016-09-22 20:28 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-23 00:12 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-22 10:57 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 10:18 +0200
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 11:48 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 15:58 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:21 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-30 07:42 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-23 23:38 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-24 11:42 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-24 14:13 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-24 23:03 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 11:29 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 14:02 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:17 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 16:52 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 13:59 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:13 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 15:50 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 08:13 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-24 16:06 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-24 11:53 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-24 14:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 14:16 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:18 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 16:39 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 23:33 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 02:08 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 10:25 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 03:05 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 11:09 +0100
Re: Portable 16 bit binary integer write "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-26 09:29 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 17:37 +0100
Re: Portable 16 bit binary integer write "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-26 12:29 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-26 11:12 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-26 13:19 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 18:34 -0700
Re: Portable 16 bit binary integer write Ike Naar <ike@iceland.freeshell.org> - 2016-09-27 06:43 +0000
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 00:51 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-27 08:42 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-22 11:40 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 10:00 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 10:34 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:13 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 00:06 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-17 17:32 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 15:57 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-17 20:46 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 16:08 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 10:03 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-17 23:59 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-17 16:49 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 01:19 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 07:16 -0700
Re: Portable 16 bit binary integer write "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 10:19 -0400
Re: Portable 16 bit binary integer write luser droog <luser.droog@gmail.com> - 2016-09-18 13:26 -0700
Re: Portable 16 bit binary integer write "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 17:04 -0400
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 01:21 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 12:07 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 00:32 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 16:30 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 18:35 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-15 22:00 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 22:17 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-16 18:12 +1200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 00:46 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-16 10:23 +0100
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-16 10:59 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 04:13 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 08:58 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 10:16 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-16 09:11 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 20:14 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 20:37 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-13 07:47 -0700
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-25 15:18 -0700 |
| Message-ID | <lnr387tyge.fsf@kst-u.example.com> |
| In reply to | #94053 |
supercat@casperkitty.com writes:
[...]
> Given that compiler writers in the 1980s were able to accommodate code
> that was designed for 16-bit "int" even on 32-bit platforms, should it
> not have been reasonable to expect that by the time 64-bit platforms
> became common, compiler writers would have figured out how to sensibly
> handle code written for 32-bit "int"?
Huh? In what sense do compilers for 64-bit platforms *not* sensibly
handle code written for 32-bit int?
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-25 16:39 -0700 |
| Message-ID | <86bc2887-c609-4e5a-bcae-cb079945264a@googlegroups.com> |
| In reply to | #94060 |
On Sunday, September 25, 2016 at 5:18:05 PM UTC-5, Keith Thompson wrote: > Huh? In what sense do compilers for 64-bit platforms *not* sensibly > handle code written for 32-bit int? The promotion of uint32_t to 64-bit signed int will change the meaning of code which uses type uint32_t. For example, code to adjust the total amount of received data based on the difference between two sequence numbers might use "total_received += new_seq - old_seq;" and expect it to regard a sequence number of 4 as being 10 larger than a sequence number of 4294967290. While such code would be better written with a cast to "uint32_t" after the subtract, not all extant code is written that way. Further, code which needs to perform polynomial arithmetic mod 4294967296 for hashing or other purposes may expect that the storing the product of any two uint32_t numbers into a uint32_t will yield the lower 32 bits of the result. Since gcc does not promise to do so, and the Standard doesn't require it, I see no basis for assuming that gcc won't sometimes decide to "optimize" such cases.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-25 23:33 -0700 |
| Message-ID | <lnmvivtbkf.fsf@kst-u.example.com> |
| In reply to | #94064 |
supercat@casperkitty.com writes:
> On Sunday, September 25, 2016 at 5:18:05 PM UTC-5, Keith Thompson wrote:
>> Huh? In what sense do compilers for 64-bit platforms *not* sensibly
>> handle code written for 32-bit int?
>
> The promotion of uint32_t to 64-bit signed int will change the meaning of
> code which uses type uint32_t.
[snip]
My point was that most compilers for 64-bit platforms still make int 32
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-09-26 02:08 -0700 |
| Message-ID | <d03226bb-e691-4ad7-814c-ce2b89bea46c@googlegroups.com> |
| In reply to | #94060 |
On Sunday, September 25, 2016 at 11:18:05 PM UTC+1, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> [...]
> > Given that compiler writers in the 1980s were able to accommodate code
> > that was designed for 16-bit "int" even on 32-bit platforms, should it
> > not have been reasonable to expect that by the time 64-bit platforms
> > became common, compiler writers would have figured out how to sensibly
> > handle code written for 32-bit "int"?
>
> Huh? In what sense do compilers for 64-bit platforms *not* sensibly
> handle code written for 32-bit int?
>
The function
double(mean(double *x, int N)
{
double total = 0;
int i;
for(i=0;i<N;i++)
total += x[i];
return total/N;
}
now breaks. We can create an array more than INT_max elements long,
and so we will get the wrong answer if we try to take the mean
using this perfectly unexceptional function.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-26 10:25 +0100 |
| Message-ID | <nsaphq$4c4$1@dont-email.me> |
| In reply to | #94071 |
On 26/09/16 10:08, Malcolm McLean wrote:
> On Sunday, September 25, 2016 at 11:18:05 PM UTC+1, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> [...]
>>> Given that compiler writers in the 1980s were able to accommodate code
>>> that was designed for 16-bit "int" even on 32-bit platforms, should it
>>> not have been reasonable to expect that by the time 64-bit platforms
>>> became common, compiler writers would have figured out how to sensibly
>>> handle code written for 32-bit "int"?
>>
>> Huh? In what sense do compilers for 64-bit platforms *not* sensibly
>> handle code written for 32-bit int?
>>
> The function
> double(mean(double *x, int N)
> {
> double total = 0;
> int i;
>
> for(i=0;i<N;i++)
> total += x[i];
>
> return total/N;
> }
>
> now breaks. We can create an array more than INT_max elements long,
> and so we will get the wrong answer if we try to take the mean
> using this perfectly unexceptional function.
Assuming you mean INT_MAX rather than INT_max. If the above code worked
on 32-bit int platforms, it'll work under the same conditions on 64-bit
int platforms. If the array was greater than INT_MAX elements long
before, it won't be now (assuming the absolute size of the array is the
same), so the code got less dodgy in the move to 64 bit, rather than the
reverse.
If you /still/ have an array greater than INT_MAX elements long because
you've defined it to be, say, INT_MAX + 6, then it's (a) a stupid design
and (b) easy to fix at least one of the stupidities of that decision.
Just use size_t instead:
#include <math.h>
#include <stddef.h>
double calc_arithmetic_mean(const double *x, size_t N)
{
double total = 0.0;
size_t i = 0;
while(i < N)
{
total += x[i];
}
return (N == 0) ? HUGE_VAL : (total / N);
}
All fixed. Use size_t, Malcolm. Now you can't create an array bigger
than the capacity of the loop counter, because the loop counter has all
the necessary range for dealing with any array.
The size_t type: you know it makes sense.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-26 03:05 -0700 |
| Message-ID | <313cb91f-8953-4099-8667-27e6cfde62df@googlegroups.com> |
| In reply to | #94072 |
On Monday, September 26, 2016 at 10:25:33 AM UTC+1, Richard Heathfield wrote:
> On 26/09/16 10:08, Malcolm McLean wrote:
> > On Sunday, September 25, 2016 at 11:18:05 PM UTC+1, Keith Thompson wrote:
> >> supercat@casperkitty.com writes:
> >> [...]
> >>> Given that compiler writers in the 1980s were able to accommodate code
> >>> that was designed for 16-bit "int" even on 32-bit platforms, should it
> >>> not have been reasonable to expect that by the time 64-bit platforms
> >>> became common, compiler writers would have figured out how to sensibly
> >>> handle code written for 32-bit "int"?
> >>
> >> Huh? In what sense do compilers for 64-bit platforms *not* sensibly
> >> handle code written for 32-bit int?
> >>
> > The function
> > double(mean(double *x, int N)
> > {
> > double total = 0;
> > int i;
> >
> > for(i=0;i<N;i++)
> > total += x[i];
> >
> > return total/N;
> > }
> >
> > now breaks. We can create an array more than INT_max elements long,
> > and so we will get the wrong answer if we try to take the mean
> > using this perfectly unexceptional function.
>
> Assuming you mean INT_MAX rather than INT_max. If the above code worked
> on 32-bit int platforms, it'll work under the same conditions on 64-bit
> int platforms. If the array was greater than INT_MAX elements long
> before, it won't be now (assuming the absolute size of the array is the
> same), so the code got less dodgy in the move to 64 bit, rather than the
> reverse.
>
> If you /still/ have an array greater than INT_MAX elements long because
> you've defined it to be, say, INT_MAX + 6, then it's (a) a stupid design
> and (b) easy to fix at least one of the stupidities of that decision.
> Just use size_t instead:
>
> #include <math.h>
> #include <stddef.h>
>
> double calc_arithmetic_mean(const double *x, size_t N)
> {
> double total = 0.0;
> size_t i = 0;
> while(i < N)
> {
> total += x[i];
> }
> return (N == 0) ? HUGE_VAL : (total / N);
> }
>
> All fixed. Use size_t, Malcolm. Now you can't create an array bigger
> than the capacity of the loop counter, because the loop counter has all
> the necessary range for dealing with any array.
>
> The size_t type: you know it makes sense.
>
So one issue is that size_t is unsigned. That's OK for mean, but it becomes a nuisance
for slightly more complicated calculations which have to manipulate the index variable
and may create negatives for intermediates or at edge conditions. So can of course
always rewrite carefully, but thats not something that some who is implementing a
filter, for example, should have to worry about. He should worry about his filter logic,
not about whether if(index + (i - halfwidth) > 0) is going to trigger funny unsigned
arithmetic quirks.
So first, make size_t signed. You lose a bit. So you can no longer have a string with
more that 2^63 characters. We can live with that restriction.
Secondly, the name. size_t is an appalling name for a general-purpose index type.
it's also a bad name for N. size_t should be reserved strictly for variables which hold
amounts of memory in bytes. So we need a better name. How about index_t? However
that's a bit confusing, as index_t and N should be the same type, and index_t is fine for
i but not for N. Both are constrained to be integral. So how about "integer ?"
In fact, for shortness, make that "int".
So now we have it. size_t fixed.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-26 11:09 +0100 |
| Message-ID | <nsas4t$cvn$1@dont-email.me> |
| In reply to | #94074 |
On 26/09/16 11:05, Malcolm McLean wrote:
> On Monday, September 26, 2016 at 10:25:33 AM UTC+1, Richard Heathfield wrote:
>> On 26/09/16 10:08, Malcolm McLean wrote:
>>> On Sunday, September 25, 2016 at 11:18:05 PM UTC+1, Keith Thompson wrote:
>>>> supercat@casperkitty.com writes:
>>>> [...]
>>>>> Given that compiler writers in the 1980s were able to accommodate code
>>>>> that was designed for 16-bit "int" even on 32-bit platforms, should it
>>>>> not have been reasonable to expect that by the time 64-bit platforms
>>>>> became common, compiler writers would have figured out how to sensibly
>>>>> handle code written for 32-bit "int"?
>>>>
>>>> Huh? In what sense do compilers for 64-bit platforms *not* sensibly
>>>> handle code written for 32-bit int?
>>>>
>>> The function
>>> double(mean(double *x, int N)
>>> {
>>> double total = 0;
>>> int i;
>>>
>>> for(i=0;i<N;i++)
>>> total += x[i];
>>>
>>> return total/N;
>>> }
>>>
>>> now breaks. We can create an array more than INT_max elements long,
>>> and so we will get the wrong answer if we try to take the mean
>>> using this perfectly unexceptional function.
>>
>> Assuming you mean INT_MAX rather than INT_max. If the above code worked
>> on 32-bit int platforms, it'll work under the same conditions on 64-bit
>> int platforms. If the array was greater than INT_MAX elements long
>> before, it won't be now (assuming the absolute size of the array is the
>> same), so the code got less dodgy in the move to 64 bit, rather than the
>> reverse.
>>
>> If you /still/ have an array greater than INT_MAX elements long because
>> you've defined it to be, say, INT_MAX + 6, then it's (a) a stupid design
>> and (b) easy to fix at least one of the stupidities of that decision.
>> Just use size_t instead:
>>
>> #include <math.h>
>> #include <stddef.h>
>>
>> double calc_arithmetic_mean(const double *x, size_t N)
>> {
>> double total = 0.0;
>> size_t i = 0;
>> while(i < N)
>> {
>> total += x[i];
>> }
>> return (N == 0) ? HUGE_VAL : (total / N);
>> }
>>
>> All fixed. Use size_t, Malcolm. Now you can't create an array bigger
>> than the capacity of the loop counter, because the loop counter has all
>> the necessary range for dealing with any array.
>>
>> The size_t type: you know it makes sense.
>>
> So one issue is that size_t is unsigned. That's OK for mean,
You chose mean, not me.
> but it becomes a nuisance
> for slightly more complicated calculations which have to manipulate the index variable
> and may create negatives for intermediates or at edge conditions. So can of course
> always rewrite carefully, but thats not something that some who is implementing a
> filter, for example, should have to worry about. He should worry about his filter logic,
> not about whether if(index + (i - halfwidth) > 0) is going to trigger funny unsigned
> arithmetic quirks.
> So first, make size_t signed. You lose a bit. So you can no longer have a string with
> more that 2^63 characters. We can live with that restriction.
So you're going to take the part of size_t that made it fix your
artificial problem, and remove it in order to re-introduce your problem,
and you call that an improvement?
> Secondly, the name. size_t is an appalling name for a general-purpose index type.
I agree, but it's the name we're stuck with. In this case, What You Get
Is What You're Given And There's No Use Moaning.
> it's also a bad name for N. size_t should be reserved strictly for variables which hold
> amounts of memory in bytes. So we need a better name. How about index_t? However
> that's a bit confusing, as index_t and N should be the same type, and index_t is fine for
> i but not for N. Both are constrained to be integral. So how about "integer ?"
>
> In fact, for shortness, make that "int".
>
> So now we have it. size_t fixed.
No, Malcolm, you've just re-broken your 'mean()' function.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-09-26 09:29 -0700 |
| Message-ID | <nsbic8$p4v$1@dont-email.me> |
| In reply to | #94072 |
On 9/26/2016 2:25 AM, Richard Heathfield wrote:
> On 26/09/16 10:08, Malcolm McLean wrote:
>> On Sunday, September 25, 2016 at 11:18:05 PM UTC+1, Keith Thompson wrote:
>>> supercat@casperkitty.com writes:
>>> [...]
>>>> Given that compiler writers in the 1980s were able to accommodate code
>>>> that was designed for 16-bit "int" even on 32-bit platforms, should it
>>>> not have been reasonable to expect that by the time 64-bit platforms
>>>> became common, compiler writers would have figured out how to sensibly
>>>> handle code written for 32-bit "int"?
>>>
>>> Huh? In what sense do compilers for 64-bit platforms *not* sensibly
>>> handle code written for 32-bit int?
>>>
>> The function
>> double(mean(double *x, int N)
>> {
>> double total = 0;
>> int i;
>>
>> for(i=0;i<N;i++)
>> total += x[i];
>>
>> return total/N;
>> }
>>
>> now breaks. We can create an array more than INT_max elements long,
>> and so we will get the wrong answer if we try to take the mean
>> using this perfectly unexceptional function.
>
> Assuming you mean INT_MAX rather than INT_max. If the above code worked
> on 32-bit int platforms, it'll work under the same conditions on 64-bit
> int platforms. If the array was greater than INT_MAX elements long
> before, it won't be now (assuming the absolute size of the array is the
> same), so the code got less dodgy in the move to 64 bit, rather than the
> reverse.
>
> If you /still/ have an array greater than INT_MAX elements long because
> you've defined it to be, say, INT_MAX + 6, then it's (a) a stupid design
> and (b) easy to fix at least one of the stupidities of that decision.
> Just use size_t instead:
>
> #include <math.h>
> #include <stddef.h>
>
> double calc_arithmetic_mean(const double *x, size_t N)
> {
> double total = 0.0;
> size_t i = 0;
> while(i < N)
> {
> total += x[i];
> }
> return (N == 0) ? HUGE_VAL : (total / N);
> }
how is that while loop ever going to terminate?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-26 17:37 +0100 |
| Message-ID | <nsbist$h4$2@dont-email.me> |
| In reply to | #94092 |
On 26/09/16 17:29, Chris M. Thomasson wrote:
> On 9/26/2016 2:25 AM, Richard Heathfield wrote:
>> On 26/09/16 10:08, Malcolm McLean wrote:
>>> On Sunday, September 25, 2016 at 11:18:05 PM UTC+1, Keith Thompson
>>> wrote:
>>>> supercat@casperkitty.com writes:
>>>> [...]
>>>>> Given that compiler writers in the 1980s were able to accommodate code
>>>>> that was designed for 16-bit "int" even on 32-bit platforms, should it
>>>>> not have been reasonable to expect that by the time 64-bit platforms
>>>>> became common, compiler writers would have figured out how to sensibly
>>>>> handle code written for 32-bit "int"?
>>>>
>>>> Huh? In what sense do compilers for 64-bit platforms *not* sensibly
>>>> handle code written for 32-bit int?
>>>>
>>> The function
>>> double(mean(double *x, int N)
>>> {
>>> double total = 0;
>>> int i;
>>>
>>> for(i=0;i<N;i++)
>>> total += x[i];
>>>
>>> return total/N;
>>> }
>>>
>>> now breaks. We can create an array more than INT_max elements long,
>>> and so we will get the wrong answer if we try to take the mean
>>> using this perfectly unexceptional function.
>>
>> Assuming you mean INT_MAX rather than INT_max. If the above code worked
>> on 32-bit int platforms, it'll work under the same conditions on 64-bit
>> int platforms. If the array was greater than INT_MAX elements long
>> before, it won't be now (assuming the absolute size of the array is the
>> same), so the code got less dodgy in the move to 64 bit, rather than the
>> reverse.
>>
>> If you /still/ have an array greater than INT_MAX elements long because
>> you've defined it to be, say, INT_MAX + 6, then it's (a) a stupid design
>> and (b) easy to fix at least one of the stupidities of that decision.
>> Just use size_t instead:
>>
>> #include <math.h>
>> #include <stddef.h>
>>
>> double calc_arithmetic_mean(const double *x, size_t N)
>> {
>> double total = 0.0;
>> size_t i = 0;
>> while(i < N)
>> {
>> total += x[i];
>> }
>> return (N == 0) ? HUGE_VAL : (total / N);
>> }
>
>
> how is that while loop ever going to terminate?
The heat death of the universe would do it. Or you could shove a ++ in
there if you prefer. (Good spot, by the way.)
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-09-26 12:29 -0700 |
| Message-ID | <nsbsuv$8df$1@dont-email.me> |
| In reply to | #94094 |
On 9/26/2016 9:37 AM, Richard Heathfield wrote:
> On 26/09/16 17:29, Chris M. Thomasson wrote:
>> On 9/26/2016 2:25 AM, Richard Heathfield wrote:
>>> On 26/09/16 10:08, Malcolm McLean wrote:
>>>> On Sunday, September 25, 2016 at 11:18:05 PM UTC+1, Keith Thompson
>>>> wrote:
>>>>> supercat@casperkitty.com writes:
>>>>> [...]
>>>>>> Given that compiler writers in the 1980s were able to accommodate
>>>>>> code
>>>>>> that was designed for 16-bit "int" even on 32-bit platforms,
>>>>>> should it
>>>>>> not have been reasonable to expect that by the time 64-bit platforms
>>>>>> became common, compiler writers would have figured out how to
>>>>>> sensibly
>>>>>> handle code written for 32-bit "int"?
>>>>>
>>>>> Huh? In what sense do compilers for 64-bit platforms *not* sensibly
>>>>> handle code written for 32-bit int?
>>>>>
>>>> The function
>>>> double(mean(double *x, int N)
>>>> {
>>>> double total = 0;
>>>> int i;
>>>>
>>>> for(i=0;i<N;i++)
>>>> total += x[i];
>>>>
>>>> return total/N;
>>>> }
>>>>
>>>> now breaks. We can create an array more than INT_max elements long,
>>>> and so we will get the wrong answer if we try to take the mean
>>>> using this perfectly unexceptional function.
>>>
>>> Assuming you mean INT_MAX rather than INT_max. If the above code worked
>>> on 32-bit int platforms, it'll work under the same conditions on 64-bit
>>> int platforms. If the array was greater than INT_MAX elements long
>>> before, it won't be now (assuming the absolute size of the array is the
>>> same), so the code got less dodgy in the move to 64 bit, rather than the
>>> reverse.
>>>
>>> If you /still/ have an array greater than INT_MAX elements long because
>>> you've defined it to be, say, INT_MAX + 6, then it's (a) a stupid design
>>> and (b) easy to fix at least one of the stupidities of that decision.
>>> Just use size_t instead:
>>>
>>> #include <math.h>
>>> #include <stddef.h>
>>>
>>> double calc_arithmetic_mean(const double *x, size_t N)
>>> {
>>> double total = 0.0;
>>> size_t i = 0;
>>> while(i < N)
>>> {
>>> total += x[i];
>>> }
>>> return (N == 0) ? HUGE_VAL : (total / N);
>>> }
>>
>>
>> how is that while loop ever going to terminate?
>
> The heat death of the universe would do it.
lol! ;^D
> Or you could shove a ++ in there if you prefer.
Indeed.
> (Good spot, by the way.)
No problem. BTW, I think your C skills are very good! I take all of your
advise to heart Richard. Thanks.
:^)
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-26 11:12 +0100 |
| Message-ID | <nsasac$djn$1@dont-email.me> |
| In reply to | #94071 |
On 26/09/2016 10:08, Malcolm McLean wrote:
> On Sunday, September 25, 2016 at 11:18:05 PM UTC+1, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> [...]
>>> Given that compiler writers in the 1980s were able to accommodate code
>>> that was designed for 16-bit "int" even on 32-bit platforms, should it
>>> not have been reasonable to expect that by the time 64-bit platforms
>>> became common, compiler writers would have figured out how to sensibly
>>> handle code written for 32-bit "int"?
>>
>> Huh? In what sense do compilers for 64-bit platforms *not* sensibly
>> handle code written for 32-bit int?
>>
> The function
> double(mean(double *x, int N)
> {
> double total = 0;
> int i;
>
> for(i=0;i<N;i++)
> total += x[i];
>
> return total/N;
> }
>
> now breaks. We can create an array more than INT_max elements long,
> and so we will get the wrong answer if we try to take the mean
> using this perfectly unexceptional function.
On my desktop PC this code will break long before you get an array that big.
Even an INT_MAX-size array of doubles would require 16GB just for the
array. The machine usually has 1-2GB free.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-26 13:19 -0700 |
| Message-ID | <552a68c2-0ef4-4380-b5ee-a17b626dd547@googlegroups.com> |
| In reply to | #94071 |
On Monday, September 26, 2016 at 4:08:58 AM UTC-5, Malcolm McLean wrote:
> The function
> double(mean(double *x, int N)
> {
> double total = 0;
> int i;
>
> for(i=0;i<N;i++)
> total += x[i];
>
> return total/N;
> }
>
> now breaks. We can create an array more than INT_max elements long,
> and so we will get the wrong answer if we try to take the mean
> using this perfectly unexceptional function.
If the array worked with some number of elements, it should continue to
work with the same number of elements. While it may be that memory
limitations on the older systems would have meant there was no need for
code to operate on arrays of anywhere near INT_MAX elements, and that
newer systems can accommodate larger arrays without difficulty, there is
really nothing special about INT_MAX or size_t in that regard. A lot of
programs will for a variety of reasons be limited in the size of data they
can handle correctly; migration to a 64-bit platform may ease some of those
limits, but should not generally be expected to ease them all.
When moving a piece of old code to a new platform, having the new code work
in the same cases as the old code did will be a helpful starting point even
if the program would need further modifications to go beyond the capabilities
of the old system.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-26 18:34 -0700 |
| Message-ID | <af805fa0-fd83-40ee-9f10-eb82e1f81a4f@googlegroups.com> |
| In reply to | #94105 |
On Monday, September 26, 2016 at 9:19:24 PM UTC+1, supe...@casperkitty.com wrote: > > If the array worked with some number of elements, it should continue to > work with the same number of elements. While it may be that memory > limitations on the older systems would have meant there was no need for > code to operate on arrays of anywhere near INT_MAX elements, and that > newer systems can accommodate larger arrays without difficulty, there is > really nothing special about INT_MAX or size_t in that regard. A lot of > programs will for a variety of reasons be limited in the size of data they > can handle correctly; migration to a 64-bit platform may ease some of > those limits, but should not generally be expected to ease them all. > When moving a piece of old code to a new platform, having the new code > work in the same cases as the old code did will be a helpful starting > point even if the program would need further modifications to go beyond > the capabilities of the old system. > 64 bits do solve this problem. Data has to mean something, so if you've got more than 2 billion data points, that is quite an achievement and you'll need 16 GB of memory just to hold the array. So for the vast majority of cases, 32 bits are more than adequate. But some automatic devices can generate that amount of data. Things like seismometers create vast data files the stress even modern machines. With 64 bits, you're safe, however. There's no way data can get to that size, even if it's automatically generated.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-09-27 06:43 +0000 |
| Message-ID | <slrn3vfsnuk58h.q1.ike@iceland.freeshell.org> |
| In reply to | #94122 |
On 2016-09-27, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > Data has to mean something, so if you've got more than 2 billion data > points, that is quite an achievement and you'll need 16 GB of memory > just to hold the array. So for the vast majority of cases, 32 bits > are more than adequate. > But some automatic devices can generate that amount of data. Things > like seismometers create vast data files the stress even modern > machines. With 64 bits, you're safe, however. There's no way data > can get to that size, even if it's automatically generated. Hash sums, encryption keys et cetera are often much larger than that.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-27 00:51 -0700 |
| Message-ID | <737e828d-fd85-4e96-8b08-b305da4334af@googlegroups.com> |
| In reply to | #94123 |
On Tuesday, September 27, 2016 at 7:43:45 AM UTC+1, Ike Naar wrote: > On 2016-09-27, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > Data has to mean something, so if you've got more than 2 billion data > > points, that is quite an achievement and you'll need 16 GB of memory > > just to hold the array. So for the vast majority of cases, 32 bits > > are more than adequate. > > But some automatic devices can generate that amount of data. Things > > like seismometers create vast data files the stress even modern > > machines. With 64 bits, you're safe, however. There's no way data > > can get to that size, even if it's automatically generated. > > Hash sums, encryption keys et cetera are often much larger than that. > Yes, there's a small specialised use for huge integers which don't actually count things but represent various mathematical transforms of data. But size_t isn't the right type for that. What you need is a general purpose index type which is efficient, can index anything the computer can handle, and supports random-access operations. A 32 bit integer is almost that type, but not quite, there are some arrays which could be created with real data which will fit into a high-end desktop's memory, and which it won't index.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-27 08:42 -0700 |
| Message-ID | <f19b392c-92d0-406d-9c4c-b5b427dae6bb@googlegroups.com> |
| In reply to | #94122 |
On Monday, September 26, 2016 at 8:34:29 PM UTC-5, Malcolm McLean wrote: > But some automatic devices can generate that amount of data. Things > like seismometers create vast data files the stress even modern > machines. With 64 bits, you're safe, however. There's no way data > can get to that size, even if it's automatically generated. If one takes some data logging code that was designed for a little 8-bit micro and runs it on a 64-bit machine, one should not blindly expect it to usefully crunch through many billions of data points. The best one should hope for without diving into the code would be that a newer machine would be able to emulate the behavior of the old machine when processing roughly- comparable amounts of data. Requiring that a compiler treat uphold certain guarantees that were upheld by the original PDP-11 implementation and on many 1990s implementations for machines with a similar programming model (including most microcomputers) might make code less efficient than it could be if targeting a high-end compiler, but if someone in 1990 faced a choice between writing code in a way that could run as fast as required on a 1990 C compiler and could run 20 times as fast as required on a 2016 machine with a conservative optimizer, or writing the code in a fashion that would only run 1/3 as fast as required on a 1990 compiler, but would be able to run 50 times as fast as required on a 2016 machine with an aggressive optimizer, what should have been the correct choice?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-22 11:40 -0700 |
| Message-ID | <lnzimzvkvi.fsf@kst-u.example.com> |
| In reply to | #93882 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> [...]
>>
>> Perhaps it's time for the next edition of the C standard to mandate
>> 2's-complement [...]
>
> I see no reason to do so, and in fact would express it more
> strongly - it is IMO philosophically wrongheaded. Most
> applications don't care. Any that do care can easily enforce
> that they will compile only on 2's complement implementations.
Do you mean by checking whether the intN_t types are defined?
> Obviously it is an advantage for the language to be available
> as widely as possible, including on hardware that employs
> alternate representation schemes. Arbitrarily excluding such
> hardware would be a poor choice for C, which IIANM is available
> on a more diverse range of hardware than any other programming
> language. That is one of C's most important strengths - any
> move in a direction that would weaken that should be viewed
> with suspicion.
I agree such a change should be viewed with suspicion.
But consider that C99 imposed restrictions relative to C90,
by explicitly requiring either 2's-complement, 1's-complement,
or sign-and-magnitude. It also required all-bits-zero to be a
representation of 0 for all integer types, which provided the
useful guarantee that memset could set an array of integers to
zero. (Actually I think that change was in a post-C99 Technical
Corrigendum.)
If there are any plausible targets for post-C11 compilers that
don't use 2's-complement, I would oppose such a change.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-23 10:00 -0700 |
| Message-ID | <kfneg4aeel9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93907 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> [...]
>>>
>>> Perhaps it's time for the next edition of the C standard to mandate
>>> 2's-complement [...]
>>
>> I see no reason to do so, and in fact would express it more
>> strongly - it is IMO philosophically wrongheaded. Most
>> applications don't care. Any that do care can easily enforce
>> that they will compile only on 2's complement implementations.
>
> Do you mean by checking whether the intN_t types are defined?
Actually I had a different idea in mind, involving a static
assertion (or a pre-C11 workaround for one) involving an
expression such as '-1 & 3', which has different values in the
different systems. Though, come to think of it, there is an
easier test that can be done, and in the preprocessor, namely:
#include <limits.h>
#if INT_MIN == -INT_MAX
#error Sorry, Charlie
#endif
In principle this test could give an error in an implementation
that actually does use two's complement, but in practice it
should work just fine. (And if INT_MIN == -INT_MAX even though
two's complement is used, that condition is odd enough that it
may be worth disallowing that implementation anyway.)
>> Obviously it is an advantage for the language to be available
>> as widely as possible, including on hardware that employs
>> alternate representation schemes. Arbitrarily excluding such
>> hardware would be a poor choice for C, which IIANM is available
>> on a more diverse range of hardware than any other programming
>> language. That is one of C's most important strengths - any
>> move in a direction that would weaken that should be viewed
>> with suspicion.
>
> I agree such a change should be viewed with suspicion.
> But consider that C99 imposed restrictions relative to C90,
> by explicitly requiring either 2's-complement, 1's-complement,
> or sign-and-magnitude.
In my view, and AFAIK also in WG14's view, these changes were
a clarification rather than a restriction. Remember, C89/C90
did say something about the representation of integral types:
The representations of integral types shall define values
by use of a /pure binary numeration system/.
The additional descriptions in C99 (ie, for two's complement,
etc) can be seen as simply being more specific about what a
"pure binary numeration system" is. Note also that the C99
Rationale document says nothing about the three representation
schemes, which it probably would have if they were viewed as
a restriction rather than a clarification.
> It also required all-bits-zero to be a
> representation of 0 for all integer types, which provided the
> useful guarantee that memset could set an array of integers to
> zero.
That's true but that's about something different. In C99 the
object representations of integer types are allowed to have
padding bits, which aren't mentioned in C89/C90. So C99 is
expanding the range of representations allowed, not reducing
it. Under the C89/C90 rules, there is no reason to say that
all-bits-zero must be 0 for integer types, because that is
implied by the "pure binary numeration system" stipulation.
The rule about all-bits-zero in C99 was needed only because
of padding bits, not value bits. Under the C89/C90 wording
the question doesn't come up.
Note that the Rationale document does mention the change in C99
to allow padding bits.
> (Actually I think that change was in a post-C99 Technical
> Corrigendum.)
Yes, I believe that's right.
> If there are any plausible targets for post-C11 compilers that
> don't use 2's-complement, I would oppose such a change.
IMO there are good reasons to leave this part of C alone, and no
compelling reason to change it, regardless of whether this or
that representation scheme may have fallen out of fashion with
hardware manufacturers.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-23 10:34 -0700 |
| Message-ID | <4d355a52-921e-40e7-805a-05fd927bc641@googlegroups.com> |
| In reply to | #93956 |
On Friday, September 23, 2016 at 12:00:28 PM UTC-5, Tim Rentsch wrote: > That's true but that's about something different. In C99 the > object representations of integer types are allowed to have > padding bits, which aren't mentioned in C89/C90. So C99 is > expanding the range of representations allowed, not reducing > it. Under the C89/C90 rules, there is no reason to say that > all-bits-zero must be 0 for integer types, because that is > implied by the "pure binary numeration system" stipulation. > The rule about all-bits-zero in C99 was needed only because > of padding bits, not value bits. Under the C89/C90 wording > the question doesn't come up. The need for padding bits arises more often in older hardware than in newer hardware, so it would seem odd that the authors of C89 intended to make the language useless on such hardware. Further, on some systems the most efficient way to handle integer math was (and on some platforms still is) offset-binary, which is a pure binary numbering system, but treats all-bits-zero as INT_MIN rather than as zero. I've never seen a C compiler which used offset binary, but on some platforms it can sometimes be more efficient than two's-complement when used in machine code. For example, if a platform doesn't support efficient sign extension, code can add together 100 offset-binary bytes by using 4000 unsigned adds and then subtracting 12800, rather than having to sign-extend each byte individually. I don't know if any C compilers used offset binary, but it would certainly be plausible that some might have done so, and I see no reason to believe the C89 Standard would have been intended to forbid them. > IMO there are good reasons to leave this part of C alone, and no > compelling reason to change it, regardless of whether this or > that representation scheme may have fallen out of fashion with > hardware manufacturers. Because the C Standard was written after the language was already in use, the authors were extremely loath to mandate that any platform--no matter how obscure--be unable to perform any task as efficiently in C89 as it had been performing it previously. If 10% of code requires that a platform have some trait which is shared by 99% of platforms, it may make sense to define the Standard in a way that describes the behavior of the 1% of platforms that lack that trait running the 90% of code that doesn't require it, but that doesn't mean that it shouldn't also specify a means by which code that only needs to run on the 99% of platforms that possess a trait shouldn't be able to take advantage of that trait.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-29 08:13 -0700 |
| Message-ID | <kfnmviqagcp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93958 |
supercat@casperkitty.com writes: > On Friday, September 23, 2016 at 12:00:28 PM UTC-5, Tim Rentsch wrote: >> That's true but that's about something different. In C99 the >> object representations of integer types are allowed to have >> padding bits, which aren't mentioned in C89/C90. So C99 is >> expanding the range of representations allowed, not reducing >> it. Under the C89/C90 rules, there is no reason to say that >> all-bits-zero must be 0 for integer types, because that is >> implied by the "pure binary numeration system" stipulation. >> The rule about all-bits-zero in C99 was needed only because >> of padding bits, not value bits. Under the C89/C90 wording >> the question doesn't come up. > > The need for padding bits arises more often in older hardware than in > newer hardware, so it would seem odd that the authors of C89 intended to > make the language useless on such hardware. It would seem odd, if it were true. 'Tisn't. > [...on the question of whether implementations may use an offset > binary representation for integer types ...] I see no reason to > believe the C89 Standard would have been intended to forbid > them. Then I can only conclude you are being willfully ignorant.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web