2 Apr
2016
2 Apr
'16
2:09 p.m.
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 mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B