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. |
| |
Of course! What was I thinking? |
| |
Clearly the correct solution is to write a macro that checks if n is 0 and returns 1 if it is. Fight fire with fire! |
| |
1472. Anonymous (pcp05209714pcs.coatsv01.pa.comcast.net) –
04 May 2004 20:09:01
[ BAD SAT SCORES ]
Ha Ha Ha, a 1050 bad LOL, Try a 720 yeah, king dipshit right here, I didnt think you could do that bad on the SAT's but some how I did
|
| |
1471. bob (207.203.240.92) –
04 May 2004 15:17:37
[ FLAMING TEXT ]
enyone there |
| |
1470. bob (207.203.240.92) –
04 May 2004 15:16:57
[ FLAMING TEXT ]
hi stupids |
| |
1469. Tom 7 (gs82.sp.cs.cmu.edu) –
04 May 2004 14:06:27
[ Cap'n Crunch ]
brrrrump-bum-bum!
Well, where do I write you?
|
| |
1468. A. Mariaskin (dhcp-152-3-21-222.psych.duke.edu) –
04 May 2004 11:23:28
[ Cap'n Crunch ]
Hi Tom. You should speak ENGLISH sometime. I'm going to a conference too, but it's a conference about babies and baby-based research. I work on a project yelling at babies' mothers in front of them. I'm great.
How are you? I like the idea of writing a personal note in a public forum. I'm interested in general about the seemingly arbitrary boundaries between the public and the private. That's why when I am singing in my car and I'm at a stoplight, I like to croon to the people on either side of me. Other people's discomfort is funny. You should write me sometime, but not here because I probably won't come back to read it.
Amy |
| |
1467. SpArKy AnGeLz (191.a.002.cba.iprimus.net.au) –
29 Apr 2004 02:58:34
[ FLAMING TEXT ]
Hey Dis Site Sux!!! |
| |
The assignments in isolation weren't necessarily long, boring, repetitive, or factually incorrect. But reading and grading them all together was; that's what I meant.
The assignment was actually shorter than last year's (which it was based on) since it allowed you to elide the compatibility cases and had a simpler language. I think that a correct 2 or 3 page solution was possible. But you're right, we should have made it shorter still.
PS. It is easy to see who was logged onto unix45 at 2:55. ;) |
| |
Now wait a minute. Based on my grade I'd have to say it wasn't factually incorrect! As for long, boring, repetitive, etc . . . definitely. But we didn't ask for a long, boring, repetitive assignment any more than you (explicitly) asked to grade one. Still, you get some sympathy because doing the assignment once was bad enough, reading twenty of them might have made me have a seizure. |
| |
1464. Anonymous (213.249.155.237) –
28 Apr 2004 04:49:03
[ FLAMING TEXT ]
hhhghhggh
|
| |
1463. Tom 7 (gs82.sp.cs.cmu.edu) –
27 Apr 2004 16:41:51
[ Gender Test ]
There may be some truth to that, but a sample size of 3 is not particularly convincing... |
| |