Um, I think your patch like the overkill reaction of C-locale...
Patch makes char2wchar and wchar2char symmetric to C-locale.
However, I tried your patch.
make check MULTIBYTE=euc_jp NO_LOCALE=true
...
===
All 120 tests passed.
===
Anyway, either should
On Wed, Feb 25, 2009 at 6:44 PM, Teodor Sigaev teo...@sigaev.ru wrote:
mbstowcs/wcstombs doesn't work with C-locale in other OSes too, so that's
not needed.
Say what? What OSes is that?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Say what? What OSes is that?
See attached test program. It tries to convert multibyte russian word in
UTF8 to wide char with C, ru_RU-KOI8-R and ru_RU.UTF-8 locales. The word
contains 6 letters.
FreeBSD 7.2 (short output):
C==
mbstowcs returns 12
Hmm well the KOI8 tests unsurprisingly produce random results on non-
KOI8 input. It's pure chance you didn't get EILSEQ.
What errno did you get for the C locale test? On which input character?
Perhaps it's sihnalljng EILSEQ for every byte 0x80 ? That seems
broken to me but perhaps not to a
Hmm well the KOI8 tests unsurprisingly produce random results on
non-KOI8 input. It's pure chance you didn't get EILSEQ.
Because KOI8 is not multibyte encoding.
What errno did you get for the C locale test? On which input
character?Perhaps it's sihnalljng EILSEQ for every byte 0x80 ? That
Hi Teodor-san.
Sorry late reaction.
- Original Message -
From: Teodor Sigaev teo...@sigaev.ru
If there's an effective function like pg_wchar2mb_with_len() which
converts wchar_t strings to server encoded strings, we had better
simply call it for char2wchar().
I don't see a way to
pg_mb2wchar_with_len() converts server encoded strings to pg_wchar
strings. But pg_wchar is typedef'd as unsigned int which is not the
same as wchar_t at least on Windows (unsigned short).
Oops. The problem is here. TParserInit allocates twice less memory than needed.
And it happens if
I think that Mr. Inoue's patch is right.
why isn't it taken into consideration yet?
I can't check that patch because I don't have a Windows box.
But I did some investigations. As I understand, the patch prevents from calling
of wcstombs/mbstowcs with C locale and I checked trace for that. But
Teodor Sigaev wrote:
I think that Mr. Inoue's patch is right.
why isn't it taken into consideration yet?
I can't check that patch because I don't have a Windows box.
But I did some investigations. As I understand, the patch prevents from
calling of wcstombs/mbstowcs with C locale and I
Hi.
Sorry late reaction.
I try check of CVS-HEAD now.
$ make check NO_LOCALE=true
...
===
All 120 tests passed.
===
However, same action as Inou-sane is seen.
make check MULTIBYTE=euc_jp NO_LOCALE=true
The differences that caused some tests to fail
Hi,
I see a regression test failure in my mingw-vista port
when I invoke the command
make check MULTIBYTE=euc_jp NO_LOCALE=yes
.
It causes a crash at tsearch.
The crash seems to occur when the server encoding isn't
UTF-8 with no locale.
The attached is a patch to avoid the crash.
regards,
11 matches
Mail list logo
