CellID is long long int in DD4hep, but uint64_t in EDM4hep

[wdconinc]

This issue is mainly to point out to this community a relevant issue on the EDM4hep issue tracker: key4hep/EDM4hep#202

• In DD4hep, CellID is defined as a signed long long int in DDCore/include/Parsers/Primitives.h. https://github.com/AIDASoft/DD4hep/blob/master/DDCore/include/Parsers/Primitives.h#L44
• In EDM4hep, CellID is defined as an unsigned uint64_t, e.g. in https://github.com/key4hep/EDM4hep/blob/master/edm4hep.yaml#L325

Discussion on the EDM4hep issue: key4hep/EDM4hep#202.

In particular, I'd be interested in knowing when (if ever) the signed nature of the CellID could be important.

[wdconinc]

To keep the discussion organized and in one place, please add comment to the EDM4hep issue, key4hep/EDM4hep#202.

[MarkusFrankATcernch]

The signed'ness is probably not the issue, but it may be more interesting to specify the exact bitfield width already in the type rather rely on a less strict definition of "long long".
Probably more an academic issue: x86 will be around for a long time.

[MarkusFrankATcernch]

@wdconinc During last meeting it was decided to standardize on uint64_t for the definition of VolumeID and CellID.
It was unclear however, if really the only difference was the change in Primitives.h. Due to this uncertainty the actual time when to switch was left open.

[wdconinc]

I expected that this would have some significant impacts throughout the code.

[MarkusFrankATcernch]

@wdconinc Was not entirely clear. Some voices claimed that the value was only accessed as a bit-field and there the interpretation as signed or unsigned should not matter since signed long long and uint64_t on linux x86 has the same width.
Clearly, print statements (and if used, loop variables) will need to change.

[MarkusFrankATcernch]

In case of problems, please re-open the pull request