Thread: AW: AW: broken locale in 7.0.2 without multibyte suppor t (F reeBSD 4.1-RELEASE) ?
AW: AW: broken locale in 7.0.2 without multibyte suppor t (F reeBSD 4.1-RELEASE) ?
From
Zeugswetter Andreas SB
Date:
> > I am a sceptic to the many casts. Would'nt the clean > solution be, to use > > unsigned char througout the code ? > > No; see the prior discussion. > > > The casts only help to avoid compiler > > warnings or errors. They do not solve the underlying problem. > > You are mistaken. You are of course correct, that they might solve the particular underlying problem, sorry, I did not actually read or verify the committed code. But don't they in general obfuscate cases where the callee does want unsigned/signed chars ? My assumption would be, that we need [un]signed char casts for library functions, but we should not need them for internal code, no ? What is actually the reason to have them both in PostgreSQL code ? My concern stems from a very bad experience with wrong signedness of chars on AIX. Andreas
Re: AW: AW: broken locale in 7.0.2 without multibyte suppor t (F reeBSD 4.1-RELEASE) ?
From
Tom Lane
Date:
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.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