Joerg Sonnenberger wrote: > > 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?
Yes, with the proposed patch and the overridden fseek/fseeko, it works. > I would strongly suggest to actually > encapsulate fflush(fp) + fseeko(fp, 0, SEEK_CUR) in a new function and > use that. Indeed, in gnulib, when simply overriding the POSIX functions doesn't help, we create our own special-purpose functions or macros. But we try hard to let the programmers write programs according to POSIX. In this case, we succeeded in overriding fflush and fseek/fseeko - albeit with major hacks. If the number of hacks in this area keeps growing, we may want to follow your suggestion. > 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. Yes, it is weird code. > 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. Eric's example is not a frequent use case, admitted. But fseek is frequent, and users of gnulib should be able to take both the fflush and the fseeko replacements without much thinking and without getting a performance degradation. Bruno _______________________________________________ Bug-m4 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-m4
