Re: broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ? - Mailing list pgsql-hackers

From Oleg Bartunov
Subject Re: broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ?
Date
Msg-id Pine.GSO.3.96.SK.1000916203525.26064c-100000@ra
Whole thread Raw
In response to Re: broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ?
List pgsql-hackers
INteresting, 
that I tried to find out what cause the problem just compiling
backend/utils/adt/ with -funsigned-char option but this won't help.
I thought (as in earlier time)  locale-aware code are in this 
directory. The problem already exists in 6.5 release,
so I'm not sure  recent Peter's changes could cause the problem 
Regards,    Oleg

On Sat, 16 Sep 2000, Tom Lane wrote:

> Date: Sat, 16 Sep 2000 13:21:20 -0400
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: Oleg Bartunov <oleg@sai.msu.su>, Peter Eisentraut <peter_e@gmx.net>
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ? 
> 
> Oleg Bartunov <oleg@sai.msu.su> 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
> 

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: src/test/suite dead?
Next
From: Peter Eisentraut
Date:
Subject: Re: ALTER TABLE OWNER patch