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

[Joerg Sonnenberger]

On Sat, Jul 28, 2007 at 09:53:42AM +0200, Bruno Haible wrote:
> 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

But it works with the more agressive approach?

> > 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.

If this is really a concern, I would strongly suggest to actually
encapsulate fflush(fp) + fseeko(fp, 0, SEEK_CUR) in a new function and
use that. Keep in mind where this started -- fflush on an input
descriptor is implementation defined by the relevant current standards.
Eric brought up a case that can't be implemented with that behaviour.
The current gnulib implementation provides that with a lot of messing in
the internals of stdio and by overridding two entry points (fflush and
fseeko). It works by forcing a non-trivial number of invariants between
the two replacement functions and the behaviour of stdio in general.

I hope we agree that this is not a good idea. The alternative fflush
function above is far less intrusive, but degrades the performance of
fseek/fseeko. I don't think there is any application that really hits
this case as the example of Eric seems to be the first good example why
it is needed, otherwise it wouldn't have been in the standards for 15
years.

It can be implemented without the performance issues when encapsulating
both operations and merging them. This might actually be a good idea for
the standard track as well, as it makes the implementation much easier
and is also easier to provide fallback support for. Going that route
makes the configure check more interesting, but I think it is somewhat
broken right now anyway.

Joerg