From: | hgonzalez(at)gmail(dot)com |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, hernan gonzalez <hgonzalez(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: psql weird behaviour with charset encodings |
Date: | 2010-05-08 01:48:53 |
Message-ID: | 0016362842accfef6204860b60f4@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> However, it appears that glibc's printf
code interprets the parameter as the number of *characters* to print,
and to determine what's a character it assumes the string is in the
environment LC_CTYPE's encoding.
Well, I myself have problems to believe that :-)
This would be nasty... Are you sure?
I couldn reproduce that.
I made a quick test, passing a utf-8 encoded string
(5 bytes correspoding to 4 unicode chars: "niño")
And my glib (same Fedora 12) seems to count bytes,
as it should.
#include<stdio.h>
main () {
char s[] = "ni\xc3\xb1o";
printf("|%.*s|\n",5,s);
}
This, compiled with gcc 4.4.3, run with my root locale (utf8)
did not padded a blank. ie it worked as expected.
Hernán
From | Date | Subject | |
---|---|---|---|
Next Message | hernan gonzalez | 2010-05-08 02:30:55 | Re: psql weird behaviour with charset encodings |
Previous Message | Tom Lane | 2010-05-07 23:46:42 | Re: psql weird behaviour with charset encodings |
From | Date | Subject | |
---|---|---|---|
Next Message | hernan gonzalez | 2010-05-08 02:30:55 | Re: psql weird behaviour with charset encodings |
Previous Message | Josh Berkus | 2010-05-08 00:17:53 | Re: [HACKERS] no universally correct setting for fsync |