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>
