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 _______________________________________________ Bug-m4 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-m4
