Re: portability checks, errors and warnings

[Paul Eggert]

Bruno Haible <address@hidden> writes:

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

A problem with this is that there will be false alarms in the link
time warnings.  The user will figure this out and ignore them.  But
the next time they redo the portability-testing step, the same false
alarms will be generated.  There should be a way to shut off the false
alarm in the source code.  That is what I was proposing "#undef ctime"
for (in system-dependent code that can assume a ctime with
well-defined behavior no matter what the argument is).

If I compile coreutils that way I get plenty of false alarms.  I don't
know whether any of them are valid (I haven't checked them recently,
there were too many and I didn't have time, but the first few were
false).

Also, I have some qualms about the whole idea of of "gnulib-tool
--import check-portability" step.  It'd be nicer if we could just ask
people to compile with -DGNULIB_POSIXCHECK or whatever.  That way they
won't have to use gnulib-tool, and the test can be done by installers
rather than just maintainers.

> What precisely is the use case that you imagine?

m4/foo.m4 has determined that foo doesn't work and ordinary code
shouldn't use it directly, but some ordinary code uses it anyway.
(Sorry, I'm not sure whether this is precise enough, but it's
late....)