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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-21 22:23 -0700 |
| Message-ID | <eb74bea1-6ec8-4f34-ae48-73ace8240fe4@googlegroups.com> |
| In reply to | #93882 |
On Thursday, September 22, 2016 at 5:03:09 AM UTC+1, Tim Rentsch wrote: > 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. > 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. > Things need to be tightened up and explained a bit. Shift operations on negative values should either be forbidden or defined to have the same effect as dividing or multiplying by a power of two. Then whilst it's in fact pretty easy to convert from two's complement to native and back for IO, it's not straightforwards. You wouldn't know that casting a negative to unsigned creates a two's complement representation, unless you had been told. The IEEE 754 portability library should be used widely, those routines or an equivalent should be in every programmer's toolbox and eventually standardised. But I agree with you. There's no reason to insist on a particular integer representation. The same is not quite true of floating point, because real numbers use every bit, and unless you are binary equivalent it's impossible to ensure that two programs will have the same results (the programs are badly coded if the difference matters, but that's another issue).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-22 08:09 -0700 |
| Message-ID | <db9e5c06-2dfa-4378-89a8-ec2e31534daf@googlegroups.com> |
| In reply to | #93883 |
On Thursday, September 22, 2016 at 12:23:54 AM UTC-5, Malcolm McLean wrote: > You wouldn't know that casting a negative to > unsigned creates a two's complement representation, unless you > had been told. The IEEE 754 portability library should be > used widely, those routines or an equivalent should be in > every programmer's toolbox and eventually standardised. The fact that (unsigned)-1 == UINT_MAX is 100% unambiguously mandated by the Standard. What isn't mandated, *even on two's-complement systems*, is that for any int x, (int)(unsigned)x == x.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-23 10:31 -0700 |
| Message-ID | <kfna8eyed61.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93883 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, September 22, 2016 at 5:03:09 AM UTC+1, Tim Rentsch wrote: >> 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. >> 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 with you. There's no reason to insist on a particular > integer representation. [...] My point is just slightly different, that the currently supported representation schemes should continue being supported. Another of C's important strengths is continuity: WG14 has deliberatly been very conservative in supporting the existing language and existing programs, and not changing the language out of some sense of what is fashionable or currently thought appropriate. That is part of what makes C be the language it is, and a major positive for the language. There are plenty of other languages available (I won't mention any names) that evolve more abruptly, for those who might want that.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-23 10:56 -0700 |
| Message-ID | <fc6e36f9-8ff9-460f-baa1-0e3e100d7b66@googlegroups.com> |
| In reply to | #93957 |
On Friday, September 23, 2016 at 12:31:11 PM UTC-5, Tim Rentsch wrote: > Another > of C's important strengths is continuity: WG14 has deliberatly > been very conservative in supporting the existing language and > existing programs, and not changing the language out of some Well, sort of. The Standard mostly avoids requiring that compilers act in ways that would break existing code. It refrains from mandating that compilers respect useful behavioral precedents set by earlier compilers for their target platforms or others like them, likely because they expected that compiler writers would naturally recognize the value in doing so, and thought that telling compiler writers to do things they obviously should would be akin to treating them like obtuse children. Unfortunately, compiler writers have treated the Standards Committees' respectful deference to compiler writers' judgment as to the value of precedents as an open invitation to throw behavioral precedents out the window and declare any code that relies upon them "broken". When C89 was ratified, it was expected that any behavior which would be supported by quality C compilers for a given platform and application field should be supported by quality C89 compilers for that same platform and field. Since then, the value of upholding some behavioral precedents has increased. A helpful reaction to that would have been to introducing new constructs which would allow similar semantics to be achieved more efficiently and deprecating the old ones. Simply erasing the old semantics by fiat, however, is much easier.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-29 08:03 -0700 |
| Message-ID | <kfnr382agtc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93960 |
supercat@casperkitty.com writes: > On Friday, September 23, 2016 at 12:31:11 PM UTC-5, Tim Rentsch wrote: >> Another >> of C's important strengths is continuity: WG14 has deliberatly >> been very conservative in supporting the existing language and >> existing programs, and not changing the language out of some > > Well, sort of. > > The Standard mostly avoids requiring that compilers act in ways that > would break existing code. It refrains from mandating that compilers > respect useful behavioral precedents set by earlier compilers for their > target platforms or others like them, [snip elaboration] What you consider to be "useful behavioral precedents" are not the same as what other people consider them to be.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-30 07:39 -0700 |
| Message-ID | <25585269-6e72-4404-a51a-174893beeb78@googlegroups.com> |
| In reply to | #94242 |
On Thursday, September 29, 2016 at 10:04:12 AM UTC-5, Tim Rentsch wrote: > What you consider to be "useful behavioral precedents" are not > the same as what other people consider them to be. Especially when using compilers of the 1980s and 1990s, code which exploited such behavior could run twice as fast or more than code which was strictly conforming, while being portable to most of the commonplace compilers that were in existence at the time. That would meet my definition of "useful", as well as the definition of many other people. The example code for 'printf' even includes such a piece of code, which would suggest Dennis Ritchie thought it was safe to rely upon the behavior when programming a machine that acted like the PDP-11.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-22 09:49 +0200 |
| Message-ID | <ns02d8$5cl$1@dont-email.me> |
| In reply to | #93882 |
On 22/09/16 06:03, Tim Rentsch wrote: > 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. > 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. > In general, I agree with you - the support for a wide range of architectures is a strength of C. But consider this: 1. There are no architectures that use anything other than two's complement, except for a few dinosaur mainframes, which are irrelevant for the future of C (they can keep their existing C compilers). It is reasonable to expect that no new processors will be made that use anything other than two's complement for their signed integer representation. (Please mention any counter-examples you know of.) 2. Restricting a future C standard to two's complement would simplify the standard. 3. There are a few programs or types of code that rely on two's complement representation. If this were standardised, it would be much easier to write such code in a portable way. 4. There are /many/ programs that unknowingly rely on two's complement representation - anything that deals with external binary formats (network protocols, file formats, interfacing to other languages, etc.) will use two's complement. Programs that use such data are likely to do so in a way that relies on two's complement formats without explicitly stating the requirements. There is no doubt that placing new restrictions on the hardware for C is not a decision to be taken lightly. But fixing on two's complement representation has clear advantages (albeit for only a small fraction of code - most code does not care), and no practical real-world disadvantages. To me, the question is not whether it would be a good idea or not - the answer is obvious. The question is merely if it is a useful enough idea to be worth the not insignificant effort required to make such a change in the C standards.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-22 08:34 -0700 |
| Message-ID | <53ee230b-ccd0-4ead-b6e5-a4250a36254c@googlegroups.com> |
| In reply to | #93884 |
On Thursday, September 22, 2016 at 8:49:14 AM UTC+1, David Brown wrote: > On 22/09/16 06:03, Tim Rentsch wrote: > > 1. There are no architectures that use anything other than two's > complement, except for a few dinosaur mainframes, which are irrelevant > for the future of C (they can keep their existing C compilers). It is > reasonable to expect that no new processors will be made that use > anything other than two's complement for their signed integer > representation. (Please mention any counter-examples you know of.) > I was thinking about how to represent types in B64. One way is to have C-like keywords, for double, int, pointer and string. Another way is to have special operators, so + means "do a floating point add" and a ^+ b mean "do an integer add". Both have obvious drawbacks. So another idea was to steal a couple of bits and tag the types. 10 would mean an integer, 01 a real, and 10 a pointer (strings would be untagged). So now our numbers are no longer two's complement. Now B64 is a long was from sweeping the computer world. But it will happen, naturally enough. And then it will start to drive hardware designs - chips will be designed so that B64 compilers have the optimal environment. So you can't assume that, just because two's complement is universal today, that situation will forever and always persist. You don't know what might drive future requirements.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-22 17:44 +0100 |
| Message-ID | <ns11pm$h65$1@dont-email.me> |
| In reply to | #93905 |
On 22/09/2016 16:34, Malcolm McLean wrote: > On Thursday, September 22, 2016 at 8:49:14 AM UTC+1, David Brown wrote: >> On 22/09/16 06:03, Tim Rentsch wrote: >> >> 1. There are no architectures that use anything other than two's >> complement, except for a few dinosaur mainframes, which are irrelevant >> for the future of C (they can keep their existing C compilers). It is >> reasonable to expect that no new processors will be made that use >> anything other than two's complement for their signed integer >> representation. (Please mention any counter-examples you know of.) >> > I was thinking about how to represent types in B64. One way is to have C-like > keywords, for double, int, pointer and string. Another way is to have special > operators, so + means "do a floating point add" and a ^+ b mean "do an That won't be popular. Usually integer ops are more common and deserve to use "+". (Haskell I think uses "+" for integer ops and "+." for floating point. But there it's to help out with type inference.) > integer add". Both have obvious drawbacks. So another idea was to steal a > couple of bits and tag the types. 10 would mean an integer, 01 a real, and > 10 a pointer (strings would be untagged). > > So now our numbers are no longer two's complement. You now have a 62-bit data size contained within a 64-word bit. The 62-bit part can still be two's complement, but everything is now a lot more complicated. And forget the idea of packing 8 8-bit chars into a 64-bit word. I thought the idea of a universal 64-bit type was to make things simpler? And not to not even being able to use all 64 bits! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-09-22 17:16 +0000 |
| Message-ID | <ns13lt$dfk$1@news.albasani.net> |
| In reply to | #93912 |
On 2016-09-22, BartC <bc@freeuk.com> wrote: > to use "+". (Haskell I think uses "+" for integer ops and "+." for > floating point. No, + for evrything.... In Haskell there are typeclasses so that anything that derives from Num can overload `+`. -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-22 18:26 +0100 |
| Message-ID | <ns148f$qak$1@dont-email.me> |
| In reply to | #93914 |
On 22/09/2016 18:16, Melzzzzz wrote: > On 2016-09-22, BartC <bc@freeuk.com> wrote: >> to use "+". > (Haskell I think uses "+" for integer ops and "+." for >> floating point. > > No, + for evrything.... In Haskell there are typeclasses so that anything > that derives from Num can overload `+`. > I must have been thinking of OCaml then. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-09-22 17:33 +0000 |
| Message-ID | <ns14lh$dfk$4@news.albasani.net> |
| In reply to | #93915 |
On 2016-09-22, BartC <bc@freeuk.com> wrote: > On 22/09/2016 18:16, Melzzzzz wrote: >> On 2016-09-22, BartC <bc@freeuk.com> wrote: >>> to use "+". >> (Haskell I think uses "+" for integer ops and "+." for >>> floating point. >> >> No, + for evrything.... In Haskell there are typeclasses so that anything >> that derives from Num can overload `+`. >> > > I must have been thinking of OCaml then. > In Haskell everything is function. There is no problem to define `add` as `+` and use that instead. eg: add = + sum a b = a `add` b -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-23 10:23 +0200 |
| Message-ID | <ns2oq3$hm6$1@dont-email.me> |
| In reply to | #93915 |
On 22/09/16 19:26, BartC wrote: > On 22/09/2016 18:16, Melzzzzz wrote: >> On 2016-09-22, BartC <bc@freeuk.com> wrote: >>> to use "+". >> (Haskell I think uses "+" for integer ops and "+." for >>> floating point. >> >> No, + for evrything.... In Haskell there are typeclasses so that anything >> that derives from Num can overload `+`. >> > > I must have been thinking of OCaml then. > Perhaps you were thinking of Forth? It has "+" for 16-bit (single word) addition, "d+" for 32-bit (double word), and "f+" for floating point addition.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-23 13:43 +0100 |
| Message-ID | <87twd6hjme.fsf@bsb.me.uk> |
| In reply to | #93933 |
David Brown <david.brown@hesbynett.no> writes: > On 22/09/16 19:26, BartC wrote: >> On 22/09/2016 18:16, Melzzzzz wrote: >>> On 2016-09-22, BartC <bc@freeuk.com> wrote: >>>> to use "+". >>> (Haskell I think uses "+" for integer ops and "+." for >>>> floating point. >>> >>> No, + for evrything.... In Haskell there are typeclasses so that anything >>> that derives from Num can overload `+`. >>> >> >> I must have been thinking of OCaml then. >> > > Perhaps you were thinking of Forth? It has "+" for 16-bit (single word) > addition, "d+" for 32-bit (double word), and "f+" for floating point > addition. Since OCaml has exactly the operators given, OCaml is more likely than Forth! This is an area where OCaml depart from other ML-derived languages where * is overloaded for int and real. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-23 14:58 +0200 |
| Message-ID | <ns38u9$5u6$3@dont-email.me> |
| In reply to | #93940 |
On 23/09/16 14:43, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 22/09/16 19:26, BartC wrote: >>> On 22/09/2016 18:16, Melzzzzz wrote: >>>> On 2016-09-22, BartC <bc@freeuk.com> wrote: >>>>> to use "+". >>>> (Haskell I think uses "+" for integer ops and "+." for >>>>> floating point. >>>> >>>> No, + for evrything.... In Haskell there are typeclasses so that anything >>>> that derives from Num can overload `+`. >>>> >>> >>> I must have been thinking of OCaml then. >>> >> >> Perhaps you were thinking of Forth? It has "+" for 16-bit (single word) >> addition, "d+" for 32-bit (double word), and "f+" for floating point >> addition. > > Since OCaml has exactly the operators given, OCaml is more likely than > Forth! This is an area where OCaml depart from other ML-derived > languages where * is overloaded for int and real. > Okay. I am not familiar with OCaml (it's on my list of languages to learn one day - but not yet near the top).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-22 18:14 -0700 |
| Message-ID | <7c04cc95-60e4-4a94-b0b6-f08d257f6052@googlegroups.com> |
| In reply to | #93912 |
On Thursday, September 22, 2016 at 5:44:54 PM UTC+1, Bart wrote: > On 22/09/2016 16:34, Malcolm McLean wrote: > > You now have a 62-bit data size contained within a 64-word bit. The > 62-bit part can still be two's complement, but everything is now a lot > more complicated. And forget the idea of packing 8 8-bit chars into a > 64-bit word. > String are implictly typed anyway. Some language do use "+" for string concatenation, and Perl plays fast and loose with numbers in string or binary representation, but mostly string operations cannot be performed on numbers or vice versa. So the "Lorem ipsum" syntax will create 64-bit aligned, zero-padded, nul-terminated string in memory, b64_strcat() will concatenate two such strings, and so on. However if you allow two's complement integers and reals in the same program, you have to distinguish them somehow. I'm not convinced we really needs two's complement - IEEE 754 will store up to 53 bit integers exactly, which is enough for most purposes. However processor design hasn't get advanced to the stage whereby IEEE 754-based indexing operations are efficient. And certainly no-one uses IEEE 754 for addresses. Options are types, but the idea is to get away from types, or separate operators, which is ugly, or tagging, which makes the binary representation unconventional, or banning integral numbers altogether, which is inefficient. There's no one obvious answer. > > I thought the idea of a universal 64-bit type was to make things > simpler? And not to not even being able to use all 64 bits! > This is it. I think the tagging idea is not going to work out. But I floated it as an example of why the assumption that two's complement shall endure forever might not hold.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-09-22 20:28 -0700 |
| Message-ID | <d1f60aef-21ec-41da-bcf3-9d28d9d3b350@googlegroups.com> |
| In reply to | #93919 |
On Thursday, September 22, 2016 at 8:15:52 PM UTC-5, Malcolm McLean wrote: > On Thursday, September 22, 2016 at 5:44:54 PM UTC+1, Bart wrote: > > On 22/09/2016 16:34, Malcolm McLean wrote: > > > > You now have a 62-bit data size contained within a 64-word bit. The > > 62-bit part can still be two's complement, but everything is now a lot > > more complicated. And forget the idea of packing 8 8-bit chars into a > > 64-bit word. > > > String are implictly typed anyway. Some language do use "+" for > string concatenation, and Perl plays fast and loose with numbers > in string or binary representation, but mostly string operations > cannot be performed on numbers or vice versa. So the "Lorem ipsum" > syntax will create 64-bit aligned, zero-padded, nul-terminated > string in memory, b64_strcat() will concatenate two such strings, > and so on. > However if you allow two's complement integers and reals in the > same program, you have to distinguish them somehow. I'm not > convinced we really needs two's complement - IEEE 754 will store > up to 53 bit integers exactly, which is enough for most purposes. > However processor design hasn't get advanced to the stage whereby > IEEE 754-based indexing operations are efficient. And certainly > no-one uses IEEE 754 for addresses. > Options are types, but the idea is to get away from types, or > separate operators, which is ugly, or tagging, which makes the > binary representation unconventional, or banning integral numbers > altogether, which is inefficient. > There's no one obvious answer. > > > > I thought the idea of a universal 64-bit type was to make things > > simpler? And not to not even being able to use all 64 bits! > > > This is it. I think the tagging idea is not going to work out. > But I floated it as an example of why the assumption that two's > complement shall endure forever might not hold. If you think 53 bits integers might be acceptable, one intriguing idea I came across is "NaN-coding". Google's not yielding anything for me atm, but my memory of what I read is you use double for all data. floating-point and integers just go straight in and you use the "space" of NaN representations -- which IIRC is surprisingly large -- to encode other non-numeric objects.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-23 00:12 -0700 |
| Message-ID | <b0777f35-54ea-4f97-860d-eba03efe4ca9@googlegroups.com> |
| In reply to | #93922 |
On Friday, September 23, 2016 at 4:28:21 AM UTC+1, luser droog wrote: > On Thursday, September 22, 2016 at 8:15:52 PM UTC-5, Malcolm McLean wrote: > > On Thursday, September 22, 2016 at 5:44:54 PM UTC+1, Bart wrote: > > > On 22/09/2016 16:34, Malcolm McLean wrote: > > > > > > You now have a 62-bit data size contained within a 64-word bit. The > > > 62-bit part can still be two's complement, but everything is now a lot > > > more complicated. And forget the idea of packing 8 8-bit chars into a > > > 64-bit word. > > > > > String are implictly typed anyway. Some language do use "+" for > > string concatenation, and Perl plays fast and loose with numbers > > in string or binary representation, but mostly string operations > > cannot be performed on numbers or vice versa. So the "Lorem ipsum" > > syntax will create 64-bit aligned, zero-padded, nul-terminated > > string in memory, b64_strcat() will concatenate two such strings, > > and so on. > > However if you allow two's complement integers and reals in the > > same program, you have to distinguish them somehow. I'm not > > convinced we really needs two's complement - IEEE 754 will store > > up to 53 bit integers exactly, which is enough for most purposes. > > However processor design hasn't get advanced to the stage whereby > > IEEE 754-based indexing operations are efficient. And certainly > > no-one uses IEEE 754 for addresses. > > Options are types, but the idea is to get away from types, or > > separate operators, which is ugly, or tagging, which makes the > > binary representation unconventional, or banning integral numbers > > altogether, which is inefficient. > > There's no one obvious answer. > > > > > > I thought the idea of a universal 64-bit type was to make things > > > simpler? And not to not even being able to use all 64 bits! > > > > > This is it. I think the tagging idea is not going to work out. > > But I floated it as an example of why the assumption that two's > > complement shall endure forever might not hold. > > If you think 53 bits integers might be acceptable, > one intriguing idea I came across is "NaN-coding". > Google's not yielding anything for me atm, but > my memory of what I read is you use double for all > data. floating-point and integers just go straight in > and you use the "space" of NaN representations -- which > IIRC is surprisingly large -- to encode other non-numeric > objects. > That's a good idea. You'd have to escape a string to keep binary compatibility. String consist of 11 set bits (NaN), then a "string" tag, then maybe a size, then the data in asciiz. Pointers similarly. Because we're only using 64 bit types, we get an extra three bits in the pointer to play with.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-22 10:57 -0700 |
| Message-ID | <801e1f43-f9f6-4a90-95be-6ea145f1f85d@googlegroups.com> |
| In reply to | #93905 |
On Thursday, September 22, 2016 at 10:35:00 AM UTC-5, Malcolm McLean wrote: > So you can't assume that, just because two's complement is universal > today, that situation will forever and always persist. You don't know what > might drive future requirements. Sign-magnitude is for many purposes a more useful blinkenlights format for humans than two's-complement. If one has 16 registers with a discrete output for each bit and wants to display those registers as sign-magnitude format using a small green bulb for positive numbers and a red bulb for negative, such display circuitry will be very easy and cheap if the values are in sign-magnitude format or ones'-complement format (one small drive transistors per bulb [two per bit], plus two larger drive transistors for the sign bit), but will be much more expensive if the registers are stored in two's-complement format. A ones'-complement ALU requires somewhat more circuitry than a two's- complement ALU, but that cost may be worth paying if it avoids the cost of adding a separate two's-complement decoder circuit for each register to handle its blinkenlights. I do not fault engineers in the 1960s and 1970s who judged such a tradeoff as a good one. I do not regard as even remotely plausible, however, the notion that such a tradeoff will ever again be even remotely desirable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-23 10:18 +0200 |
| Message-ID | <ns2ogt$gou$1@dont-email.me> |
| In reply to | #93905 |
On 22/09/16 17:34, Malcolm McLean wrote: > On Thursday, September 22, 2016 at 8:49:14 AM UTC+1, David Brown wrote: >> On 22/09/16 06:03, Tim Rentsch wrote: >> >> 1. There are no architectures that use anything other than two's >> complement, except for a few dinosaur mainframes, which are irrelevant >> for the future of C (they can keep their existing C compilers). It is >> reasonable to expect that no new processors will be made that use >> anything other than two's complement for their signed integer >> representation. (Please mention any counter-examples you know of.) >> > I was thinking about how to represent types in B64. One way is to have C-like > keywords, for double, int, pointer and string. Another way is to have special > operators, so + means "do a floating point add" and a ^+ b mean "do an > integer add". Both have obvious drawbacks. So another idea was to steal a > couple of bits and tag the types. 10 would mean an integer, 01 a real, and > 10 a pointer (strings would be untagged). > > So now our numbers are no longer two's complement. And they will no longer be efficient - they won't match the hardware, or any other software. That's fine in some use-cases. For interpreted languages, for example, it is often best to have a single general number type rather than multiple types with limited range but more efficient execution. > > Now B64 is a long was from sweeping the computer world. But it will happen, > naturally enough. And then it will start to drive hardware designs - chips will > be designed so that B64 compilers have the optimal environment. Yeah, right. They will be used in the flight control systems for flying pigs. > > So you can't assume that, just because two's complement is universal > today, that situation will forever and always persist. You don't know what might > drive future requirements. > I know it won't be B64.
[toc] | [prev] | [next] | [standalone]
Page 5 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