Re: Test suite failure for gettext's gnulib on ARMv7HL

[Kamil Dudka]

On Monday, August 3, 2020 2:57:22 PM CEST Bastien Nocera wrote:
> On Mon, 2020-08-03 at 12:55 +0200, Kamil Dudka wrote:
> > On Friday, July 31, 2020 6:47:08 PM CEST Bastien Nocera wrote:
> > > Hey,
> > > 
> > > Gettext 0.20.2's gnulib copy has its test suite failing on Fedora
> > > rawhide on ARMv7HL. I'm afraid that it's Friday late in the day,
> > > and I
> > > don't have much more information than what's available in the build
> > > logs.
> > > 
> > > Those are the 2 failing tests:
> > > FAIL: test-strerror_r
> > > FAIL: test-perror2
> > 
> > I ended up with the following (temporary?) fix in Fedora packages:
> > 
> > https://src.fedoraproject.org/rpms/coreutils/c/27d47106
> > https://src.fedoraproject.org/rpms/findutils/c/41947242
> 
> Those are just random high numbers, which are supposed to test a few
> things in the behaviour of strerror and perror:
> https://www.mail-archive.com/bug-gnulib@gnu.org/msg22023.html
> 
> So the work-around is probably incorrect. Do you know what the actual
> failure is, eg. which one of the checks is failing?

Yes, the `ASSERT (msg3 == msg4 || STREQ (msg3, str3))` check is failing here:

    
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-strerror_r.c;h=b11d6fd9#l170

As far as I understand the documentation, the test exercises something that
the interface does not guarantee.  The strerror() man page explicitly says:

    "This string must not be modified by the application, but may be modified
    by a subsequent call to strerror() or strerror_l()."

So the fact that a string previously returned by strerror() is arbitrarily
modified by a subsequent call to strerror() is not a bug on its own.

Kamil