[PATCH] [libstdc++] [testsuite] avoid arbitrary errno codes

[Alexandre Oliva]

On Jul 12, 2024, Jonathan Wakely <jwakely@redhat.com> wrote:

> On Fri, 12 Jul 2024 at 10:27, Jonathan Wakely <jwakely@redhat.com> wrote:
>> 
>> On Fri, 12 Jul 2024 at 09:27, Alexandre Oliva <oliva@adacore.com> wrote:
>> >
>> > On Jul 11, 2024, Jonathan Wakely <jwakely@redhat.com> wrote:
>> >
>> > > There's no requirement that system_error uses strerror, that's just an
>> > > implementation detail.
>> >
>> > *nod*.  I meant it was more of a libc test in the case that relied on
>> > strerror.  But I fully agree that testing the C++ standard API makes
>> > perfect sense.  It's just that maybe we want workarounds for cases in
>> > which we implement in terms of libc, but libc doesn't live up to the
>> > standard.  Tolerating NULL returns from strerror would be an easy one;
>> > do we want that?  Checking strerror acceptable ranges (that don't
>> > trigger runtime errors) before calling it, and taking an alternate path
>> > when needed, that would be harder to do, and IMHO of dubious value.
>> 
>> Yes, handling a null result from strerror seems sensible if that's the reality.

> Does this fix it for your target?

IIRC calling strerror(95) was enough to trigger a runtime failure,
regardless of system_error, so the problem on this specific target was
not that strerror returned NULL.  But the change you proposed will help
other implementations that do, according to the [GNU/]Linux man-pages.
Thanks!

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive