Re: [PATCH] largefile: add dependencies to this module

[Paul Eggert]

On 07/25/11 17:51, Bruno Haible wrote:

> For me, that sounds perfectly in line with the gnulib approach: We create
> a new module when we notice and fix the first portability problem with
> the particular function.

It's not always that simple, unfortunately.  Sometimes it's better to
think of a module as being for a broader portability issue, not as
being for a particular function.  The 'largefile' module is more of an
issue-oriented module, whereas the (say) 'alphasort' module is more of
a function-oriented module.

In a trivial sense every function-oriented module is an issue-oriented
module (e.g., 'alphasort's issue is "I need the alphasort function!"),
but not every issue can be boiled down to a single function, and
conversely a program that invokes a function sometimes needs to
address just some that function's portability issues, not all of them.

> Actually, for 'fseek' and 'ftell' adding a dependency to 'largefile' buys
> nothing, because it does not change the width of the type 'long'.

Good point.

> I would better leave 'relocatable-prog' and 'relocatable-prog-wrapper'
> alone, because these are built in a very special way and rarely tested
> on all platforms, and because executables larger than 2 GB have yet to
> be seen in the wild.

Yes, that makes sense.

> So we will have some uses of the stat() function which give rise to a
> module dependency towards 'stat', and others which trigger a module
> dependency towards 'largefile'? Sounds hard to remember. In comparable
> ...
> So, I would propose to rename 'stat' to 'stat-posix', and add a new module
> 'stat' that only fixes the 2 GiB st_size / 4 TiB st_ino problem. Then,
> when other modules depend on it, it's very clear why they do, and during
> future maintenance it will be clear whether to keep the dependency or not.

Won't that be just as hard to remember -- maybe even harder?  We can't
reasonably expect people to remember that 'stat-posix' means "deals
correctly with trailing slashes", and that 'stat' means "deals
correctly with large files".  An explicit dependency on 'largefile'
makes the latter point clearer.  And it makes for fewer modules, which
is also a good thing.

Another advantage of depending on 'largefile' is that it simplifies
maintenance later on.  If a function currently uses 'stat', for
example, and we switch it to use 'fstat', we won't have to change its
module dependencies, because it will continue to depend on
'largefile'.  (I am assuming the module doesn't care about trailing
slashes, which is the case for several modules now.)

(Come to think of it, it might be nicer if we had a 'trailing-slashes'
module, or small family of modules, rather than the current approach
of testing each function separately.  But this is diverging into a
different topic....)

> Users who use --avoid are on their own in general.

Yes, good point.  So perhaps I should stop worrying about that.

>>    . fileblocks has lib/fileblocks.c, which uses low-level system
>>      macros and types such as daddr_t that probably depend on largefile.
> 
> More importantly, it uses off_t, therefore it indeed profits from 'largefile'.

I'm not sure about that.  Merely using off_t doesn't mean fileblocks
needs 'largefile', any more than merely using struct dirent means that
alphasort needs 'largefile'.  The key notion is whether the module's
code talks to the outside world.  In looking at fileblocks.c again,
maybe it's OK for it to not depend on largefile.

I'll take a look at the new modules in a separate email.