Wednesday, January 18, 2012
99 ways to program a hex, Part 10: C99, const and restrict correctness, assertive
It's pretty much the same as yesterday's version, only in C99:
/*************************************************************************
*
* Copyright 2012 by Sean Conner. All Rights Reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* Comments, questions and criticisms can be sent to: sean@conman.org
*
*************************************************************************/
/* Style: C99, const and restrict correctness, assertive */
#include <stdio.h>
#include <ctype.h>
#include <string.h>
#include <stdlib.h>
#include <assert.h>
#define LINESIZE 16
static void do_dump (FILE *const restrict,FILE *const restrict);
/****************************************************************/
int main(const int argc,char *const restrict argv[])
{
assert(argc >= 1);
assert(argv != NULL);
assert(argv[0] != NULL);
if (argc == 1)
do_dump(stdin,stdout);
else
{
for (int i = 1 ; i < argc ; i++)
{
FILE *fp = fopen(argv[i],"rb");
if (fp == NULL)
{
perror(argv[i]);
continue;
}
printf("-----%s-----\n",argv[i]);
do_dump(fp,stdout);
fclose(fp);
}
}
return EXIT_SUCCESS;
}
/******************************************************************/
static void do_dump(FILE *const restrict fpin,FILE *const restrict fpout)
{
unsigned char buffer[BUFSIZ];
size_t offset;
size_t bread;
assert(fpin != NULL);
assert(fpout != NULL);
offset = 0;
while((bread = fread(buffer,1,BUFSIZ,fpin)) > 0)
{
unsigned char *pbyte = buffer;
while (bread > 0)
{
char ascii[LINESIZE + 1];
fprintf(fpout,"%08lX: ",(unsigned long)offset);
size_t j = 0;
do
{
fprintf(fpout,"%02X ",*pbyte);
if (isprint(*pbyte))
ascii [j] = *pbyte;
else
ascii [j] = '.';
pbyte ++;
offset ++;
j ++;
bread --;
} while ((j < LINESIZE) && (bread > 0));
ascii [j] = '\0';
if (j < LINESIZE)
for (size_t i = j ; i < LINESIZE ; i++) fprintf(fpout," ");
fprintf(fpout,"%s\n",ascii);
}
if (fflush(fpout) == EOF)
{
perror("output");
exit(EXIT_FAILURE);
}
}
}
/***************************************************************/
Not much to say about today's version.
- Part 9: C89, const correctness, assertive
- Part 11: C89, const correctness, assertive, GCC extensions
It was a misconfiguration
Yesterday's problem? It turned out to be a misconfiguration. Or rather, the configuration file format changed enough to break the configuration files checked in for regression testing.
Sometime since the last regression test, parameters that deal with time can now take a suffix to denote the time unit being used (for example, “9s” for 9 seconds, or “3d” for 3 days) and the base unit for non-suffixed values changed (from “seconds” to “milliseconds” I'm guessing) so what was once configured to time out in 15 seconds would now timeout in 15 millisecconds, and thus, the one component would think the other side timed out.
I saw the initial changes, but I neglected to update a few key parameters properly. It's an easy thing to miss (as it took me two tries to change all the affected parameters).
Sigh.
But that aside, the regression test finally ran (well, it's still running—it takes hours for the thing to run).
A bit about buggy whips
I haven't talked much about SOPA and PIPA but I've been aware of them for some time. In fact, on the sites I normally travel, it was hard not to come across it. And then today … everybody by now has heard of SOPA.
And yes, it's bad. But why? It could be that there are a lot of people with money that want bits to have color, when bits have no color:
Bits do not naturally have Colour. Colour, in this sense, is not part of the natural universe. Most importantly, you cannot look at bits and observe what Colour they are. I encountered an amusing example of bit Colour recently: one of my friends was talking about how he'd performed John Cage's famous silent musical composition 4′33″ for MP3. Okay, we said, (paraphrasing the conversation here) so you took an appropriate-sized file of zeroes out of /dev/zero and compressed that with an MP3 compressor? No, no, he said. If I did that, it wouldn't really be 4′33″ because to perform the composition, you have to make the silence in a certain way, according to the rules laid down by the composer. It's not just four minutes and thirty-three seconds of any old silence.
My friend had gone through an elaborate process that basically amounted to performing some other piece of music four minutes and thirty-three seconds long, with a software synthesizer and the volume set to zero. The result was an appropriate-sized file of zeroes—which he compressed with an MP3 compressor. The MP3 file was bit-for-bit identical to one that would have been produced by compressing /dev/zero … but this file was (he claimed) legitimately a recording of 4′33″ and the other one wouldn't have been. The difference was the Colour of the bits. He was asserting that the bits in his copy of 433.mp3 had a different Colour from those in a copy of 433.mp3 I might make by means of the /dev/zero procedure, even though the two files would contain exactly the same bits.
Now, the preceding paragraph is basically nonsense to computer scientists or anyone with a mathematical background. (My friend is one; he'd done this as a sort of elaborate joke.) Numbers are numbers, right? If I add 39 plus 3 and get 42, and you do the same thing, there is no way that “my” 42 can be said to be different from “your” 42. Given two bit-for-bit identical MP3 files, there is no meaningful (to a computer scientist) way to say that one is a recording of the Cage composition and the other one isn't. There would be no way to test one of the files and see which one it was, because they are actually the same file. Having identical bits means by definition that there can be no difference. Bits don't have Colour; computer scientists, like computers, are Colour-blind. That is not a mistake or deficiency on our part: rather, we have worked hard to become so. Colour-blindness on the part of computer scientists helps us understand the fact that computers are also Colour-blind, and we need to be intimately familiar with that fact in order to do our jobs.
The trouble is, human beings are not in general Colour-blind. The law is not Colour-blind. It makes a difference not only what bits you have, but where they came from. There's a very interesting Web page illustrating the Coloured nature of bits in law on the US Naval Observatory Web site. They provide information on that site about when the Sun rises and sets and so on … but they also provide it under a disclaimer saying that this information is not suitable for use in court. If you need to know when the Sun rose or set for use in a court case, then you need an expert witness—because you don't actually just need the bits that say when the Sun rose. You need those bits to be Coloured with the Colour that allows them to be admissible in court, and the USNO doesn't provide that. It's not just a question of accuracy - we all know perfectly well that the USNO's numbers are good. It's a question of where the numbers came from. It makes perfect sense to a lawyer that where the information came from is important, in fact maybe more important than the information itself. The law sees Colour.
What Colour are your bits? - Ansuz - mskala's home page
Or maybe it goes deeper than that—that the Inernet is such a disruptive technology that it threatens all sorts of industries, not only because bits have no color, but that it democratizes the means of global mass production, and that may scare some people more than the colorless bits:
What's different now is that distribution costs have disappeared. Suddenly, hobbyists have the same reach as businesses and are seen as real competition. Unfortunately, hobbyists don't distribute for the same reasons and don't play by the same rules. That's a fundamental problem.
A business is run for money, even if it does creative things. It has expenses and investments. It has a physical location and distribution channels. A business has to play by the rules in order to keep earning money, and because they are vulnerable—to lawsuits, regulations, taxes and police.
A hobbyist is doing it for love, not money. He has almost no expenses— just put your music up on YouTube and promote it online, all for free. Since there is no monetary investment, no payroll, no building, no sales channel, the hobbyist does not have a lot to lose.
If a business breaks the law, it can be sued or a government can close it down. There aren't that many businesses in a given field, so it's relatively easy to police them. There are millions of hobbyists and they require no money to do their thing. Even if you sue them, you can't recover your costs because they have no money. And there are too many to shut them down individually.
On top of that, the internet is global, so many of the people a business wants to sue or arrest aren't even within its jurisdiction. The internet didn't just drop distribution costs, it made it possible to evade restrictive laws passed to protect publishers.
Viewing this as hobbyists vs. businesses makes a difference. The current story from publishers is that everything was fine until the internet came along and pirates started to steal all their products. The reality is that it's not just about piracy.
Hobbyists have always been there, creating art, music, books, comics, open source software, etc. The internet has just forced these two worlds into collision. Even if all the piracy disappeared, publishers would still be in trouble.
Part 47: Intellectual Property
Whatever the case, SOPA/PIPA is bad, and should be rejected by the United States govevernment. It's bad enough that I have to keep buying all these damned buggy whips when it's clear that the future is going to be these horseless carriages I keep hearing about.
