Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII

On Fri, Sep 6, 2013 at 3:57 PM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:

> On 2013-09-06 10:52:03 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > > I have no clue about the gettext stuff but I am in favor of including
> > > the raw errno in strerror() messages (no backpatching tho).
> >
> > I dislike that on grounds of readability and translatability; and
> > I'm also of the opinion that errno codes aren't really consistent
> > enough across platforms to be all that trustworthy for remote diagnostic
> > purposes.
>

Historically they weren't even the same on Linux acros architectures. This
was to support running native binaries from the incumbent platform (SunOS,
OSF, BSD) under emulation on each architecture. I don't see any evidence of
that any more but I'm not sure I'm looking in the right place.

> Well, it's easier to get access to mappings between errno and meaning of
> foreign systems than to get access to their translations in my
> experience.
>

That's definitely true. There are only a few possible platforms and it's
not hard to convert an errno to an error string on a given platform.
Converting a translated string in some language you can't read to an
untranslated string is another matter.

What would be nicer would be to display the C define, EINVAL, EPERM, etc.
Afaik there's no portable way to do that though. I suppose we could just
have a small array or hash table of all the errors we know about and look
it up.

--
greg