Christoph Biedl reports that tradspool tokens have a different syntax on 32 and 64-bit architectures. Article numbers (as unsigned long in the tokens) are written either on 4 or 8 bytes, leading for instance to either @05630000135A000062850000000000000000@ or @05630000135A000000000000628500000000@.
The underlying issue is the assumption sizeof(uint32_t) == sizeof(long) which holds for 32 bit. But here, MakeToken gets an article number (artnum) as unsigned long (64 bit), converts it using htonl which is 32 bit, likewise for (group) num. For storing the article number however, sizeof(num) is used as the offset, so 8, while by design it should be only 4. Luckily, the reverse operation TokenToPath uses the same semantics, so things do work as expected, and nobody noticed in decades. Only tradspool_explaintoken fails since it uses uint32_t which follows the design but does not match the implementation.
There are several ways to get out of this. Quick and dirty, adjust tradspool_explaintoken and the documentation. Nicer was to make the implementation follow the design, replace unsigned long with _uint32t when it's about article and group numbers, and have a transition in the lookup code for the article number: it would check both offsets (4 and 8), the non-zero one has the actual information. That might as well be done as part of an upgrade.
Christoph Biedl reports that tradspool tokens have a different syntax on 32 and 64-bit architectures. Article numbers (as unsigned long in the tokens) are written either on 4 or 8 bytes, leading for instance to either
@05630000135A000062850000000000000000@or@05630000135A000000000000628500000000@.The underlying issue is the assumption
sizeof(uint32_t) == sizeof(long)which holds for 32 bit. But here,MakeTokengets an article number (artnum) as unsigned long (64 bit), converts it usinghtonlwhich is 32 bit, likewise for (group)num. For storing the article number however,sizeof(num)is used as the offset, so 8, while by design it should be only 4. Luckily, the reverse operationTokenToPathuses the same semantics, so things do work as expected, and nobody noticed in decades. Onlytradspool_explaintokenfails since it usesuint32_twhich follows the design but does not match the implementation.There are several ways to get out of this. Quick and dirty, adjust
tradspool_explaintokenand the documentation. Nicer was to make the implementation follow the design, replace unsigned long with _uint32t when it's about article and group numbers, and have a transition in the lookup code for the article number: it would check both offsets (4 and 8), the non-zero one has the actual information. That might as well be done as part of an upgrade.