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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-09-19 17:03 +1200 |
| Message-ID | <e499t5FtdveU3@mid.individual.net> |
| In reply to | #93764 |
On 09/19/16 10:46 AM, supercat@casperkitty.com wrote: > On Sunday, September 18, 2016 at 5:15:14 PM UTC-5, Bart wrote: >> 'short' and 'long' might have been better implemented as relative (not >> absolute) modifiers of 'int': respectively halving or doubling the >> width, whatever that is, rather than allowing them to do nothing at the >> whim of the implementation. > > For a long time, the majority of C implementations defined integer types > consistently as: > > char 8 bits > short 16 bits > int 16 or 32 bits > long 32 bits > > I don't see how making the sizes relative would be an improvement on that. Most (all?) compilers for 32 targets still do. > It would be more useful to define a means by which a piece of source code > could indicate its expectations for integer types, with a requirement that > compilers must either process the code in accordance with its specifications > or indicate in a defined fashion that it cannot do so. If a program > indicates that it needs integer overflow to behave a certain way, then > within that program integer overflow would not cause Undefined Behavior. It probably already can with the appropriate static assertions. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-19 07:40 -0700 |
| Message-ID | <48e74afb-1f97-4c30-aff7-e982c543653f@googlegroups.com> |
| In reply to | #93776 |
On Monday, September 19, 2016 at 12:03:41 AM UTC-5, Ian Collins wrote: > > It would be more useful to define a means by which a piece of source code > > could indicate its expectations for integer types, with a requirement that > > compilers must either process the code in accordance with its specifications > > or indicate in a defined fashion that it cannot do so. If a program > > indicates that it needs integer overflow to behave a certain way, then > > within that program integer overflow would not cause Undefined Behavior. > > It probably already can with the appropriate static assertions. What static assertion could a program use to indicate that it will only work on implementations where signed overflow will never have any side- effect other than yielding a value which may behave as though it has non- deterministic "upper bits"? Or, for that matter, on implementations where unsigned-to-signed conversions are always performed via two's-complement mod reduction? One might not expect that an implementation would use saturating conversion if a programs is compiled on a Tuesdays but mod reduction if compiled on other days, but such a behavior would be allowable by the Standard provided that it was described somewhere in nominally- human-readable documentation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-19 10:54 -0700 |
| Message-ID | <lnwpi7wza6.fsf@kst-u.example.com> |
| In reply to | #93803 |
supercat@casperkitty.com writes:
[...]
> What static assertion could a program use to indicate that it will only
> work on implementations where signed overflow will never have any side-
> effect other than yielding a value which may behave as though it has non-
> deterministic "upper bits"?
No such static assertion is possible in unextended standard C.
Since you're obviously fascinated with the idea of supporting
such assertions, why don't you write up a concrete proposal?
(You could post it on your blog.)
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-19 10:51 -0700 |
| Message-ID | <ln1t0fydzw.fsf@kst-u.example.com> |
| In reply to | #93762 |
BartC <bc@freeuk.com> writes:
> On 18/09/2016 23:33, Keith Thompson wrote:
>>> is not 8, 16 or 32, and int sizes that are not 16 or 32 bits.
>>
>> 64-bit int is perfectly sensible for 64-bit systems. The main
>> reason, I think, that it's not more common is that it leaves a
>> gap; if you have 8-bit char and 64-int, and short is the only type
>> in between, then you can't have both 16-bit and 32-bit integers.
>> Extended integer types, appropriate typedefs in <stdint.h>, should
>> solve that, but I don't think any implementations have taken
>> advantage of that (probably because of backward compatibility).
>
> Short short?
No, I'm not suggesting that, and it's not at all necessary.
Extended integer types typically have names with the form of reserved
identifiers. An implementation with 8-bit char and 64-bit int might
have, say, 32-bit short and a 16-bit type named, for example, "__int16".
<stdint.h> could then have:
typedef signed char int8_t;
typedef __int16 int16_t;
typedef short int32_t;
typedef int int64_t;
(and so on for uintN_t, [u]int_leastN_t, et al).
If you were starting with C90 (which didn't have extended integer
types or <stdint.h>) and you wanted to permit 64-bit int while
still providing 8-bit, 16-bit, and 32-bit integer types, you might
reasonably consider adding "short short". But with the features
added in C99, that was no longer necessary.
One might argue that "long long" was equally unnecessary, and I
suppose that's true. But "long long" is in the language, and it's
not going away.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-19 22:03 +0200 |
| Message-ID | <nrpgag$asr$1@dont-email.me> |
| In reply to | #93807 |
On 19/09/16 19:51, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 18/09/2016 23:33, Keith Thompson wrote: >>>> is not 8, 16 or 32, and int sizes that are not 16 or 32 bits. >>> >>> 64-bit int is perfectly sensible for 64-bit systems. The main >>> reason, I think, that it's not more common is that it leaves a >>> gap; if you have 8-bit char and 64-int, and short is the only type >>> in between, then you can't have both 16-bit and 32-bit integers. >>> Extended integer types, appropriate typedefs in <stdint.h>, should >>> solve that, but I don't think any implementations have taken >>> advantage of that (probably because of backward compatibility). >> >> Short short? > > No, I'm not suggesting that, and it's not at all necessary. > > Extended integer types typically have names with the form of reserved > identifiers. An implementation with 8-bit char and 64-bit int might > have, say, 32-bit short and a 16-bit type named, for example, "__int16". > <stdint.h> could then have: > > typedef signed char int8_t; > typedef __int16 int16_t; > typedef short int32_t; > typedef int int64_t; > > (and so on for uintN_t, [u]int_leastN_t, et al). > > If you were starting with C90 (which didn't have extended integer > types or <stdint.h>) and you wanted to permit 64-bit int while > still providing 8-bit, 16-bit, and 32-bit integer types, you might > reasonably consider adding "short short". But with the features > added in C99, that was no longer necessary. > > One might argue that "long long" was equally unnecessary, and I > suppose that's true. But "long long" is in the language, and it's > not going away. > Of curiosity, do you know of any implementations that actually have extended integer types? gcc has __int128_t on some targets (typically 64-bit targets), but it is not an extended integer type. I can't remember exactly why it does not qualify as an extended integer type (there is no way to express constants of that type, unless it happens to match long long, but I don't know if that is an issue for qualifying as an extended integer type).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-19 15:44 -0700 |
| Message-ID | <ln8tunwlux.fsf@kst-u.example.com> |
| In reply to | #93825 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Of curiosity, do you know of any implementations that actually have
> extended integer types?
No.
> gcc has __int128_t on some targets (typically
> 64-bit targets), but it is not an extended integer type. I can't
> remember exactly why it does not qualify as an extended integer type
> (there is no way to express constants of that type, unless it happens to
> match long long, but I don't know if that is an issue for qualifying as
> an extended integer type).
On a system with 64-bit long long, an extended 128-bit integer type,
if it exists in both signed and unsigned types, would require
[u]intmax_t to be 128 bits. gcc makes [u]intmax_t 64 bits.
Supposedly the x86_64 ABI requires [u]intmax_t to be 64 bits.
Making [u]intmax_t would require coordination between the compiler
and the standard library, as well as among compilers that expect to
generate code passing values of those types to functions compiled
by other compilers.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-20 09:02 +0200 |
| Message-ID | <nrqmtg$6h0$3@dont-email.me> |
| In reply to | #93828 |
On 20/09/16 00:44, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Of curiosity, do you know of any implementations that actually have >> extended integer types? > > No. > >> gcc has __int128_t on some targets (typically >> 64-bit targets), but it is not an extended integer type. I can't >> remember exactly why it does not qualify as an extended integer type >> (there is no way to express constants of that type, unless it happens to >> match long long, but I don't know if that is an issue for qualifying as >> an extended integer type). > > On a system with 64-bit long long, an extended 128-bit integer type, > if it exists in both signed and unsigned types, would require > [u]intmax_t to be 128 bits. gcc makes [u]intmax_t 64 bits. > Supposedly the x86_64 ABI requires [u]intmax_t to be 64 bits. > > Making [u]intmax_t would require coordination between the compiler > and the standard library, as well as among compilers that expect to > generate code passing values of those types to functions compiled > by other compilers. > OK. This would clearly not be a problem for making /smaller/ extended integer types.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-19 21:12 +0100 |
| Message-ID | <nrpgrd$d2q$1@dont-email.me> |
| In reply to | #93807 |
On 19/09/2016 18:51, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> Short short? > > No, I'm not suggesting that, and it's not at all necessary. > > Extended integer types typically have names with the form of reserved > identifiers. An implementation with 8-bit char and 64-bit int might > have, say, 32-bit short and a 16-bit type named, for example, "__int16". > <stdint.h> could then have: > > typedef signed char int8_t; > typedef __int16 int16_t; > typedef short int32_t; > typedef int int64_t; > > (and so on for uintN_t, [u]int_leastN_t, et al). > > If you were starting with C90 (which didn't have extended integer > types or <stdint.h>) and you wanted to permit 64-bit int while > still providing 8-bit, 16-bit, and 32-bit integer types, you might > reasonably consider adding "short short". But with the features > added in C99, that was no longer necessary. The C99 features aren't quite the same thing. Sometimes you don't want to specify hard integer widths. You just want an 'int', whatever width that happens to be, and also have a wider int and a narrower one. (For example, what type do you need to represent the least or most significant half of an int?) The C99 intN_t types also introduce some problems: what printf format do you use for int32_t for example, and which for int64_t? With the non-specific types, you know that %d, %ld and %lld correspond to int, long int, and long long int respectively (even if there are only two different widths rather than tree. Or just one). -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-19 15:58 -0700 |
| Message-ID | <ln4m5bwl76.fsf@kst-u.example.com> |
| In reply to | #93826 |
BartC <bc@freeuk.com> writes:
> On 19/09/2016 18:51, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Short short?
>>
>> No, I'm not suggesting that, and it's not at all necessary.
>>
>> Extended integer types typically have names with the form of reserved
>> identifiers. An implementation with 8-bit char and 64-bit int might
>> have, say, 32-bit short and a 16-bit type named, for example, "__int16".
>> <stdint.h> could then have:
>>
>> typedef signed char int8_t;
>> typedef __int16 int16_t;
>> typedef short int32_t;
>> typedef int int64_t;
>>
>> (and so on for uintN_t, [u]int_leastN_t, et al).
>>
>> If you were starting with C90 (which didn't have extended integer
>> types or <stdint.h>) and you wanted to permit 64-bit int while
>> still providing 8-bit, 16-bit, and 32-bit integer types, you might
>> reasonably consider adding "short short". But with the features
>> added in C99, that was no longer necessary.
>
> The C99 features aren't quite the same thing. Sometimes you don't want
> to specify hard integer widths. You just want an 'int', whatever width
> that happens to be, and also have a wider int and a narrower one. (For
> example, what type do you need to represent the least or most
> significant half of an int?)
C has no direct way to specify a type half as wide as int, and it never
has. K&R1, published in 1978, says that the implementation for the
Honeywell 6000 use 36 bits for short, int, and long.
The intent is that short and long should provide different lengths
of integers where; practical; int will normally reflect the most
"natural" size for a particular machine. As you can see, each
compiler is free to interpret short and long as appropriate for its
own hardware. About all you should count on is that short is no
longer than long.
That last sentence understates things a bit; you could also safely
assume that short is no longer than int, and that int is no longer than
long.
> The C99 intN_t types also introduce some problems: what printf format do
> you use for int32_t for example, and which for int64_t?
"%" PRId32 for int32_t, "%" PRId64 for int64_t. The macros are defined in
<inttypes.h>.
#include <inttypes.h>
#include <stdio.h>
int main(void) {
int32_t x = INT32_MAX;
int64_t y = INT64_MAX;
printf("x = %" PRId32 ", y = %" PRId64 "\n", x, y);
}
Or if that's too ugly for you, you can safely convert an int32_t value
to long and use "%ld", or an int64_t value to long long and use "%lld".
#include <inttypes.h>
#include <stdio.h>
int main(void) {
int32_t x = INT32_MAX;
int64_t y = INT64_MAX;
printf("x = %ld, y = %lld\n", (long)x, (long long)y);
}
> With the non-specific types, you know that %d, %ld and %lld correspond
> to int, long int, and long long int respectively (even if there are only
> two different widths rather than tree. Or just one).
Yes.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-19 09:49 +0200 |
| Message-ID | <nro59m$ktj$1@dont-email.me> |
| In reply to | #93754 |
On 19/09/16 00:33, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 18/09/16 18:48, Keith Thompson wrote: >>> supercat@casperkitty.com writes: >>>> On Saturday, September 17, 2016 at 2:50:35 PM UTC-5, Keith Thompson wrote: >>> [...] >>>>> (Perhaps it's time for the next edition of the C standard to mandate >>>>> 2's-complement and tighten up some of the requirements, but I think >>>>> that's a separate discussion. The current standard has to cater >>>>> to the three possible representations -- and represention doesn't >>>>> imply a particular behavior.) >>>> >>>> The proper thing to do would be to recognize that implementations >>>> other than two's-complement are not "normal", and require that such >>>> implementations define macros to indicate their deviations from typical >>>> behaviors. >>> >>> Too complicated. If non-two's-complement systems are really obsolete, >>> why not just have the next C standard require two's-complement? If >>> there are any remaining one's-complement or sign-and-magnitude systems, >>> let them claim conformance to the old C11 standard, or just let them be >>> non-conforming. >> >> That would have my vote. (But I would not want signed integer overflow >> to be defined behaviour.) Drop padding bits in types too, any character >> sets that don't match ASCII for the first 128 characters, > > Padding bits might still be sensible in some cases. For example, there > have been systems in the past, presumably optimized for floating-point, > that represent integers as floating-point numbers with the exponent > fixed at zero (or something like that). It's worth asking whether we > can drop the idea of padding bits, but I'm not ready to assume that we > can do so. Such questions do need to be asked if the C standard were to drop support for "obsolete" hardware for future versions. I am confident that systems with padding bits are sufficiently obsolete and obscure that they can be dropped - but I would definitely want the committee to investigate such points properly, and not just take the word of some guy off Usenet! Perhaps the more significant change is that currently the C standards document are each written to succeed and replace previous versions. There is only one current valid ISO C standard - the version known as C11. A "C compiler" made today has to follow that version of the standard. If a future C standard dropped support for some older hardware, then there would really need to be a fork in the standards - so that C11 would still be a valid standard for old systems, with C20 (or whatever) going onward for modern ones. > >> CHAR_BIT that >> is not 8, 16 or 32, and int sizes that are not 16 or 32 bits. > > 64-bit int is perfectly sensible for 64-bit systems. The main > reason, I think, that it's not more common is that it leaves a > gap; if you have 8-bit char and 64-int, and short is the only type > in between, then you can't have both 16-bit and 32-bit integers. > Extended integer types, appropriate typedefs in <stdint.h>, should > solve that, but I don't think any implementations have taken > advantage of that (probably because of backward compatibility). > No, 64-bit int is not a sensible idea (IMHO). Extended integer types could solve some of the problems it would create, but at significant effort to toolchain authors, library writers (someone has to make a "printf" that supports the different sizes in some way), and significant inconvenience in data exchange. It is data exchange (by network protocols, file formats, etc.) that drives the need for standardisation here. And what is to be gained with 64-bit int? There is some hardware that can operate more efficiently on a 64-bit object than a 32-bit object - but such hardware is niche or obsolete (i.e., old Cray machines), and therefore excluded. Is there any software benefit in having 64-bit int? I think not - it is rare indeed that you actually need such a large integer type, and C already has perfectly good ones that you can use in that case (int64_t and long long int). It is not a coincidence that the only systems with 64-bit int are ancient, and pre-date the common usage of 64-bit processors.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-19 02:37 -0700 |
| Message-ID | <15210a4d-a350-4539-b36a-33bb408ce189@googlegroups.com> |
| In reply to | #93780 |
On Monday, September 19, 2016 at 8:49:24 AM UTC+1, David Brown wrote: > On 19/09/16 00:33, Keith Thompson wrote: > > No, 64-bit int is not a sensible idea (IMHO). Extended integer types > could solve some of the problems it would create, but at significant > effort to toolchain authors, library writers (someone has to make a > "printf" that supports the different sizes in some way), and significant > inconvenience in data exchange. It is data exchange (by network > protocols, file formats, etc.) that drives the need for standardisation > here. > Most printf formatting routines will work with 64 bit ints. The algorithm just take modulus ten and then divided until the integer is exhausted. As for data exchange, that should be independent of the representation the machine happens to use. With real values it's a bit fiddly (see my IEEE 754 portability routines), but for binary integer exchange, just a case of knowing the gotchas embedded in the standard. > > And what is to be gained with 64-bit int? There is some hardware that > can operate more efficiently on a 64-bit object than a 32-bit object - > but such hardware is niche or obsolete (i.e., old Cray machines), and > therefore excluded. Is there any software benefit in having 64-bit int? > I think not - it is rare indeed that you actually need such a large > integer type, and C already has perfectly good ones that you can use in > that case (int64_t and long long int). > You don't need any other type. If 64 bits are as efficient as 32 bits, there's no reason to use 32 bit types in main core current memory (you might want to compress to save memory in backing store or rarely accessed memory, but cutting 64 bits down to 32 isn't a particularly effective compression, though it's simple and fast). > > It is not a coincidence that the only systems with 64-bit int are > ancient, and pre-date the common usage of 64-bit processors.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-19 13:20 +0200 |
| Message-ID | <nrohlg$r1o$1@dont-email.me> |
| In reply to | #93787 |
On 19/09/16 11:37, Malcolm McLean wrote: > On Monday, September 19, 2016 at 8:49:24 AM UTC+1, David Brown wrote: >> On 19/09/16 00:33, Keith Thompson wrote: >> >> No, 64-bit int is not a sensible idea (IMHO). Extended integer types >> could solve some of the problems it would create, but at significant >> effort to toolchain authors, library writers (someone has to make a >> "printf" that supports the different sizes in some way), and significant >> inconvenience in data exchange. It is data exchange (by network >> protocols, file formats, etc.) that drives the need for standardisation >> here. >> > Most printf formatting routines will work with 64 bit ints. The algorithm just > take modulus ten and then divided until the integer is exhausted. As for > data exchange, that should be independent of the representation the > machine happens to use. With real values it's a bit fiddly (see my IEEE 754 > portability routines), but for binary integer exchange, just a case of > knowing the gotchas embedded in the standard. That's not the issue. For supporting extended integer types well, you are going to need new type specifiers for printf, as well as a way to write literals in the new types, and so on. The size of int itself is a minor point. >> >> And what is to be gained with 64-bit int? There is some hardware that >> can operate more efficiently on a 64-bit object than a 32-bit object - >> but such hardware is niche or obsolete (i.e., old Cray machines), and >> therefore excluded. Is there any software benefit in having 64-bit int? >> I think not - it is rare indeed that you actually need such a large >> integer type, and C already has perfectly good ones that you can use in >> that case (int64_t and long long int). >> > You don't need any other type. If 64 bits are as efficient as 32 bits, there's no > reason to use 32 bit types in main core current memory (you might want to > compress to save memory in backing store or rarely accessed memory, but > cutting 64 bits down to 32 isn't a particularly effective compression, though > it's simple and fast). I don't know what world you live in, but in my experience programs need to communicate - you have a great deal of data passing in and out. Doing the conversion between file or network types of different sizes, and internal 64 bit types, all at the boundary IO functions - that would be massively inefficient. And while a modern desktop cpu can add two 64-bit ints as fast as it can add two 32-bit ints, it takes twice as much memory bandwidth to load and store them, and twice as much cache space to track them - it would be hugely inefficient. Read the next paragraph again. >> >> It is not a coincidence that the only systems with 64-bit int are >> ancient, and pre-date the common usage of 64-bit processors. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-19 06:22 -0700 |
| Message-ID | <fb965f62-444d-4653-a532-72d122a9840a@googlegroups.com> |
| In reply to | #93792 |
On Monday, September 19, 2016 at 12:20:30 PM UTC+1, David Brown wrote: > On 19/09/16 11:37, Malcolm McLean wrote: > > I don't know what world you live in, but in my experience programs need > to communicate - you have a great deal of data passing in and out. > Doing the conversion between file or network types of different sizes, > and internal 64 bit types, all at the boundary IO functions - that would > be massively inefficient. And while a modern desktop cpu can add two > 64-bit ints as fast as it can add two 32-bit ints, it takes twice as > much memory bandwidth to load and store them, and twice as much cache > space to track them - it would be hugely inefficient. > My programs don't communicate all that much. They might get a mouse movement from the user - maybe 32 bytes - each frame. They then need to generate a frame in response to that, and pass it on to the graphics subsystem. You potentially have a big IO bottleneck in that direction, but it's all wrapped in interfaces. It's well understood that the system is meant to stand up to a frame refresh every video cycle. In between, they are doing lots of mathematics to generate a frame, and that's where the challenge lies - users expect reality simulations, but we can't simulate much reality in 1/50th of a second, even on a modern processor.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-19 12:46 +0100 |
| Message-ID | <nroj78$voo$1@dont-email.me> |
| In reply to | #93780 |
On 19/09/2016 08:49, David Brown wrote: > No, 64-bit int is not a sensible idea (IMHO). Extended integer types > could solve some of the problems it would create, but at significant > effort to toolchain authors, library writers (someone has to make a > "printf" that supports the different sizes in some way), and significant > inconvenience in data exchange. It is data exchange (by network > protocols, file formats, etc.) that drives the need for standardisation > here. > > And what is to be gained with 64-bit int? There is some hardware that > can operate more efficiently on a 64-bit object than a 32-bit object - > but such hardware is niche or obsolete (i.e., old Cray machines), and > therefore excluded. Is there any software benefit in having 64-bit int? > I think not - it is rare indeed that you actually need such a large > integer type, and C already has perfectly good ones that you can use in > that case (int64_t and long long int). In my dynamic language I've made the integer type 64 bits only. That saved having to deal with combinations of 32 and 64 bits, but didn't use any more memory as the variant types always allowed for 64 bits anyway (for doubles and pointers for example). (For compact, packed storage, such as C-compatible structs and arrays, it's possible to specifier narrower widths.) But in the implementation, most int values are 32 bits. Including the lengths of lists, arrays and strings. In C however you don't seem to have that choice if you want to make use of size_t for such lengths. On a 64-bit system size_t will itself be 64 bits. It's bad enough that pointers will be 64 bits even though most of the time the entire task - code and data - can be addressed with 32 bits. Anyway I agree that there is no real need for the default 'int' width for a language like C to be bigger than 32 bits. When needed, you specifically use something wider, although it would have been better if 'long' was actually always wider than 'int', as it means using the unwieldy 'long long' instead, or int64_t. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-19 16:20 +0200 |
| Message-ID | <nros6t$uso$1@dont-email.me> |
| In reply to | #93794 |
On 19/09/16 13:46, BartC wrote: > On 19/09/2016 08:49, David Brown wrote: > >> No, 64-bit int is not a sensible idea (IMHO). Extended integer types >> could solve some of the problems it would create, but at significant >> effort to toolchain authors, library writers (someone has to make a >> "printf" that supports the different sizes in some way), and significant >> inconvenience in data exchange. It is data exchange (by network >> protocols, file formats, etc.) that drives the need for standardisation >> here. >> >> And what is to be gained with 64-bit int? There is some hardware that >> can operate more efficiently on a 64-bit object than a 32-bit object - >> but such hardware is niche or obsolete (i.e., old Cray machines), and >> therefore excluded. Is there any software benefit in having 64-bit int? >> I think not - it is rare indeed that you actually need such a large >> integer type, and C already has perfectly good ones that you can use in >> that case (int64_t and long long int). > > In my dynamic language I've made the integer type 64 bits only. That > saved having to deal with combinations of 32 and 64 bits, but didn't use > any more memory as the variant types always allowed for 64 bits anyway > (for doubles and pointers for example). > Tradeoffs are different for interpreted and dynamic languages - having a single integer type keeps it simpler, and the performance costs of using 64-bit overall are negligible (except, as you point out, for compatibility with external functions, or for large arrays). > (For compact, packed storage, such as C-compatible structs and arrays, > it's possible to specifier narrower widths.) > > But in the implementation, most int values are 32 bits. Including the > lengths of lists, arrays and strings. > > In C however you don't seem to have that choice if you want to make use > of size_t for such lengths. On a 64-bit system size_t will itself be 64 > bits. It's bad enough that pointers will be 64 bits even though most of > the time the entire task - code and data - can be addressed with 32 bits. > You don't /have/ to use size_t for lengths or indexes - you can use int or any other type you want for most of the time. The value will get bumped up to a size_t before calling functions that take a size_t parameter, but that's all. It is always a risk to generalise, but I would expect that most uses of "size_t" will be as short-lived local variables or as parameters or return values for functions. In these cases, the variable will spend all or most of its time in a register, where there is no disadvantage in being 64 bits. > Anyway I agree that there is no real need for the default 'int' width > for a language like C to be bigger than 32 bits. When needed, you > specifically use something wider, although it would have been better if > 'long' was actually always wider than 'int', as it means using the > unwieldy 'long long' instead, or int64_t. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-19 07:32 -0700 |
| Message-ID | <493ea8d8-479f-4aff-8566-ce62e0a8ef44@googlegroups.com> |
| In reply to | #93780 |
On Monday, September 19, 2016 at 2:49:24 AM UTC-5, David Brown wrote: > Perhaps the more significant change is that currently the C standards > document are each written to succeed and replace previous versions. > There is only one current valid ISO C standard - the version known as > C11. Such a notion makes it impossible to know whether any particular piece of source text which has well-defined behavior today will continue to have that same well-defined behavior in future. The only way a standard can be meaningful is if C89, C99, and C11 continue to be regarded as standards regardless of what the Committee says. If the Committee insists that those aren't standards anymore, then the Committee should be ignored.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-19 11:26 -0700 |
| Message-ID | <lnshsvwxte.fsf@kst-u.example.com> |
| In reply to | #93780 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Perhaps the more significant change is that currently the C standards
> document are each written to succeed and replace previous versions.
> There is only one current valid ISO C standard - the version known as
> C11. A "C compiler" made today has to follow that version of the
> standard. If a future C standard dropped support for some older
> hardware, then there would really need to be a fork in the standards -
> so that C11 would still be a valid standard for old systems, with C20
> (or whatever) going onward for modern ones.
The previous editions of the standard are officially obsolete in the
eyes of ISO. That doesn't prevent anyone from using them. I'm not
convinced that a formal fork would be necessary. Implementations
could still claim C99 or C11 conformance.
[...]
> No, 64-bit int is not a sensible idea (IMHO). Extended integer types
> could solve some of the problems it would create, but at significant
> effort to toolchain authors, library writers (someone has to make a
> "printf" that supports the different sizes in some way), and significant
> inconvenience in data exchange. It is data exchange (by network
> protocols, file formats, etc.) that drives the need for standardisation
> here.
N1570 6.2.5p5:
A "plain" int object has the natural size suggested by the
architecture of the execution environment [...].
For a 64-bit target, surely 64 bits is "the natural size suggested by
the architecture".
> And what is to be gained with 64-bit int? There is some hardware that
> can operate more efficiently on a 64-bit object than a 32-bit object -
> but such hardware is niche or obsolete (i.e., old Cray machines), and
> therefore excluded. Is there any software benefit in having 64-bit int?
> I think not - it is rare indeed that you actually need such a large
> integer type, and C already has perfectly good ones that you can use in
> that case (int64_t and long long int).
I haven't looked into the relative performance of 32-bit and 64-bit
arithmetic on modern 64-bit systems. It seems plausible (but is quite
possibly wrong) that an N-bit system will perform most efficiently on
N-bit data.
On the other hand, I'm sure designers have expended some effort to make
32-bit arithmetic efficient -- largely *because* C implementations
typically have 32-bit int.
> It is not a coincidence that the only systems with 64-bit int are
> ancient, and pre-date the common usage of 64-bit processors.
Are there *no* modern 64-bit processors on which 64-bit arithmetic is
faster than 32-bit arithmetic? Can you be sure there will be no such
processors in the future?
--
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-19 09:10 -0700 |
| Message-ID | <ba107762-850a-46ae-b7e7-3b93ece343c6@googlegroups.com> |
| In reply to | #93809 |
On Monday, September 19, 2016 at 10:56:55 AM UTC-5, Keith Thompson wrote: > Are there *no* modern 64-bit processors on which 64-bit arithmetic is > faster than 32-bit arithmetic? Can you be sure there will be no such > processors in the future? There exist processors where 64-bit *arithmetic* is faster than 32-bit arithmetic. I would consider it unlikely that there will ever exist general-purpose platforms where large arrays of 64-bit values can be processed as efficiently as arrays of 32-bit values, since the latter will use memory bandwidth and cache capacity twice as effectively as the former, and those are the primary factors limiting speed in many applications. Unless a platform is intended to spend most of its time manipulating values that are larger than 32 bits, the performance gains from allowing 32-bit reads and writes will be sufficient to justify the relatively slight cost.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-19 09:33 -0700 |
| Message-ID | <15fa1eeb-eab4-4b28-83a6-0cff98ce9135@googlegroups.com> |
| In reply to | #93811 |
On Monday, September 19, 2016 at 5:10:58 PM UTC+1, supe...@casperkitty.com wrote: > On Monday, September 19, 2016 at 10:56:55 AM UTC-5, Keith Thompson wrote: > > Are there *no* modern 64-bit processors on which 64-bit arithmetic is > > faster than 32-bit arithmetic? Can you be sure there will be no such > > processors in the future? > > There exist processors where 64-bit *arithmetic* is faster than 32-bit > arithmetic. I would consider it unlikely that there will ever exist > general-purpose platforms where large arrays of 64-bit values can be > processed as efficiently as arrays of 32-bit values, since the latter > will use memory bandwidth and cache capacity twice as effectively as > the former, and those are the primary factors limiting speed in many > applications. Unless a platform is intended to spend most of its time > manipulating values that are larger than 32 bits, the performance gains > from allowing 32-bit reads and writes will be sufficient to justify the > relatively slight cost. > But not much data consists of large arrays of integers. I'm not saying you can't find examples. But data has to represent something, and the world is continuous, so typically you have a few counts, and then large numbers of real values. Which are often in a special format (e.g. an image has width and height, integers, then width * height pixel values, which are continuous, but usually represented on 0-1. Audio consists of a sample rate, integer, and a count of sample, integer, then usually millions of wave samples, which are continuous, and usually either represented as 32 bit floats or scaled on -32767 to 32767 and stored in sixteen bits). But I can't think of a common desktop file format that consists mostly of massive arrays of integral numbers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-19 11:54 -0700 |
| Message-ID | <lnd1jzwwhv.fsf@kst-u.example.com> |
| In reply to | #93809 |
Keith Thompson <kst-u@mib.org> writes:
[...]
> I haven't looked into the relative performance of 32-bit and 64-bit
> arithmetic on modern 64-bit systems. It seems plausible (but is quite
> possibly wrong) that an N-bit system will perform most efficiently on
> N-bit data.
[...]
One data point of questionable significance: the GNU C library
for x86_64 uses 64 bits for int_fast16_t and int_fast32_t.
(The <stdint.h> header is provided by glibc, not by gcc, and it
does this if __WORDSIZE == 64.)
--
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 3 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