Re: Some more <config.h> reminders

[Bruno Haible]

Paul Eggert wrote:
> This patch doesn't look right, since it causes year2038 to depend on a 
> bunch of modules like sys_shm that most programs don't need.
> 
> I don't know why year2038 should depend on sys_shm etc.

year2038 makes arrangements to turn 'time_t' into a 64-bit type. There can
be conflicts at two levels:

  * Conflicts between two packages, where one uses a 32-bit time_t and the
    other one a 64-bit time_t. Such a conflict can only be resolved at
    the distro / user level. There's nothing Gnulib can do about it.
    (Except that it could help the distro guys / users by printing the
    time_t width in the summary section that 'configure' prints at the
    end [in packages which do print such a summary]).

  * Conflicts between two compilation units of the same package.
    A compilation unit that includes <config.h> first will get the
    64-bit time_t; a compilation unit that does not include <config.h>
    will get the 32-bit time_t. So, it is the 'year2038' module which,
    in packages that don't follow the "include <config.h> first" rule,
    will cause trouble.

    What kind of mitigation against this trouble do you imagine?
    - A static analysis tool that searches through all .c and .cc files
      whether <config.h> is included? This won't work everywhere,
      since there is considerable variation in the way projects organize
      their include files.
    - The compile-time guard is cheap, since the time_t type can only be
      defined by one of the 10 listed .h files (from <sys/types.h> to
      <sys/shm.h>).

> But whatever the 
> reason, let's remove those dependencies as they're more likely to cause 
> problems than cure them.

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.

Maybe we should have a module 'year2038-safer', that depends on 'year2038'
and that has the 10 dependencies? So, 'year2038' would be without surprises.

> 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.

Bruno