tradspool tooken weirdness

Christoph Biedl <[email protected]> Thu, 21 Dec 2023 20:12:56 +0100
Newsgroups	gmane.network.inn
Message-ID	<[email protected]>
So I was looking into ol' tradspool, and took a peek into the history
file to see when an article is tradspooled. And eventually saw something
like this:

    @05630000135A000000000000628500000000@

Even without checking any documentation it was pretty obivous: Storage
method 5, class 99, group number 0x135a = 4954, article 0x6285 = 25221;
and yes, that's it.

However, this does not match the token description as in tradspool.c:

    **  The token is @05nnxxxxxxxxyyyyyyyy0000000000000000@
    **  where "05" is the tradspool method number,
    **  "nn" the hexadecimal value of the storage class,
    **  "xxxxxxxx" the name of the primary newsgroup (as defined
    **  in <pathspool>/tradspool.map),
    **  "yyyyyyyy" the article number in the primary newsgroup.

More precisely, the article number part should be eight positions
further to the left. And indeed, "sm -c" gets it wrong, check artnum in
the output:

    @05630000135A000000000000628500000000@ \
        method=tradspool class=99 ngnum=4954 artnum=0 \
        file=(...)/spool/articles/comp/lang/mumps/25221

Before you freak out, the only real problem is the visual in "sm -c"
above.


So, this is on amd64, and I'm certain this happens on all 64 bit
architentures, or more precisely: Where sizeof(long) is 8 - but I guess
that's the same thing.

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 uint32_t
when it's about article and group numbers[1], 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.

Cheers,
    Christoph


[1] Perhaps some day there'll be an architecture/ABI where long is
    128 bit. Then we're in trouble.

-- 
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
signature.asc (application/pgp-signature, 833 B)