On Jul 12, 2024, Jonathan Wakely <jwak...@redhat.com> wrote: > On Fri, 12 Jul 2024 at 10:27, Jonathan Wakely <jwak...@redhat.com> wrote: >> >> On Fri, 12 Jul 2024 at 09:27, Alexandre Oliva <ol...@adacore.com> wrote: >> > >> > On Jul 11, 2024, Jonathan Wakely <jwak...@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
