Other identifiers such as the objId are also affected. Hassan is investigating whether the Gaia DR2 object identifier, the sourceId, can be stored in the positive range of a 64-bit signed int to avoid possible confusion. Yabe-san is checking the HSC ID.

I think the hexadecimal notation of the 64bit hash will be kept unsigned as it is now, e.g. 0xfedcba9876543210.
What will the signed value for x = 0xfedcba9876543210?
I think fits_cast_unsigned_to_signed(x) is currently used.
What I meant in slack was cplusplus_cast_unsigned_to_signed(x).
I don't have preference but it should be determined which to use.

def fits_cast_unsigned_to_signed(x):
    return x - 0x8000_0000_0000_0000

def cplusplus_cast_unsigned_to_signed(x):
    return x - ((x & 0x8000_0000_0000_0000) << 1)

Following subsequent discussions with cloomis and sogo.mineo: generating a hash that is truncated to from the original 160 bit SHA-1 to 64-bits, compared with one truncated to 63 bits, would cause more confusion and problems than it helps.

For example, if the resultant 64-bit hash is carried internally as a 64-bit signed integer (for example when read from the opDB, where the column type is 64-bit signed), then approx 50% of all generated hashes would result in a negative signed integer value being read. Care then needs to be taken when using these, for example when writing out such has values as hex representations in file names, as performed by the LSST Gen2 Butler (tests show in fact that the Butler would raise an error in such situations).

It appears to be much simpler and safer to truncate the SHA to 63 bits. This way, all hash values will be positive.

merged to master (d472332)