Re: [HACKERS] broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ?
On Sun, 3 Dec 2000, Tom Lane wrote: Date: Sun, 03 Dec 2000 18:13:47 -0500 From: Tom Lane [EMAIL PROTECTED] To: Oleg Bartunov [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ? Oleg Bartunov [EMAIL PROTECTED] wrote a couple months ago: It's clear that we must use 'unsigned char' instead of 'char' and corrected version runs ok on both systems. That's why I suspect that gcc 2.95.2 has different default under FreeBSD which could cause problem with LC_CTYPE in 7.0.2 ok. will check this. I've recompile 7.0.2 on freebsd with -funsigned-char and the problem has gone away. This prove my suggestion. I also checked 6.5 and it has the same probelm on FreeBSD. Also, this makes clear many complains about broken locale under FreeBSD I got from people. Hmm, current cvs has the same problem :-( Today I inserted (unsigned char) casts into all the ctype.h function calls I could find. This issue should be fixed as of current cvs. Please try it again when you have time. Just tried on FreeBSD 3.4-STABLE, current cvs, gcc version 2.95.2 19991024 (release), ru-RU.KOI8-R locale, postgresql configured with --enable-locale, no gcc option like --unisgned-chars Looks like your changes did right job ! regards, Oleg regards, tom lane _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: [HACKERS] broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ?
Oleg Bartunov [EMAIL PROTECTED] wrote a couple months ago: It's clear that we must use 'unsigned char' instead of 'char' and corrected version runs ok on both systems. That's why I suspect that gcc 2.95.2 has different default under FreeBSD which could cause problem with LC_CTYPE in 7.0.2 ok. will check this. I've recompile 7.0.2 on freebsd with -funsigned-char and the problem has gone away. This prove my suggestion. I also checked 6.5 and it has the same probelm on FreeBSD. Also, this makes clear many complains about broken locale under FreeBSD I got from people. Hmm, current cvs has the same problem :-( Today I inserted (unsigned char) casts into all the ctype.h function calls I could find. This issue should be fixed as of current cvs. Please try it again when you have time. regards, tom lane
Re: [HACKERS] broken locale in 7.0.2 without multibyte support(FreeBSD 4.1-RELEASE) ?
Tom Lane writes: Well, we could fix it either by propagating use of "unsigned char" all over the place, or by casting the arguments given to ctype macros. The former would be a lot more invasive because it would propagate to routines that don't actually call any ctype macros (since they'd have to conform to prototypes, struct definitions, etc). I'm not married to either solution, I just opine that it is cleaner to use "signed char" and "unsigned char" explicitly when you depend on the signed-ness. Otherwise you might just end up moving the problem elsewhere, namely those structs and prototypes, etc. (Hmm, template/aix contains this: CFLAGS='-qchars=signed ...'. That can't be good.) Probably Andreas put that in --- maybe he still remembers why. But it shouldn't matter. We need to be able to run on platforms where char is signed and there's no handy "-funsigned-chars" compiler option. What I meant was that (a) according to Oleg's report, the source depends on char being unsigned in some places, so those places break on AIX, and (b) according to the above, the source apparently requires char to be signed in some places, so it breaks when char is made unsigned. *That* can't be good. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ?
On Sat, 16 Sep 2000, Tom Lane wrote: Date: Sat, 16 Sep 2000 11:23:33 -0400 From: Tom Lane [EMAIL PROTECTED] To: Oleg Bartunov [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [HACKERS] broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ? Oleg Bartunov [EMAIL PROTECTED] writes: It's clear that we must use 'unsigned char' instead of 'char' and corrected version runs ok on both systems. That's why I suspect that gcc 2.95.2 has different default under FreeBSD which could cause problem with LC_CTYPE in 7.0.2 I didn't test current CVS under FreeBSD but probably will check it. I think Peter recently went around and inserted explicit casts to fix this problem. Please do see if it's fixed in CVS. ok. will check this. I've recompile 7.0.2 on freebsd with -funsigned-char and the problem has gone away. This prove my suggestion. I also checked 6.5 and it has the same probelm on FreeBSD. Also, this makes clear many complains about broken locale under FreeBSD I got from people. Hmm, current cvs has the same problem :-( Regards, Oleg regards, tom lane _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: [HACKERS] broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ?
Oleg Bartunov [EMAIL PROTECTED] writes:
It's clear that we must use 'unsigned char' instead of 'char'
and corrected version runs ok on both systems. That's why I suspect
that gcc 2.95.2 has different default under FreeBSD which could
cause problem with LC_CTYPE in 7.0.2
I think Peter recently went around and inserted explicit casts to
fix this problem. Please do see if it's fixed in CVS.
Hmm, current cvs has the same problem :-(
Now that I look at it, what Peter was doing was just trying to eliminate
compiler warnings on some platform or other, and he made changes like
these (this example is interfaces/ecpg/preproc/pgc.l):
@@ -491,7 +491,7 @@
/* this should leave the last byte set to '\0' */
strncpy(lower_text, yytext, NAMEDATALEN-1);
for(i = 0; lower_text[i]; i++)
- if (isascii((unsigned char)lower_text[i]) isupper(lower_text[i]))
+ if (isascii((int)lower_text[i]) isupper((int) lower_text[i]))
lower_text[i] = tolower(lower_text[i]);
if (i = NAMEDATALEN)
@@ -682,7 +682,7 @@
/* skip the ";" and trailing whitespace. Note that yytext contains
at least one non-space character plus the ";" */
- for ( i = strlen(yytext)-2; i 0 isspace(yytext[i]); i-- ) {}
+ for ( i = strlen(yytext)-2; i 0 isspace((int) yytext[i]); i-- ) {}
yytext[i+1] = '\0';
for ( defptr = defines; defptr != NULL
@@ -754,7 +754,7 @@
/* skip the ";" and trailing whitespace. Note that yytext contains
at least one non-space character plus the ";" */
- for ( i = strlen(yytext)-2; i 0 isspace(yytext[i]); i-- ) {}
+ for ( i = strlen(yytext)-2; i 0 isspace((int) yytext[i]); i-- ) {}
yytext[i+1] = '\0';
yyin = NULL;
Peter, I suppose what you were trying to clean up is a "char used as
array subscript" kind of warning? These changes wouldn't help Oleg's
problem, in fact the first change in this file would have broken code
that was previously not broken for him.
I think that the correct coding convention is to be careful to call the
ctype.h macros only with values that are either declared as or casted
to "unsigned char". I would like to think that your compiler will not
complain about
if (isascii((unsigned char)lower_text[i]) ...
If it does we'd have to write something as ugly as
if (isascii((int)(unsigned char)lower_text[i]) ...
which I can see no value in from a portability standpoint.
regards, tom lane
