Stephan Szabo <[EMAIL PROTECTED]> writes: > On Thu, 6 Nov 2003, Jason Godden wrote: >> On Thu, 6 Nov 2003 06:25 am, Markus Bertheau wrote: >>> +#define HEXVALUE(c) (((c)>='a') ? ((c)-87) : (((c)>='A') ? ((c)-55) : > ((c)-'0')))
> I haven't looked at the code in question, but assuming the digits are > contiguous and in order is safe, the C spec mandates that. Assuming that > the letters are in order and contiguous is not safe. I believe that's a true statement with respect to the character sets used in the field; I dunno whether the C spec actually says that though. My original concern about this macro had several different levels: 1. I can't see any reason why the subtractions are coded as "-55" and not "-'A' + 10". The existing coding is less understandable than doing it right, and won't save anything in runtime (since the compiler will fold the constants anyway), on top of being a character set dependency. 2. I don't much care for the assumption that lower case letters are greater than upper case are greater than digits. This could be avoided at a fairly small runtime penalty by making range tests: #define HEXVALUE(c) \ (((c) >= '0' && (c) <= '9') ? ((c) - '0') : \ (((c) >= 'A' && (c) <= 'F') ? ((c) - 'A' + 10) : \ ((c) - 'a' + 10))) 3. The third level would be to get rid of the assumption that letters are contiguous, which would probably require making a lookup table to map from char code to hex value. I'm not sure level 3 is really worth doing, since AFAIK no one tries to run Postgres on any EBCDIC platform. (It's likely that there are other places that depend on the letters-are-contiguous assumption anyway.) I do think level 1 and probably level 2 are appropriate changes. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]