[NNTP] 64-bit article counter extension strawman

[Steve Walker]

Russ Allbery wrote:

> 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).

Glibc supports 64 bit numbers as does the Microsoft stuff as far 
as I'm aware.  There really isn't much out there that couldn't 
support at least 64 bit numbers.  And if a system didn't it 
wouldn't break until the 31/32 bit limit was reached so why would 
it really matter.  It was doomed to break anyway.

> 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

I think rolling over is prone to problems and it's not worth it 
when there is there is a good clean method of using 64 bit numbers.

> 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.

It worked for 977 so why wouldn't it continue to work.  It would 
be just like file systems limits.  Each file system is rated to x 
number terabytes.  We would have servers/clients that claim we're 
rated to article numbers up to x billion.  I'm not saying this is 
a good thing.  I'm just saying this is what will happen as soon 
as servers start exceeding 31 bits.

If you specify a 32 bit limit in the protocol client authors will 
not know what is the proper method to fix the overflow problem. 
Everyone will be forced to guess and we will have a mess.

Steve.