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

[Bruno Haible]

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