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?
--- a/libstdc++-v3/src/c++11/system_error.cc
+++ b/libstdc++-v3/src/c++11/system_error.cc
@@ -110,7 +110,11 @@ namespace
#else
string strerror_string(int err)
{
- return strerror(err); // XXX Not thread-safe.
+ auto str = strerror(err); // XXX Not thread-safe.
+ if (str) [[__likely__]]
+ return str;
+ // strerror should not return NULL, but some implementations do.
+ return "Unknown error";
}
#endif
