Stephan Szabo <sszabo@megazone.bigpanda.com> 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
