Re: Padding Bits
- From: Richard Heathfield <rjh@xxxxxxxxxxxxxxx>
- Date: Mon, 11 Feb 2008 09:31:10 +0000
John Messenger said:
<snip>
If there are no compilers in the real world that use
padding bits in integer types, then my job of managing these people
becomes a lot easier.
Indeed. But of course it has not been shown that there are no such
compilers. All that has been shown is that only one of the small handful
of people who read your article over this weekend has come across a
hardware platform that uses padding bits.
I'm put in mind of a (blessedly hypothetical) physicist, being asked 35
years ago whether the irrational number 4.66920160910299067... had any
practical significance in the real world, and answering with a resounding
"NO, sir! None whatsoever."
And if you'd asked instead, say, whether anyone had used any non-ASCII
character sets, and it just happened that nobody who had done so
bothered to respond to your article, would you have concluded that
non-ASCII character sets do not now and will never exist?
Yes.
Then just hope and pray that your code never has to work on a mainframe.
ASCII is the de facto standard for C code in general and source code
distribution in general.
More or less true (although exceptions exist), but nevertheless beside the
point.
Any time one distributes source code via an
electronic medium (whether it is on a CD, or in a compressed archive such
as GZIP or ZIP or BZ or whatever, or in a simple uncompressed format,
etc.), they have committed to using a specific character encoding,
whether they are aware of it or like it or not.
It is fairly trivial, having taken delivery of such C code, to convert it
to another encoding. What is not so trivial is to identify all the code
that relies on the runtime data being encoded in ASCII. if(x == 9), for
example. Or if(x < 32) is quite common, too. As is ch - 48.
You, and your companions, in fact, distribute the source code for the
examples in the book "C Unleashed" in ASCII encoding, right?
You have, indeed, completely and utterly missed the point. The code I wrote
for that book works just fine on mainframes using non-ASCII encodings. All
you have to do is tell the 3270 emulator to convert ASCII to EBCDIC during
the file transfer.
<snip>
Did you and the others who wrote "C Unleashed" include any type of
disclaimer similar to the following?
"The source code on the companion CD is stored in the ASCII encoding
format. If you use any C compiler that does not expect the ASCII encoding
format, this code will most likely not compile. Don't blame this on the C
Standard--blame it on us".
No, we didn't include any such disclaimer. The book is intended for use by
programmers with some existing professional-level experience of C, and any
such people who use non-ASCII encodings will already know how to convert
ASCII to their own encoding. But I will say that, if any of the code from
the book were found to rely on a host environment that uses ASCII (or
indeed any specific encoding) at compile time or run time, we would
consider that to be a bug.
In the same way, I consider code that relies on the absence of padding bits
to be less good than code that does not have that reliance. Such
assumptions have a habit of becoming invalid at the worst possible moment.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.
- References:
- Padding Bits
- From: John Messenger
- Re: Padding Bits
- From: Ike Naar
- Re: Padding Bits
- From: John Messenger
- Re: Padding Bits
- From: Richard Heathfield
- Re: Padding Bits
- From: John Messenger
- Padding Bits
- Prev by Date: Re: Padding Bits
- Next by Date: Re: Who likes short shorts?
- Previous by thread: Re: Padding Bits
- Next by thread: Re: Padding Bits
- Index(es):
Relevant Pages
|