Re: address@hidden: Re: CVS commit: pkgsrc/devel/m4]

[Bruno Haible]

Joerg Sonnenberger wrote:
> Be careful, this breaks the intention. If you reset the flag, you
> also have to keep overriding fseek/fseeko, because it will set use the
> optimisation again.

Indeed, with the proposed patch and the system's fseek/fseeko, I get a
test failure on MacOS X:
  File offset is wrong after fseek: 17.
  FAIL: test-fflush

> I don't think it is critical in any way to disable the optimisation, as
> fflush is supposedly a very rare operation on stdin and fseeko as well.

Yes, fseeko is normally not a frequent operation. But if a program uses it
heavily (like, read 10 bytes, fseek back by 10 bytes, read the 10 bytes
again, or the way "od" does it), then it's preferrable to have the optimized
fseek that only updates fields in the FILE struct, rather than the unoptimized
one which discards the read buffer and performs lseek() and read() system
calls. This is achieved by resetting the __SNPT flag and performing some
in-memory tests in fseeko.c, which are both fast operations.

Bruno