Re: timespec_get: port to Ubuntu 23.04

[Bruno Haible]

Hi Paul,

> > Do you remember how the user was supposed to determine
> > which modules from time.in.h he needs to import?
> > How did the GNULIB_PORTCHECK
> > macro help doing that (or was supposed to help doing that)?
> 
> This is all old history and I had to look into the archives to refresh 
> my memory. It dates back to around when mbscasecmp (of all things...) 
> was introduced in 2007. In February 2007 I reported an issue with an 
> older way of doing these checks:
> 
> https://lists.gnu.org/r/bug-gnulib/2007-02/msg00004.html
> 
> and in commit 9f62a12a18eacd2e289aa1acbc5d7280f332f5a8 you installed 
> some "#ifdef GNULIB_POSIXCHECK" code for the first time:
> 
> https://lists.gnu.org/r/bug-gnulib/2007-02/msg00039.html
> 
> We had some back-and-forth about it. A few days later, when I responded 
> to Simon's suggestion to dump time_r.h and just have code include 
> time.h, I implemented something along those lines in commit 
> 3ac9552429c5a500717e1d3d129c32f7d0ea37a3, using GNULIB_PORTCHECK instead 
> of GNULIB_POSIXCHECK:
> 
> https://lists.gnu.org/r/bug-gnulib/2007-02/msg00132.html

Thanks for digging out this history. Yes, at that time, we did not have
the GL_LINK_WARNING macro (later called _GL_WARN_ON_USE) and therefore
had only a vague imagination of how the portability-checking feature would
work. And we just came from a world where we used symbol renaming to
provoke linker errors, e.g.
  # define memmem memmem_is_unportable__use_gnulib_module_memmem_for_portability

Then the idioms in the other .h files got improved, but the one in time.in.h
didn't.

Can we get some positive idea from the time_h.m4 idiom now? I don't see any:
  * It puts different information into the REPLACE_FUNC variable depending
    on whether module 'func' is in use or not. When it is in use, it's 0 or 1,
    telling the .h file whether to "#define func rpl_func"; when it is not
    in use, it tells the .h file whether to provoke a linker warning or error.
  * So, there's no way around testing @GNULIB_FUNC@.
  * This kind of information multiplexer can make code smaller, but usually
    less adaptable. It's not dramatic that the per-function template in a .in.h
    file is now ca. 30 lines long. OTOH, there are modules whose overrides
    we activate always (in stdio.h: fileno, fseek, etc.).
  * Is there a need to put this GNULIB_PORTCHECK or GNULIB_POSIXCHECK
    variable's value into module-dependent variables? Do the users need a
    toggle for "show me the portability problems of strncpy but not the rest?"
    or "show me the portability problems of <string.h> functions but not of
    <time.h> functions?" — I don't see the need. Testing GNULIB_POSIXCHECK
    directly is good enough.
  * Doing a portability check requires modifying the set of gnulib modules,
    because when a .h file is not autogenerated no _GL_WARN_ON_USE invocations
    in it are effective.

> As I vaguely recall, I used the name GNULIB_PORTCHECK not 
> GNULIB_POSIXCHECK because I thought some of the time.h portability 
> issues were related to the GNU API rather than merely to the POSIX API.

Yes, GNULIB_PORTABILITY_CHECK would have been a slightly better name than
GNULIB_POSIXCHECK. Should we make the change now, and rename also the
doc section title "Finding recommended ISO C and POSIX function substitutes"?
Possible. But not urgent, I would say.

> > If the procedure turns out to be simpler than what we have documented at
> > https://www.gnu.org/software/gnulib/manual/html_node/Finding-POSIX-substitutes.html
> > then we have room for improvement on these 44 *.in.h file.
> > 
> > If not, then I would suggest to align time.in.h with the other 44 *.in.h 
> > files.
> 
> If adopting GNULIB_POSIXCHECK for time-h would regularize 
> things please feel free to do that.

Indeed, regularizing things would be useful:
  - The time_h.m4 convention is that the REPLACE_* variables have to be re-
    initialized in the corresponding func.m4 file, whereas for the other
    header files this is not the case.
  - I forgot about this and on 2010-04-04 I introduced a code branch in
    nanosleep.m4 that does not set REPLACE_NANOSLEEP.
  - I forgot about this again and on 2023-01-22 I introduced a code branch
    in timespec_get.m4 that does not set REPLACE_TIMESPEC_GET, leading to
    the problem that you observed.

I'll do that in the next days.

Bruno