site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Date: Mon, 7 Jan 2008 09:49:19 -0800 From: Norm Green <norm.green@gemstone.com> Subject: RE: fread/fwrite/fflush bug ... Someone pointed out the fpurge() function. Calling fpurge() on the reader before the 2nd read fixes the problem. David _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This might be one fix for your code, but how about other code not yet ported to OSX that is looking for "proper" behavior (making an assumption here). Reading the man page for fpurge, it says: "For input streams this discards any input read from the underlying object but not yet obtained via getc(3)...". I interpret this to mean the following would fail (but not your example): - writer writes say 1000 bytes - reader is told to read one byte at location 0 (but fread gets a buffer full) - writer changes all the data - all 1000 bytes - reader reads location 1, and gets old data (which it already had in the buffer) - reader keeps reading a byte at a time. When the internal buffer is exhausted THEN it would start reading the actual file again, and get a buffer of correct data. Based on the man page, one could assume that the seek backwards should cause the data in the buffer to get flushed as if fpurge was called. Apparently fread looks to see if the requested bytes are located in its buffer in all cases, and if so, uses them. This email sent to site_archiver@lists.apple.com