tumble under BSD

[Mouse]

> 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