bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test-sprintf-posix and test-snprintf-posix test failures


From: Bruno Haible
Subject: Re: test-sprintf-posix and test-snprintf-posix test failures
Date: Sat, 27 Apr 2024 11:02:08 +0200

Hi Collin,

> I would have worked a bit harder and tried to come up with a patch,

At this point of the investigations, it's too early for a patch.
First, one needs to determine whether it's a bug in Gnulib or a
bug in some package we rely on (typically gcc or glibc). In the
latter case, we report the bug and wait for the answer. Depending
on the answer, we may fix the test (if they say that our test is
wrong), or we may put in an officially recommended workaround,
or a workaround of our liking, or disable that part of the unit test.

> but I am not very familiar with the wide character and multibyte
> string functions (wcrtomb is mentioned in the comment).

In order to determine how these functions are supposed to behave,
we often reference
  - ISO C 23 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf>
  - POSIX:2018 <https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/>

The Linux manpages project and the glibc documentation
<https://www.gnu.org/software/libc/manual/html_node/>
are also valuable in this context.

In this case, what matters for

    int retval =
      my_sprintf (result, "a%lcz %d", (wint_t) L'\0', 33, 44, 55);

is the specification of sprintf, that is found in ISO C 23. (POSIX:2018
does not yet have the correction mentioned in the comment.)

> > Does the test failure persist when the tests are compiled with "-ggdb"
> > instead of "-g -O2"? (Change CFLAGS in gltests/Makefile.)
> 
> Interesting. Using "-ggdb" in gltests/Makefile fixes both failures.
> I'm assuming that -O2 is the important change here? I know very little
> about GCC's optimizations so feel free to educate me.

Probably -O2 makes the difference, yes (to be tested, though: try "-g O2"
vs "-g", or "-O2" vs "").

Since glibc also has optimizations of string functions, conditionalized by
__OPTIMIZE__, at this point it could be a bug in gcc or in glibc.

> > Does the test program use rpl_sprintf defined by Gnulib, or does it use
> > sprintf from glibc directly? (Use 'nm test-sprintf | grep printf'.) In
> > the first case, does the test failure persist when the Gnulib replacement
> > code is compiled with "-ggdb" instead of "-g -O2"? (Change CFLAGS in
> > gllib/Makefile.)
> 
> Both use them from glibc directly. I feel a bit silly for not checking
> that before...
> 
> $ nm gltests/test-sprintf-posix | grep 'printf'
>                  U fprintf@GLIBC_2.2.5
>                  U sprintf@GLIBC_2.2.5
> 
> $ nm gltests/test-snprintf-posix | grep 'printf'
>                  U fprintf@GLIBC_2.2.5
>                  U snprintf@GLIBC_2.2.5

If some glibc-optimized expansions are active, you would also see some
*_chk symbols in the 'nm' output.

So, at this point it looks like a gcc problem. The next step is to prepare
a trimmed-down test case <https://gcc.gnu.org/bugs/#need>:
  1. Concentrate on the simpler test case. In this case, I would say, it's
     sprintf, since it takes one argument less than snprintf.
  2. Eliminate the -I, -L, -l options specific to gnulib. So that you have
     a program that succeeds without -O2 and fails with -O2. This implies
     inlining include files from gnulib (test-sprintf-posix.h, macros.h, etc.).
  3. Work on minimizing the compilation unit that succeeds without -O2 and
     fails with -O2. Always keep -Wall enabled, to guard against mistakes.
     Remove the test cases that pass, remove unnecessary includes, and so on.
  4. When you can't minimize that further, preprocess it:
     $ gcc OPTIONS -E foo.c > foo-pre.c
     Verify that it still succeeds without -O2 and fails with -O2.
  5. Continue minimizing, with -Wall enabled. Typically the end result will
     be a small file, 10-20 lines of code.

If you got that far and can argue (by the standards) that it is a GCC bug,
open a bug report. The GCC shipped by Fedora is not an upstream release;
nevertheless Paul opens his bug reports about Fedora's gcc directly in the
upstream bug tracker, e.g.
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870?>. You can do the same.

Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]