Skip site navigation (1) Skip section navigation (2)

Re: AW: AW: broken locale in 7.0.2 without multibyte suppor t (F reeBSD 4.1-RELEASE) ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: AW: broken locale in 7.0.2 without multibyte suppor t (F reeBSD 4.1-RELEASE) ?
Date: 2000-12-04 20:24:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> But don't they in general obfuscate cases where the callee does want
> unsigned/signed chars ?

Well, it's ugly, but I don't think we have much choice.  Seems to me
that changing to "unsigned char" throughout the backend would obfuscate
things *more* than coding <ctype.h> calls as

	char	*p;
	x = tolower((unsigned char) *p);

which is what I actually did.

There are lots of places where "char" variables are used that will never
see a <ctype.h> call.  Do we institute a coding rule that plain "char"
is verboten in *all* cases, whether or not they're relevant to ctype
calls?  If not, how do we check that "char" is being used safely?
Aren't we likely to get compiler warnings from passing "unsigned char *"
to libc functions that are declared to take plain "char *"?

I don't think that path is an improvement over a coding rule that ctype
functions must be applied to unsigned chars.  IMHO the latter is less
intrusive overall, and no harder to check for violations.

> My concern stems from a very bad experience with wrong signedness of chars
> on AIX.

I agree that this is something we'll have to watch.  I don't see any
cleaner answer, though.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Bruce GuenterDate: 2000-12-04 20:28:10
Subject: Re: Using Threads?
Previous:From: Larry RosenmanDate: 2000-12-04 19:45:42
Subject: Re: [Fwd: Re: [CORE] Going Beta on Monday ...]

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group