On 20 February 2016 at 16:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> After further thought about the portability implications of this ---
>
> 1. We probably gave up support for long-long-less compilers when we agreed
> to start requiring a working int64 type. On a 32-bit machine that's
> highly likely to be "long long", and 64-bit machines are mostly new enough
> that they'd have C99-compliant compilers.
>
> 2. Nonetheless, LL is not the same as int64; on modern 64-bit machines it
> probably means int128. So the right thing to do when writing a constant
> you mean to be int64 is to use a cast or [U]INT64CONST(). (You need that
> macro if the constant value might be too wide for plain int, since pickier
> compilers may reject an unsuffixed constant wider than int.)
>
OK, thanks that's all good to know.
> Your updated code looks fine from here. I looked into changing that code
> in ecpg, but it would be more invasive than I thought because ecpg doesn't
> use c.h. Some rearrangement of the ecpg headers would be required, and
> in view of point #1, it's unlikely to be worth it; it might buy a bit of
> micro-efficiency but not much.
>
It looks to me as though it doesn't need long long anyway, since the
rotation it's doing can be done just as easily with ints, for example:
int hashVal = 0;
for (...)
{
hashVal = hashVal + (int) ecpgQuery[stmtIx];
hashVal = (((unsigned int) hashVal) >> 19) | (hashVal << 13);
}
but it's probably not worth changing, for risk of breaking it.
Regards,
Dean
