tradspool tooken weirdness

Christoph Biedl isc.cxzo at manchmal.in-ulm.de
Mon Jan 15 20:05:50 UTC 2024


Julien ÉLIE wrote...

> Hi Christoph,
>
> All right, it would indeed be better to have a homogenized syntax for
> tradspool tokens between 32 and 64-bit archs.
>
> The only drawback I see if we enforce uint32_t instead of unsigned long, is
> that it is not in the path towards supporting 64-bit article numbers (but
> well, that's another story and amount of work globally in INN).  At least it
> would make consistent the generation of 32-bit article numbers in tradspool
> tokens, but while we're at doing a migration, why not use uint64_t instead
> for article numbers?  (group numbers may be kept as uint32_t)

Heh, was thinking about 64bit article numbers as well ...

Here, I am slightly leaning towards doing this, or at least to open the
path for it.

Major concern is "Is this really needed?". The highest article number I
have here has seven digits (in control.cancel, no surprise), and the
last number reset was at least 25 years ago. So hitting the 32 bit limit
is not going to happen any time soon.

On the other hand, there's the main lesson from y2k and upcoming y2038:
Software will be used for way longer times and at way bigger scale than
initially anticipated - therefore adapt early. Also, today's systems are
really powerful enough to handle the additional computational overhead.

As a little bonus and if I assess the situation correctly, that would
move the job of token conversion from 64bit to 32bit systems, and no
doubt their number is small, and shrinking.

Related, has anybody already tested whether clients can handle >32bit
article numbers? I fear the worst ...

> > * Extra code that deals with these invalid tokens by picking the article
> >    number from the place where it is. That the transition I was talking
> >    about.
> >
> > * Additionally, the next news.daily could repair these invalid tokens as
> >    well.
> >    Pro: The handling of invalid tokens could be removed again faily soon,
> >    say after the next major release.
>
> Seems like the better way.  When news.daily regenerates the history file,
> these tokens can indeed be fixed.

Now I feel the temptation to implement that but I even haven't sent out
the patches I had promised last month ...

    Christoph


More information about the inn-workers mailing list