On Thu, 11 Jul 2024 at 17:23, Alexandre Oliva <ol...@adacore.com> wrote: > > On Jul 11, 2024, Jonathan Wakely <jwak...@redhat.com> wrote: > > > And std::system_error doesn't limit the values that can be passed to > > it either. So I'd prefer to keep testing with arbitrary int values, > > because that *should* work. > > Fair enough, thanks. I've seen portability documentation suggesting > that strerror returns NULL on some systems, if the error code is > unknown, and it didn't seem to me that libstdc++ was prepared to deal > with that. I'm not sure this system, on which I saw the failure, > returns NULL or fails in some other way, but it's clear its behavior is > not compliant with the relevant standards. It makes sense to test for > this condition, though IMHO that makes it more of a libc test than a > libstdc++ test,
There's no requirement that system_error uses strerror, that's just an implementation detail. So I think it makes sense to test at the user visible API level that system_error works with arbitrary values, even though that ends up depending on whether libc strerror also supports them. > compared with the patched version I proposed. Not that > I object to that :-) I just hadn't understood the goal. > > Patch withdrawn. > > -- > 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 >
