1500. Tom 7 (h-66-167-250-95.phlapafg.dynamic.covad.net) –
11 May 2004 17:24:48
[ Sigh Of Relief! ]
Oops! I guess it's been too long, or I've been up too late...
At least I didn't say Yankovich. |
| |
THE ROBOTS ARE NOT FUCKING FUNNY. IM EPILEPTIC AND I THINK IT IS FUCKING DISGRACEFUL |
| |
1498. dwindlehop (jffwpr04.jf.intel.com) –
11 May 2004 14:15:58
[ Sigh Of Relief! ]
As a person with his own "Running With Scissors" Tour VIP pass, I would think you would know the man's name is "Weird Al" Yankovic.
http://www.weirdal.com/faq.htm |
| |
1497. Tom 7 (gs82.sp.cs.cmu.edu) –
11 May 2004 12:49:29
[ Sigh Of Relief! ]
That's a good idea!!!!!1! |
| |
1496. mike (h-66-167-250-95.phlapafg.dynamic.covad.net) –
11 May 2004 09:18:21
[ Sigh Of Relief! ]
Let's see it! scan and post it. |
| |
1495. Tom 7 (h-66-167-250-95.phlapafg.dynamic.covad.net) –
10 May 2004 22:34:35
[ News: ESCAPE ]
Soon Neal! All the pieces are now in place... I just need a free day or two to compose something. |
| |
1494. Neal (qwest170-dsl5.cybermesa.com) –
10 May 2004 22:31:10
[ News: ESCAPE ]
escape is dandy, but when are we getting the band back together? |
| |
1493. Tom 7 (h-66-167-250-95.phlapafg.dynamic.covad.net) –
10 May 2004 22:24:26
[ News: ESCAPE ]
It should work now. |
| |
1492. Tom 7 (h-66-167-250-95.phlapafg.dynamic.covad.net) –
10 May 2004 22:15:47
[ News: ESCAPE ]
Nope, looks like I screwed something up without realizing it.
I will fix. |
| |
1491. Mike (68.184.245.134.charter-stl.com) –
10 May 2004 20:55:17
[ News: ESCAPE ]
I can't register my player. username: mpn
That is: Escape win32 200404260
Connecting to escape.spacebar.org...
try 21532 27685...
fail: [fail (bug) register]
try 12254 12452
fail: [fail (bug) register]
Is the server just down? |
| |
1490. Tom 7 (gs82.sp.cs.cmu.edu) –
10 May 2004 17:32:26
[ News: ESCAPE ]
Cool! Yeah, chip's challenge was in my top 5 shareware games of the 90s, for sure... |
| |
1489. Mike (68.184.245.134.charter-stl.com) –
10 May 2004 17:24:21
[ News: ESCAPE ]
Escape rules! I love Chip's Challenge so this game is perfect for me. I even used to have "chip's challenge" listed in my interests section on LJ.
I think I'll make some levels for it eventually :). |
| |
1488. FredrickaJeanJacques (pool-68-237-83-190.ny325.east.verizon.net) –
08 May 2004 13:01:06
[ FLAMING TEXT ]
This site is the shit. You can make your names in any style and color. I love this fucking website |
| |
I've used DosBox, which is great, although these emulators for the adventure game format are even better because you can use them at higher resolution, etc. |
| |
supposed to say look for and grabbing |
| |
Try looking for a grabbing DosBox. It's an emulator that runs under windows. Not only does it emulate a 486, it emulates several soundcards, allowing you to play many of the older SQ series games. |
| |
Yeah, I probably do. =)
Once you've programmed 3D graphics it's hard to play a game without thinking about how it's done, you know? |
| |
dude, those are some AMAZING fucken explosions. you have no idea how long i sat there throwing bombs just to watch the explosions. hmm, actually... you probably do. |
| |
I think there's an argument to be made if you're actually at the end of the file, yeah. But the spec says it fails if the end of file is "reached" and I don't see how we can reach anything if we don't move. In addition, if one reads a single byte file in a call to fread(b, 1, 1, f), this "reaches" the end of file in some sense, but of course should succeed. |
| |
I was going to say that you could kind of see the design making sense it it was a specification that was trying to avoid a divide-by-zero: that you might at some point multiply size * num_elem to get the total bytes to read, and later divide bytes_read / size to get the actual num_elem read. But that argument doesn't really convince me.
On the other hand, I think you're looking at this solely from the point of view of varying the size of the element, leading to a 'natural' conclusion. But if we look at the behavior of fread() relative to feof(), we could also assert a pretty plausible behavior: fread() should always return 0 if feof() is true.
If you buy that behavior, you're now stuck with fread(buffer,0,1,f) returning 1 if not at EOF and 0 if at EOF, which is probably not what you want either. You could argue that the 0-lengthness should win out over the feof()ness--"i'm not actually asking for any data, so it doesn't matter if there's any data there or not"--but I'm not convinced that in practical code this might not be the opposite of what you want. Certainly if you fclose(f), I don't think fread(buffer,0,1,f) should return 1, although I guess that's probably undefined anyway. |
| |
I don't doubt that there are uses for the special case, but that's not important to me. (It's not prima facie obvious to me that even in your example, the programmer wouldn't want to do the overhead block even on zero-sized objects. I do in my code, which is basically the same. Of course, he'd also have to deal with the special situation of malloc(0), which is at least documented!)
How can we "fail" to read 0 bytes? That's what I don't understand. If it's not a failure, then the function doesn't implement the spec. You argue that the observable effects of failure and success are the same (other than the return value). I agree. But why would fread then choose failure instead of success (which it can obviously also attain)... sheer pessimism? That doesn't make sense to me.
I've been pointed to other specifications for this function that do point out the special case. If it's well-known that there are special cases to "help" you, then programmers can use those (maybe to benefit) and it's not *as* bad. I would have spent less time debugging this had it been documented. But it still makes it harder to understand and write code, because you have to remember the special cases in addition to the general specification. Therefore I contend that general specifications are always better.
Adam: it does also crash on win32, but Microsoft is not responsible for the design of the ANSI C library. ;) In any case, this argues that there is some kind of standard surrounding this behavior, but that it is not documented well. |
| |
I don't know... whether or not you can "successfully read" 0 bytes seems like a philosophical question to me. Specifically, since the contents of the buffer you're reading into don't change, a "success" would have the exact same effect as a "failure." Suppose you were doing this:
size_t size = get_size_somehow();
char *buffer = (char*)malloc(size);
if (fread(buffer, size, 1, file))
{
// do something with a lot of overhead
}
I think this is what the authors were thinking: in most cases, somebody is going to have to check for zero somewhere, so we might as well do it in the library. If they return 0, then somebody writing this code doesn't need to check before the big-overhead part; if they return 1, then somebody writing code like yours doesn't need to check. I think you could make a case for either.
Not that there's any excuse for not following the standard, or for having bad documentation, though. I think the spec should state explicitly what happens in this case. |
| |
1478. Arthur (supercow.kabel.utwente.nl) –
05 May 2004 04:41:22
[ Cap'n Crunch ]
Google is your friend! |
| |
1476. SuperSaiyanFOTS (adsl-68-122-140-158.dsl.sndg02.pacbell.net) –
05 May 2004 00:54:08
[ UPD: DBZ Shirts ]
w00t i was dumb |
| |
It looks like it's a case where the specification was ambiguous long ago, someone chose a concrete implementation, and we're stuck with it.
Curiously, the documentation you read is in error. ISO C requires that 0 be returned only on error, even when size or nmemb are 0. UNIX documentation says the opposite.
Here is a bug report filed in 1998 about this:
http://www.opengroup.org/platform/resolutions/bwg98-007.html
Still, try this with VC++. I bet you'll get the same thing. |
| |