Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
| От | Greg Stark |
|---|---|
| Тема | Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII |
| Дата | |
| Msg-id | CAM-w4HM8SNZH1W2=z0izBorH+xGkq9QYzB+fO28L0=18F+iSbA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
|
| Список | pgsql-hackers |
On Fri, Sep 6, 2013 at 3:57 PM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2013-09-06 10:52:03 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.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
В списке pgsql-hackers по дате отправления: