[NNTP] 64-bit article counter extension strawman

[Russ Allbery]

Forrest J Cavalier <forrest at mibsoftware.com> writes:

> MSVC has 64 bit integer types for what, 8 years now, and that generates
> code that runs on 386's.  GCC has supported "long long" for just about
> that long or longer.

I'm not really disagreeing with what you're saying, just making sure that
everyone understands what I'm talking about.

Support of the 64-bit type itself is, as previously noted, not really the
gating factor.  It's the supporting library functions that are more of a
problem, and GCC can't help with your printf implementation (for example).

> A note about breakage seems appropriate.  Servers MAY roll over at 31
> bits seems appropriate to me.

Do we want to allow rolling over?  Rolling over comes with its own set of
bugs, in particular triggering the low > high logic that causes many
clients to consider the group empty.  I'm not sure we want to allow *both*
rolling over *and* longer article numbers.  We would get all the different
breakage scenarios at the same time.

> But we don't need to save bits in NNTP, so I'd not even specify 64
> bits...except that leaving it open-ended seems to promote abuse of
> article number as a structured number, instead of a plain sequence
> number.

Saying "there's no limit and you should be prepared for any length of
article number" says to client authors "you must include a bignum
library."  That seems a little excessive, and in practice I doubt clients
will actually do this.  I think we need to be very careful about what we
say about allowed or recommended client behavior if we really don't
specify any limit.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>