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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-23 11:48 -0700 |
| Message-ID | <kfn60pme9ki.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93884 |
David Brown <david.brown@hesbynett.no> writes: > 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 [elaboration] > > 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. Point 1 is irrelevant. Every statement is true, except for the exceptions. Point 2 is a non-argument. Of course taking things out of the language simplifies the language, but that isn't per se an argument for removing them, especially in cases like this where the text change involved is extremely minor. Point 3 is either laughable or stupid. If the word "portable" is redefined so it covers a smaller area, then of course it's easier to make things that are "portable". The result is meaningless. Point 4 is a bicycle training wheels argument - lots of people fall over on their bikes, so all bicycles ought to have training wheels. Even better, let's require the training wheels be welded to the frame and not removable, to protect the idiots who are too dumb to learn to ride a bike. I am philosophically opposed to any language restriction whose primary motiviation is to make it easier for stupid people to write programs. > 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. [...] Your idea of what constitutes a "practical real-world advantage" (or disadvantage) seems to be based primarily on how it affects you. I prefer taking a broader view.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-23 15:58 -0700 |
| Message-ID | <e1b36e19-9658-4f70-a1da-968a16b9efac@googlegroups.com> |
| In reply to | #93961 |
On Friday, September 23, 2016 at 1:48:59 PM UTC-5, Tim Rentsch wrote: I.e. no architectures which are capable of supporting enough features to make a modern C implementation plausible, use anything other than two's complement. > > > > > > 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. > > > 1. There are no architectures that use anything other than two's > > complement, except for [elaboration] > Point 1 is irrelevant. Every statement is true, except for the > exceptions. The only exceptions are machines for which it is highly unlikely that anyone would ever want to invest the effort necessary to write compiler that could do everything necessary for modern C compliance. > > 2. Restricting a future C standard to two's complement would > > simplify the standard. > Point 2 is a non-argument. Of course taking things out of > the language simplifies the language, but that isn't per se > an argument for removing them, especially in cases like this > where the text change involved is extremely minor. A number of operations whose outcome could be ambiguous when using integer representations other than two's-complement pose no ambiguity when using two's-complement form, and there are many places where the Standard could allow implementations to promise "loosely-constrained" behaviors that would only make sense in two's-complement implementations. > Point 3 is either laughable or stupid. If the word "portable" is > redefined so it covers a smaller area, then of course it's easier > to make things that are "portable". The result is meaningless. If shrinking the area by 1% results in a massive increase in the fraction of programs that can easily be made "portable", I'd say that's a pretty big win. > Point 4 is a bicycle training wheels argument - lots of people > fall over on their bikes, so all bicycles ought to have training > wheels. Even better, let's require the training wheels be > welded to the frame and not removable, to protect the idiots > who are too dumb to learn to ride a bike. I am philosophically > opposed to any language restriction whose primary motiviation > is to make it easier for stupid people to write programs. The authors of the C Standard must be stupid for regarding as useful the fact that then-current implementations require casts when performing arithmetic on short unsigned types if the result was going to be stored into an unsigned int.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-29 08:21 -0700 |
| Message-ID | <kfninteafzl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93970 |
supercat@casperkitty.com writes: > On Friday, September 23, 2016 at 1:48:59 PM UTC-5, Tim Rentsch wrote: > [...] >> Point 3 is either laughable or stupid. If the word "portable" is >> redefined so it covers a smaller area, then of course it's easier >> to make things that are "portable". The result is meaningless. > > If shrinking the area by 1% results in a massive increase in the fraction > of programs that can easily be made "portable", I'd say that's a pretty > big win. That is irrelevant to my point. >> Point 4 is a bicycle training wheels argument - lots of people >> fall over on their bikes, so all bicycles ought to have training >> wheels. Even better, let's require the training wheels be >> welded to the frame and not removable, to protect the idiots >> who are too dumb to learn to ride a bike. I am philosophically >> opposed to any language restriction whose primary motiviation >> is to make it easier for stupid people to write programs. > > The authors of the C Standard must be stupid for regarding as useful the > fact that then-current implementations require casts when performing > arithmetic on short unsigned types if the result was going to be stored > into an unsigned int. There is no indication they do regard it as useful. The job of WG14 is to standardize the language, not to improve the language, however much you might want it to be otherwise.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-30 07:42 -0700 |
| Message-ID | <7ff71f4a-415c-4307-a17b-a38fa33b1c2e@googlegroups.com> |
| In reply to | #94245 |
On Thursday, September 29, 2016 at 10:21:58 AM UTC-5, Tim Rentsch wrote: > > The authors of the C Standard must be stupid for regarding as useful the > > fact that then-current implementations require casts when performing > > arithmetic on short unsigned types if the result was going to be stored > > into an unsigned int. > > There is no indication they do regard it as useful. The job > of WG14 is to standardize the language, not to improve the > language, however much you might want it to be otherwise. The purpose should be to maximize the amount that can usefully be said about programs running on implementations. Saying that 99% of implementations will treat some construct in one of two distinct fashions which can easily be coded for is much more useful than simply saying that programmers have no right to expect any particular behavior.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-23 23:38 -0700 |
| Message-ID | <dd711aca-f51f-4304-a55d-c9192c811c64@googlegroups.com> |
| In reply to | #93961 |
On Friday, September 23, 2016 at 7:48:59 PM UTC+1, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > > > 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. > > Point 4 is a bicycle training wheels argument - lots of people > fall over on their bikes, so all bicycles ought to have training > wheels. Even better, let's require the training wheels be > welded to the frame and not removable, to protect the idiots > who are too dumb to learn to ride a bike. I am philosophically > opposed to any language restriction whose primary motiviation > is to make it easier for stupid people to write programs. > However if we standardised fput16be, fput16le, fget16be, fget16le and so on, then it would stop people thinking "no function to write an int in binary? Hom hum. Oh, I get it, you don't need one because you can use fread() and fwrite()". And it wouldn't be a huge change, just the addition of a few new functions.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-24 11:42 -0700 |
| Message-ID | <271f24c5-4e0a-44e9-94df-2b86de634bcf@googlegroups.com> |
| In reply to | #93971 |
On Saturday, September 24, 2016 at 1:38:45 AM UTC-5, Malcolm McLean wrote:
> However if we standardised fput16be, fput16le, fget16be, fget16le
> and so on, then it would stop people thinking "no function to write
> an int in binary? Hom hum. Oh, I get it, you don't need one because
> you can use fread() and fwrite()".
>
> And it wouldn't be a huge change, just the addition of a few new
> functions.
The amount of compiler complexity required to detect anything close to all
of the different ways that a programmer might try to convert a uint32_t
into four consecutive bytes in little-endian format is huge. Further, the
amount of programmer effort necessary to examine any such piece of code and
be certain that it behaves as intended would be significant.
If instead there were a standard macro to invoke an inline function or
intrinsic taking a "uint_least32_t" and a "void*", and store 32 bits of
the supplied value in four consecutive chunks of storage (8 bits each, regardless of the size of "char"), a compiler writer would only have to
look for and optimize one specific pattern. If a family of such functions
used a consistent naming convention, programmers who encounter any member
of the family would be able to instantly know what it does without having
to search elsewhere for the definition of a user-defined macro or function.
[Note: I suggest using a macro that chains to a function, rather than using
a function directly, to allow code to easily establish compatibility with
older compilers by defining its own definitions for such things when used
with compilers that don't support them, e.g.
#ifndef store32le
#define store32le supercat_store32be
static inline void supercat_store32le(void *dest, uint_least32_t value) {
unsigned char *d = dest;
d[0] = (value >> 8) & 255;
d[1] = (value >> 16) & 255;
d[2] = (value >> 24) & 255;
d[3] = (value >> 32) & 255;
}
#endif
That wouldn't work wonderfully if a header that maps such functions to
intrinsics is parsed after a file in which the above appears, but if
a standard macro indicated that a header for the system version would
be available, the above code could be preceded by
#ifdef __BYTEPARSE_H_AVAILABLE__
#include <byteparse.h>
#else
... user definitions of the necessary functions
#endif
The main purpose for the #ifdef checks on the functions is to allow for
the possibility that different pieces of code might need to define
different combinations of such functions. If all definitions are
functionally the same, there may be some redundant code generated, but
the functions should be small enough that some redundancy won't matter.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-24 14:13 -0700 |
| Message-ID | <lnbmzduhlr.fsf@kst-u.example.com> |
| In reply to | #93971 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> However if we standardised fput16be, fput16le, fget16be, fget16le
> and so on, then it would stop people thinking "no function to write
> an int in binary? Hom hum. Oh, I get it, you don't need one because
> you can use fread() and fwrite()".
>
> And it wouldn't be a huge change, just the addition of a few new
> functions.
Exactly how many new functions would be needed? Presumably 4 functions
for each supported size greater than 1 byte -- but how many such sizes
are there, and what are they?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-24 23:03 -0700 |
| Message-ID | <c0983f56-2a98-4a93-82ea-0d7de6324228@googlegroups.com> |
| In reply to | #93995 |
On Saturday, September 24, 2016 at 10:12:58 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > [...] > > However if we standardised fput16be, fput16le, fget16be, fget16le > > and so on, then it would stop people thinking "no function to write > > an int in binary? Hom hum. Oh, I get it, you don't need one because > > you can use fread() and fwrite()". > > > > And it wouldn't be a huge change, just the addition of a few new > > functions. > > Exactly how many new functions would be needed? Presumably 4 functions > for each supported size greater than 1 byte -- but how many such sizes > are there, and what are they? > A binary file format designer can of course choose any format whatsoever for integers. But unless he has some special purpose, in which case we should write special purpose code, the likely choices are ascii decimal, ascii hex, 16 bit, 32 bit or 64 bit. Then we can have signed, unsigned, big-endian or little-endian. The ascii formats are already catered for by strtol, except it needs renaming (something like atolong) and the specifications changed to make clear that it operates on ascii / utf-8 encoded data, not data in the native text format. If the execution character set is not ascii, you'll need both strtol and atolong, normally they are just aliases. The we've got three byte lengths, two formats, two signednesses, and two operations (read/write). So that makes 3*2*2*2 = 24 functions. More that you really want,, but not excessive, and since they all have predictable names and behaviour, not much to learn.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-25 11:29 +0100 |
| Message-ID | <87y42ge0gy.fsf@bsb.me.uk> |
| In reply to | #94012 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, September 24, 2016 at 10:12:58 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> [...] >> > However if we standardised fput16be, fput16le, fget16be, fget16le >> > and so on, then it would stop people thinking "no function to write >> > an int in binary? Hom hum. Oh, I get it, you don't need one because >> > you can use fread() and fwrite()". >> > >> > And it wouldn't be a huge change, just the addition of a few new >> > functions. >> >> Exactly how many new functions would be needed? <snip> > The we've got three byte lengths, two formats, two signednesses, and two > operations (read/write). So that makes 3*2*2*2 = 24 functions. More > that you really want,, but not excessive, and since they all have > predictable names and behaviour, not much to learn. Or you could have two functions and use a format specifier. That could be made considerably more flexible. And, at the expense of a bit more bloat, one could even add this to printf/scanf families. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-25 14:02 -0700 |
| Message-ID | <e27b618e-5dc1-4ef0-89f4-e9329150943d@googlegroups.com> |
| In reply to | #94016 |
On Sunday, September 25, 2016 at 5:29:57 AM UTC-5, Ben Bacarisse wrote: > Or you could have two functions and use a format specifier. That could > be made considerably more flexible. And, at the expense of a bit more > bloat, one could even add this to printf/scanf families. Back around 1990 I remember thinking there should be printf/scanf-like functions for binary data (they'd need to be separate functions because printf and scanf aren't designed to accommodate data that may contain zero bytes, newlines, etc. For such a thing to be most useful, however, it would need to be able to read data directly into a structure, which would imply that the library routines would have to know how the structure was laid out. Having brackets in the format string to indicate nested structures might work, but I'm not sure if any nice way of specifying the layout would always give the library function all the information it would need to know how things in the structure are laid out.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-25 15:17 -0700 |
| Message-ID | <lnvaxjtyjf.fsf@kst-u.example.com> |
| In reply to | #94052 |
supercat@casperkitty.com writes:
> On Sunday, September 25, 2016 at 5:29:57 AM UTC-5, Ben Bacarisse wrote:
>> Or you could have two functions and use a format specifier. That could
>> be made considerably more flexible. And, at the expense of a bit more
>> bloat, one could even add this to printf/scanf families.
>
> Back around 1990 I remember thinking there should be printf/scanf-like
> functions for binary data (they'd need to be separate functions because
> printf and scanf aren't designed to accommodate data that may contain
> zero bytes, newlines, etc.
printf("%c", 0) prints a null byte. putchar('\n') prints a newline.
What's the problem?
You can't have an embedded null character in a format string or in a
string pointed by an argument corresponding to a "%s" format, but apart
from that fprintf and fscanf certainly can deal with zero bytes and
newline. It's not common to use fprintf with a binary stream, but it's
well defined. (I'm assuming that you're really referring to fprintf and
fscanf, and not literally to printf and scanf which work with stdout and
stdin, which are opened in text mode.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-25 16:52 -0700 |
| Message-ID | <5a0a798e-84de-4514-b5ff-1b4e7d86549b@googlegroups.com> |
| In reply to | #94059 |
On Sunday, September 25, 2016 at 5:16:16 PM UTC-5, Keith Thompson wrote: > You can't have an embedded null character in a format string or in a > string pointed by an argument corresponding to a "%s" format, but apart > from that fprintf and fscanf certainly can deal with zero bytes and > newline. It's not common to use fprintf with a binary stream, but it's > well defined. (I'm assuming that you're really referring to fprintf and > fscanf, and not literally to printf and scanf which work with stdout and > stdin, which are opened in text mode.) The normal sscanf behaviors would be flummoxed by embedded zeroes in the data source. If something besides sscanf is needed for the case where the data source is a char*, a similar construct should be used when reading from files. If binary input uses something other than the scanf family, that would suggest that binary output should use something other than the printf family.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-25 13:59 -0700 |
| Message-ID | <70ec1beb-d57b-43e7-9dcf-585aceab54bb@googlegroups.com> |
| In reply to | #93995 |
On Saturday, September 24, 2016 at 4:12:58 PM UTC-5, Keith Thompson wrote: > Exactly how many new functions would be needed? Presumably 4 functions > for each supported size greater than 1 byte -- but how many such sizes > are there, and what are they? Signed (two's-complement) or unsigned, big-endian or little-endian, 8, 16, 32, or 64 bits. If one assumes that data will be packed into octets rather than into larger chunks, accommodating all possibilities would require 16 "get" functions and 16 "put" functions. Small compared with everything else the Standard requires. While such libraries wouldn't be sufficient to accommodate every I/O format that is in use, it would be sufficient to handle the vast majority of applications. Applications which need to handle 24 or 48-bit numbers, ones'-complement, or other less common format could simply encode or decode values manually without performance loss on common hardware, since most implementations would not be able to exploit hardware features when operating on such types.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-25 15:13 -0700 |
| Message-ID | <lnzimvtyp8.fsf@kst-u.example.com> |
| In reply to | #94051 |
supercat@casperkitty.com writes:
> On Saturday, September 24, 2016 at 4:12:58 PM UTC-5, Keith Thompson wrote:
>> Exactly how many new functions would be needed? Presumably 4 functions
>> for each supported size greater than 1 byte -- but how many such sizes
>> are there, and what are they?
>
> Signed (two's-complement) or unsigned, big-endian or little-endian, 8, 16,
> 32, or 64 bits. If one assumes that data will be packed into octets rather
> than into larger chunks, accommodating all possibilities would require
> 16 "get" functions and 16 "put" functions.
Why would you need special functions for 8-bit data?
Are we assuming file data is organized into octets? Nothing in
the standard currently makes that assumption.
Perhaps POSIX would be a better place for this. Of course POSIX
already has byte order conversion functions (htonl, htons, ntohl,
ntohs). It currently only supports 16 and 32 bits; perhaps adding
64-bit versions would be useful.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-25 15:50 -0700 |
| Message-ID | <974ed2fa-c409-4897-acb1-024de23437d4@googlegroups.com> |
| In reply to | #94058 |
On Sunday, September 25, 2016 at 5:12:50 PM UTC-5, Keith Thompson wrote: > Why would you need special functions for 8-bit data? In part because code which uses consistent syntax when writing 8-bit types as those of other sizes will be easier to read than code whose syntax varies according to data type. Further, the optimal code for the 8-bit signed case might vary on platforms where "signed char" uses something other than an 8-bit two's-complement representation. > Are we assuming file data is organized into octets? Nothing in > the standard currently makes that assumption. So many systems exchange data as octets that they represent a useful data interchange format even on systems whose native character size is something else. They would be a useful inclusion to the Standard if they were used for even 75% of information interchange (or even 25%). Given that they are used for 99%+ of information interchange, the existence of other comparatively rare forms should not be an obstacle to providing support for the vast- majority case. > Perhaps POSIX would be a better place for this. Of course POSIX > already has byte order conversion functions (htonl, htons, ntohl, > ntohs). It currently only supports 16 and 32 bits; perhaps adding > 64-bit versions would be useful. POSIX is limited to systems with 8-bit "char", is it not? The above functions would be useful on all systems that have to exchange data with anything that uses octets.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-28 08:13 -0700 |
| Message-ID | <kfnr384awh3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93971 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, September 23, 2016 at 7:48:59 PM UTC+1, Tim Rentsch wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> 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. >> >> Point 4 is a bicycle training wheels argument - lots of people >> fall over on their bikes, so all bicycles ought to have training >> wheels. Even better, let's require the training wheels be >> welded to the frame and not removable, to protect the idiots >> who are too dumb to learn to ride a bike. I am philosophically >> opposed to any language restriction whose primary motiviation >> is to make it easier for stupid people to write programs. > > However if we standardised fput16be, fput16le, fget16be, fget16le > and so on, then it would stop people thinking "no function to write > an int in binary? Hom hum. Oh, I get it, you don't need one because > you can use fread() and fwrite()". > > And it wouldn't be a huge change, just the addition of a few new > functions. I don't know how or if you think this relates to what I was saying, but AFAICT it does not.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-24 16:06 +0200 |
| Message-ID | <ns618u$dub$1@dont-email.me> |
| In reply to | #93961 |
On 23/09/16 20:48, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> 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 [elaboration] >> >> 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. > > Point 1 is irrelevant. Every statement is true, except for the > exceptions. > > Point 2 is a non-argument. Of course taking things out of > the language simplifies the language, but that isn't per se > an argument for removing them, especially in cases like this > where the text change involved is extremely minor. > > Point 3 is either laughable or stupid. If the word "portable" is > redefined so it covers a smaller area, then of course it's easier > to make things that are "portable". The result is meaningless. > > Point 4 is a bicycle training wheels argument - lots of people > fall over on their bikes, so all bicycles ought to have training > wheels. Even better, let's require the training wheels be > welded to the frame and not removable, to protect the idiots > who are too dumb to learn to ride a bike. I am philosophically > opposed to any language restriction whose primary motiviation > is to make it easier for stupid people to write programs. > >> 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. [...] > > Your idea of what constitutes a "practical real-world advantage" > (or disadvantage) seems to be based primarily on how it affects > you. I prefer taking a broader view. > I think you are wrong on every count here. Clearly I disagree with each of your comments on my points above - otherwise I would not have made the points in the first place. But in general, I believe you are viewing the whole thing from an ivory tower perspective. You know a great deal about the details of the C standards, and are willing and able to take those details into account in your coding. You are concerned about portability of code across the ranges from the earliest computers with C compilers to the strangest hypothetical systems in the future. That's all marvellous - people with your skills and knowledge are important in some lines of work, and it makes you an invaluable resource in a newsgroup like this. But I think it also makes you somewhat out of touch with the average C programmer. You are extraordinarily dismissive of people who simply code C for a living, and are happy when their code compiles and the test runs work - and who have neither the time, the knowledge, the interest or the skills to study the C standards or consider how their code might fail when run on a 1970's mainframe or a 2030's 128-bit int machine. To most programmers, the "C standard" is something they have heard of, but never seen themselves - very few employers will pay their coders to study the standards, so it is only oddballs like me that /enjoy/ such details who read them in their free time. To most programmers, "portable C code" is code that can be used on Linux and Windows, or which doesn't assume "int" is the same as "long" or that "int" can hold a pointer. Whenever you watch television, whenever you drive your car, whenever you use your computer - remember that the huge majority of the software around you is written by people that in your words are "stupid people" who are "too dumb to ride a bicycle". There is no way we can stop "stupid people" from writing code. There is no way we can make managers give their programmers the training and the time needed for high quality coding. There is no way we can make consumers be willing to pay enough for their products and software so that managers can afford to train their programmers. So is it better to think about ways that could make it easier for those programmers to produce better code - or is it better to simply dismiss them as idiots who should not be let near a computer?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-24 11:53 -0700 |
| Message-ID | <26b1209d-868e-49f4-a211-3d0f1019759d@googlegroups.com> |
| In reply to | #93976 |
On Saturday, September 24, 2016 at 9:06:42 AM UTC-5, David Brown wrote: > But I think it also makes you somewhat out of touch with the average C > programmer. You are extraordinarily dismissive of people who simply > code C for a living, and are happy when their code compiles and the test > runs work - and who have neither the time, the knowledge, the interest > or the skills to study the C standards or consider how their code might > fail when run on a 1970's mainframe or a 2030's 128-bit int machine. I do not think it unreasonable for programmers to expect that their code will never be run on a 1970s machine. Further, it should not be unreasonable for programmers to expect that a quality compiler for any future architecture should be capable of emulating the semantics of architectures that have been popular for over a decade (or in many cases two). Even if a requirement that a compiler emulate the semantics of an emulating the semantics of an older architecture meant that the generated code would run 10x as slowly as it could if it had targeted semantics that a newer machine could handle better, that would in most case not be a problem. If the old program ran acceptably on hardware that was 100 times slower than newer hardware, running it 10x as fast should be perfectly adequate even if it could run 100x as fast. Given the devolution of C over the last decade, an expectation that newer compilers will maintain compatibility with code for older ones is no longer reasonable, but there's no good reason it shouldn't have been.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-24 14:23 -0700 |
| Message-ID | <ln7fa1uh4z.fsf@kst-u.example.com> |
| In reply to | #93989 |
supercat@casperkitty.com writes:
[...]
> I do not think it unreasonable for programmers to expect that their code
> will never be run on a 1970s machine. Further, it should not be unreasonable
> for programmers to expect that a quality compiler for any future architecture
> should be capable of emulating the semantics of architectures that have been
> popular for over a decade (or in many cases two).
[...]
How much code runs on VAX emulators?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-25 14:16 -0700 |
| Message-ID | <177ae31d-6836-4448-9edd-339cf95aa974@googlegroups.com> |
| In reply to | #93996 |
On Saturday, September 24, 2016 at 4:22:57 PM UTC-5, Keith Thompson wrote: > supercat writes: > [...] > > I do not think it unreasonable for programmers to expect that their code > > will never be run on a 1970s machine. Further, it should not be unreasonable > > for programmers to expect that a quality compiler for any future architecture > > should be capable of emulating the semantics of architectures that have been > > popular for over a decade (or in many cases two). > [...] > > How much code runs on VAX emulators? I wasn't thinking of binary-interpreter emulation, but rather having compilers "behave" like traditional implementations. In the late 1980s compilers for the Macintosh could be configured to regard "int" as either 16 bits or 32 bits. This made it possible for such compilers to use code that expected "int" to be 16 bits without too much difficulty if any functions that needed to exchange data used types whose size was independent of "int". Things like "printf" were sometimes problematical since the meaning of "%d" is tied to "int", but for the most part there was no problem supporting code that expected that "int" would be 16 bits as well as code that expected that it would be 32 bits. Given that compiler writers in the 1980s were able to accommodate code that was designed for 16-bit "int" even on 32-bit platforms, should it not have been reasonable to expect that by the time 64-bit platforms became common, compiler writers would have figured out how to sensibly handle code written for 32-bit "int"?
[toc] | [prev] | [next] | [standalone]
Page 6 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