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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: MauMau <maumau307(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Date: 2013-09-09 14:25:10
Message-ID: 18204.1378736710@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> My suggestion in this matter is to disable gettext processing when
> LC_CTYPE is set to C. We could log a warning when LC_MESSAGES is set to
> something and LC_CTYPE is set to C. Or just do the warning and keep
> logging. Something like that.

Meh. Seems that would only prevent one specific instance of the general
problem that strerror can fail to translate its result. Other locale
combinations might create the same kind of failure.

More generally, though, is strerror actually using gettext at all, or
some homegrown implementation? As I said upthread, I would expect that
gettext("foo") returns the given ASCII string "foo" if it fails to create
a translated version. This is evidently not what's happening in strerror.

It's way past time to look into the glibc sources and see what it's
actually doing...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-09-09 14:33:57 Re: [bug fix] strerror() returns ??? in a UTF-8/C database with LC_MESSAGES=non-ASCII
Previous Message Peter Eisentraut 2013-09-09 12:54:32 Re: ENABLE/DISABLE CONSTRAINT NAME