On 4/15/23 05:22, Bruno Haible wrote:
it is the 'year2038' module which,
in packages that don't follow the "include <config.h> first" rule,
will cause trouble.
The year2038 module by itself does not cause the trouble: the trouble is
caused by a combination of things. One could just as easily say that
including <sys/shm.h> causes the problem, and the proper fix is to use
the sys_shm module if one wants to include <sys/shm.h> (and similarly
for the other headers).
I concede that having a generated sys/msg.h just because of the year2038
module is surprise. But I don't see the potential for problems: we are
used to override <sys/types.h>, <sys/file.h>, etc.
The problem I ran into first was surprise on the developer's part: why
is Gnulib pulling in all this stuff I'm not using? Granted, if
everything works according to plan I'll be OK, but I'll have to think
about it and maybe something will go wrong. I'd rather not have to worry
about it.
Maybe we should have a module 'year2038-safer', that depends on 'year2038'
and that has the 10 dependencies? So, 'year2038' would be without surprises.
That would be an option - though now we're complicating the year20388
business even further. I doubt whether I'd want to use the
year2038-safer module, as the hassle (a bunch of source files I don't
need and that worries people) would be greater than the benefit
(catching typos that my source code doesn't have since I don't include
<sys/shm.h> etc.). But perhaps other package maintainers would want the
hassle, so year2038-safer would be useful for them.
I suppose it would be OK for sys_shm etc. to depend on year2038
No, that's the wrong dependency direction. A package that wants to use
shared memory does not need 'year2038'. Only the users of the 'shmctl'
function need year-2038 safety.
This cuts both ways, as a package that merely wants to use year2038 does
not need sys_shm. Perhaps we should have the shmctl module depend on
year2038 instead?
Part of this issue here is, how much do we want to cover all
theoretically-possible issues, versus how much do we want to support the
likely practical uses? For example, although POSIX *allows* an app to
include <sys/shm.h> merely to define time_t, this is pretty unlikely and
I think we needn't worry about that.
Conversely, POSIX *allows* any .h file to define time_t, which means
that strictly speaking year2038-safer should depend on every module that
builds a .h file (at least all .h files specified by POSIX and by the C
standard, and likely lots of other .h files too). That would be kinda
ridiculous, though; I don't advocate that. Though it is true that the
current approach is buggy since, e.g., <sys/resource.h>'s ABI depends on
time_t on some platforms even though year2038 does not depend on
sys_resource, and there are other issues like this with other header
files - what a mess, eh?
My suggestion is that we give up on having dependencies address this
particular issue, since they cause more trouble than they cure. Let's
just go back to year2038 not depending on anything other than largefile,
and tell people to include config.h first without trying to enforce it
for time_t-related types and functions.
