[NNTP] 64-bit article counter extension strawman

[Steve Walker]

Russ Allbery wrote:
> Steve Walker <nntp at nntpserver.com> writes:
> 
>>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.
> 
> 
> I just refuted this statement in the paragraph immediately above your
> response.  If you want more details or have questions about the specifics
> of what I said, could you please ask them, rather than simply asserting
> that I'm wrong without any additional support?

I didn't mean to step on your toe's.  I apologize if you saw it 
that way, it was not my intention.  The question (or I guess it 
was more of a statement) was are there any modern systems out 
there that can not use either the glibc or windows libraries? 
Note that the glibc libraries are not the same as a gcc compiler.

>>It worked for 977 so why wouldn't it continue to work.
> 
> 
> No one actually implemented this aspect of RFC 977 that I am aware of.  If
> you know of a client implementation that supports arbitrarily long article
> numbers, I'd love to hear about it.  If not, then saying that it worked
> for 977 isn't a particularly useful statement, since RFC 977 itself didn't
> actually work as a standard in this area.

It work in the sense that everyone used a binary number that 
would hold a number large enough to get the job done.  Why didn't 
people use 8 or 16 bits numbers?  They choose a number that 
matched the current needs.  If we left it open the same would 
happen again.  People would slowly migrate to the next larger 
binary number, in this case 63/64 bit.

Steve.