Tom 7 Radar

				x Other ways to read Tom 7 Radar: RSS feed for aggregator software

Entries from May 2004

p
e
r
s
o
n
a
l Idea (18 May 2004 at 21:30)

In the interests of rejuvenating our beleaguered city, I think that we should rename one of our sports teams to The Pittsburg Geagles. It doesn't matter which one.

(9 comments) [ comment ]

p
e
r
s
o
n
a
l Sigh Of Relief! (11 May 2004 at 00:47)

(sound of sigh of relief)

I found my birth certificate! (After many hours of search.) I need this to get a passport tomorrow.

It was safely under my 1999 Weird-Al Yankovik "Running With Scissors" Tour VIP pass, naturally.

(10 comments) [ comment ]

p
e
r
s
o
n
a
l News: ESCAPE (10 May 2004 at 14:07)

I'm currently helping to "proctor" an exam, which really just means sitting still for three hours watching the squirming, tortured faces. That's not very fun. (Although, in contrast, we can all breathe a collective sigh of relief when it's over!)

Aside from finishing up grading and being sick, I spent much of the weekend hacking on escape. Players can now rate levels that they play, which will (I hope) let me assess which levels are best so that I can create a collection of high-quality "Official" levels. The capability to submit puzzles that you make is already there, so if you're looking for something to do as your bored summer begins, I would love for you to try it out. Very soon will be a "1.0" release, at which time I'll make a nicer web page and try to expose the game to more than just readers of this weblog.

In other related news, Adam made a fantastic port of Escape to the Nintendo for his NES development class project. He managed to implement all the game rules, and all of the 18x10 levels are supposed to be included in it. I made some box artwork (complete with laser background) for the game. He's in the final polishing stages now... it will be available for download soon!

Categories: drawings video games escape

(59 comments — almost 18 years ago) [ comment ]

p
e
r
s
o
n
a
l Screwed like me, thanks to libc (04 May 2004 at 19:50)

The UNIX C library is dumb beyond what I already knew. Here's what the man page says for fread (which is a function that tries to read nmemb blocks of length size from the file stream into ptr):

size_t fread( void *ptr, size_t size, size_t nmemb, FILE *stream);

... RETURN VALUE fread and fwrite return the number of items successfully read or written (i.e., not the number of characters). If an error occurs, or the end-of-file is reached, the return value is a short item count (or zero).

Based on this spec, what do you suppose the following code should print? I'm asking to read 1 block of zero bytes from "test.c", which exists and is non-empty.

FILE * ff = fopen("test.c", "r"); char r[100]; printf("fread(r, 0, 1, ff) = %d\n", fread(r, 0, 1, ff));

If you're me reading the spec and writing this code, then fread should return 1. Why? Well, I've asked for it to read 1 block of size 0, and it will return the number of items successfully read, unless there is an error or the end of file is reached. It doesn't need to read any bytes, so it certainly won't "reach" the end of file. It doesn't make sense to deliberately read fewer items than is possible (the "If an error occurs..." clause seems to imply, though not require, that a short item count is only returned if it can't read all of the items requested). Therefore, I believe the fread above should always return 1, since it can successfully read one zero-byte element from the file into r.

I think this reading of the spec will be obvious to most of the people I work with; if you disagree, I welcome your interpretation.

Well, what does it do? It returns zero. In fact, there is a special case of the implementation to deal with this case. Check out glibc-2.3.2/libio/iofread.c:

_IO_size_t _IO_fread (buf, size, count, fp) void *buf; _IO_size_t size; _IO_size_t count; _IO_FILE *fp; { _IO_size_t bytes_requested = size * count; ... if (bytes_requested == 0) return 0; ... /* continue sanely */

At best, the specification is ambiguous. I don't actually think that it is, unless you can consider 0-byte argument an occurrence of an "error." At worst, this is another example of one of UNIX's worst philosophies (I suppose I project my negative opinions of perl onto UNIX in general, but this example seems to bear that out!): Finding cases where I'm doing something that's seemingly useless or degenerate, and then replacing that with "more useful" behavior. I suppose the argument that the designers of the C library (if they indeed intended this behavior and it is not just glibc interpreting the apparent ambiguity) would use is, "Why would you ever want to read blocks of zero length?" And so they "helpfully" give me an "error" instead of just doing what I asked.

(Aside: I also discovered recently that an empty \begin{enumerate} \end{enumerate} is illegal in LaTeX, which is precisely the same kind of stupid misdesign/bug.)

I don't believe that a reasonable use scenario should be a pre-requisite for a library function having a general specification. Implementing the spec even in seemingly useless corner cases should just be what you do. But having a reasonable use for such "corner" cases makes the situation even worse, and in this case I have one. (The difficulty in tracking down a bug in real code to this problem is the reason that I'm bothering to compose this rant in the first place.) Here it is. Suppose you have a file format where you store data objects of arbitrary length (say, strings) by first writing their length n, then writing n bytes. (RIFF based file formats like MIDI and WAV use this scheme, among others.) How do you read such a format? Well, fread an integer, and then, perhaps fread(buffer, n, 1, ff). Well, if n is ever zero, as it is in some of my files, then you are screwed like me, thanks to libc.

(10 comments — almost 15 years ago) [ comment ]

Entries from April 2004

p
e
r
s
o
n
a
l Cap'n Crunch (23 Apr 2004 at 21:10)

Jason and I have been writing a lot of code for Automated Theorem Proving recently, and enjoying it quite a lot.

I would describe the process of writing this particular piece of code today as "programming by accumulation of invariants."

The whole process of writing this prover is somewhat like the architecting by accumulation of modules. Integrating them into a working thing will, I hope, be easier than the reputation this methodology has due to our foresight and programming language. Yay types!

This is going to be a busy weekend and coming week. I guess it is crunch time after all. The revisions for the LICS paper are due on Sunday, which is really obnoxious because it means I will spend the weekend doing them. I don't really understand 10 page limits on conference papers--suggested lengths are fine, but doesn't it make more sense to simply have peer review determine the appropriate level, content, and length for a submission?

(5 comments) [ comment ]

... Apr 2004 continued

2
0
2
4 Posts from 2024

Oct Sep Aug Jul Jun May Apr Mar Feb Jan

2
0
2
3 Posts from 2023