Re: [PATCH] inttostr-tests: depend on snprintf, not snprintf-posix

[Bruno Haible]

Hi Jim,

> coreutils bootstrap would fail like this: 
> 
>     ./bootstrap: m4/xsize.m4 overrides ._bootmp2/m4/xsize.m4
>     ./bootstrap: aclocal --force -I m4 ...
>     missing file gnulib-tests/vasnprintf.c
>     configure.ac:45: error: expected source file, required through 
> AC_LIBSOURCES, not found
>     m4/gnulib-comp.m4:1729: gl_INIT is expanded from...
>     configure.ac:45: the top level
>     autom4te: /usr/bin/m4 failed with exit status: 1
>     aclocal: error: autom4te failed with exit status: 1
> ...
> I've just noticed that snprintf-posix includes this notice:
> 
>     Comment:
>     This module should not be used as a dependency from a test module,
>     otherwise when this module occurs as a tests-related module, it will
>     have side effects on the compilation of the 'vasnprintf' module, if
>     that module occurs among the main modules in lib/.

Yes, this comment exactly describes the situation. The fact that the
'vasnprintf' and 'vasnprintf-posix' modules use the same source file with
different config.h parametrizations is what triggers the error message and
is also the reason for the comment.

> Yet, the inttostr tests require the ability to use %jd and %ju formats,
> so I've changed that module to depend on the snprintf module instead.

But the 'snprintf' module does not guarantee that the %jd and %ju formats
can be used. (See doc/posix-functions/snprintf.texi.) On Solaris 9 SPARC,
both in 32-bit mode and in 64-bit mode, as well as on Solaris 9 x86 (32-bit
mode), I get this test failure:

  test-inttostr.c:68: assertion failed
  FAIL: test-inttostr

IMO imaxtostr etc. is a function that is meant to do something that the system
functions cannot do. Therefore its unit test must necessarily do something
different than comparing its result to the one that the system functions
produce.

While the CK macro can be used for the types 'int' and 'unsigned int',
(because snprintf is portably usable with %d and %u), I think a test for
the larger types (off_t, intmax_t, uintmax_t) requires either
  - hardcoding the expected values (one for 32-bit, one for 64-bit, maybe
    one for 128-bit integers), or
  - computing the expected value by calling sprintf on
    x/10^18, (x/10^9) mod 10^9, x mod 10^9 and combining the results.

Bruno