Re: fseek, ftell warnings

[Bruno Haible]

Hi Eric,

> Actually, I'm wondering if we need modules/fseeko to depend on
> modules/fseek, or if we can come up with some other approach.  After
> all, the whole idea is that portable programs should only be using
> fseeko, not fseek.  But by making fseeko depend on fseek, then
> stdio.in.h will always end up replacing fseek even if it is not going to
> be used, and we lose the ability to issue gcc warnings about unintended
> use of fseek when fseeko should have been used.

IMO the dependencies between modules should be determined by the need to
get functions work correctly according to POSIX. If we want warnings, we
can attach warnings regardless whether a function is overridden or not.

When you say "portable programs should only be using fseeko, not fseek",
the warning text should probably be "fseek cannot handle files larger
than 2 GB", rather than "fseek has portability bugs", right? This warning
is valid regardless whether the module 'fseek' is requested, regardless
whether the module 'fseeko' depends on the module 'fseek', regardless
whether REPLACE_FSEEK gets set to 1.

> Of course, the fseeko replacement needs to fix flaws in the native fseek
> if there is no native fseeko, but if we can make it do that without also
> dragging in the fseek module, that would be better.

Why would that be better? If we replace 'fseek', it ought to be through a
file lib/fseek.o and through a module 'fseek'. This has proven to be the
code structure that is most easy to understand and most easy to work with.

IIRC, you added the inline function for fseek() when the user has asked for
'fseeko' just to guarantee that fseek() and fseeko() are consistent, because
everything else leads to madness.

Bruno
-- 
In memoriam Anna Göldi <http://en.wikipedia.org/wiki/Anna_Göldi>