Re: portability checks, errors and warnings

[Bruno Haible]

Hi Paul, all,

> I want 'make' to fail if any module
> uses ctime, since it's asking for trouble in portable code (it has
> undefined behavior with out-of-range time stamps).  I suppose someone
> could write code that carefully bounds the time stamps and then uses
> ctime; such code can "#undef ctime" if it really wants to.

This was the initial approach we took three weeks ago. But it didn't
work out because people do things like

    #ifdef __linux__
      s = ctime (tp);
    #else
      ...
    #endif

and it's not a bug for them to do so. See the thread at
  http://lists.gnu.org/archive/html/bug-gnulib/2007-02/msg00000.html
or your example from coreutils
  http://lists.gnu.org/archive/html/bug-gnulib/2007-02/msg00037.html

So, we need to foresee some tolerance against purposeful uses of unportable
functions. Either warnings, or - if using errors - a way to disable the
errors in a way that is less intrusive than "#undef ctime".

Paul Eggert wrote:
> I'd rather not have a warning, as there are too many false alarms.
> ...
> I want the 'make'
> to fail if someone is using a function that should not be used.

Ok, probably we need to discuss the use cases from scratch.

The use case I have in mind is someone who has written a program that
compiles fine with "gcc -Wall", and he wants to make it portable, but
he does not have time or the means to test it on all system from AIX to
z/OS. I want to tell him the following in the gnulib manual:

  "For testing portability, invoke 'gnulib-tool --import check-portability'
   (or check-portability-unix if mingw is not among your portability targets),
   then compile the program and look at the link time warnings. Use
   gnulib-tool --import with all the mentioned modules; all portability
   warnings will then disappear, and your program will be portable."

The 'check-portability' module would be implemented as a module that defines
GNULIB_POSIXCHECK and has dependencies on 'string', 'stdio', 'time' etc.

What precisely is the use case that you imagine? You want errors for the
same purpose as the one people use "-Werror" for, namely to check that no
new dependencies are introduced in an existing program?

Bruno