> It appears that the stdio that I'm linking against on OS X 10.9.5 > does not keep the file pointers synchronized between the system and > stdio.
Actually, I would say that any supposedly-portable software that depends on either behaviour is broken; AFAICT stdio has never promised either way. > In the case of tiff at least (haven't checked others) a syscall file > descriptor is passed to libtiff. Once it's inside, the tiff library > reads the magic number with a read syscall and erroneously gets data > 4K into the file, so it never saw the rewind(). Assuming the narkive.com discussion's quotes are accurate, unless the last stdio call on that stream was fflush (which it sounds as though it wasn't in this case), there is no requirement that the file descriptor seek pointer be synchronized with the stdio offset, and software depending on it being so is buggy, regardless of how many systems it may happen to work on. > Being a Unix greybeard, it took a couple of days staring at it to > figure out what was going on, since I had never run into a system > that behaved this way. I'd say it's about as important to know what is _promised_ as it is to know what _actually happens_. This sort of thing is why. (I went through my larval phase in the '80s under VMS; the VMS documentation is, or at least was then, a joy to behold, with very clear demarcation of what is promised and what isn't.) Indeed, most stdios do not keep the file descriptor offset and the stdio stream offset synchronized in general; for example, after fopen()ing a file for read and getc()ing one byte, the OS file pointer will usually be 4K or 8K or some such into the file (one stdio bufferful), not the one byte into the file the stdio offset is. Hence the requirement for fflush. (I'd've preferred a separate call, but they didn't ask me.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
