Jef Driesen jefdriesen@telenet.be writes:
It could be as simple as a new libdivecomputer callback ("given this serial *number*, what is the string for it?"), but it would probably be better to expand the current DC_EVENT_DEVINFO event to simply give us a string in addition to the number. Because it's not necessarily the case that all serial number strings can even be represented as a single 32-bit integer.
The primary purpose of the serial number in the DC_EVENT_DEVINFO event is to be able to uniquely identify individual devices (e.g. for use with the fingerprint feature). For this purpose, it doesn't really matter if the serial number (as returned by libdivecomputer) doesn't match the real serial number (as printed on the hardware). That's why I didn't bother to decode it properly, and just return the raw bytes wrapped in a 32bit integer. In this sense the serial number is more like an opaque device id, and it was not really intended to be shown to the end-user (e.g. for warranty purposes).
Until now, all serial numbers did nicely fit into a 32bit integer, but if there ever happens to be a device where this isn't possible, we can always calculate some hash, just like you already do in subsurface. But of course that will only work if we make no guarantees that the libdivecomputer serial number will match the real serial number.
You are solving the wrong problem. As was discussed earlier on the list, being anle to show the "user readable" serial number in the dive log is a feature - one that we are interested in having.
That's why Linus suggested a new callback that returns the serial number STRING for those devices where it is known how to create it. So no change is suggested to the existing 32bit number - just the addition of a human readable serial number to the API.
/D