Subject: [NNTP] 32 bit article counters

From: Steve Walker <[email-masked]>
Date: Fri, 08 Jul 2005 12:06:17 -0500

Hello Everyone,

I would like to re-open the discussion on new 32bit article 
number limit added to proposed RFC977 replacement.  As most 
people know, RFC977 wisely left the article numbers as text, 
limited by line length limits.  Good software will deal with long 
article numbers since they are text even if their binary 
conversion exceeds 32bits.  It's just a matter of time before 
these counters exceed 32bits.  The proposed protocol does not 
specify what should happen when this even happens.  Should the 
counters wrap around or does Usenet just finally die?  The 
proposed protocol has forbid wrapping by placing the restrictions 
that the high counter can not be less than low counter.

Personally I use software that serializes all articles into a 
"master" type newsgroup and I use the same article number for all 
cross posts.  Our article counters will exceed the 32bit number 
much sooner than other servers, but all servers will eventually 
reach this new limit.  I will reach the 32bit article number 
limit within 2 years. (2^32 - 6 million articles per day = ~2 
years).  Other servers will reach the limit in less than 8 years 
(from inital setup).

For example, if you consider a group the receives 500K articles 
per day and factor in 2X growth every 2 years to get the 
following.  Note this is if you setup the server/counters today. 
  Most servers have been running for years.

Year	Day		Year		Total
1	500000		182500000	182500000
3	1000000		365000000	547500000
5	2000000		730000000	1277500000
7	4000000		1460000000	2737500000
9	8000000		2920000000	5657500000
11	16000000	5840000000	11497500000

Since RFC977 did not place any limits and software is in use that 
relies on this fact I think this new proposal is actually moving 
us backwards.  I propose that the limits either be removed 
entirely or they be specified as a more reasonable 64 bit counter.

Regards,
Steve Walker
NNTPServer.com

---

From: Russ Allbery <[email-masked]>
Date: Fri, 08 Jul 2005 11:59:05 -0700

I think this needs general discussion by the group.  I'll go ahead and
state my opinion for the record and then stay quiet and let people talk it
over, since Steve has already heard my view on this.

There are definitely some reasons to want to move to either 64-bit article
IDs or require that software deal with arbitrary length article IDs:

 * A news configuration like Steve's that files all articles in a single
   group for one reason or another will interact poorly with a limited
   article ID space, or at least a 32-bit limited article ID space, given
   current traffic.  I was personally unaware that anyone was doing this.

 * It's likely that eventually some newsgroup will, in a normal
   configuration, overflow a 32-bit counter.  My calculations indicate
   that it's likely to take another 20 years or so, but assuming that
   Usenet persists and certain groups remain popular, both fairly
   reasonable assumptions in my opinion, it will happen eventually and
   there's no good way of dealing with it at present.

 * Arbitrary limits are bad and should be avoided wherever possible.

There are also sound reasons why the working group originally took the
course of action it did and restricted the article ID space to 32 bits:

 * This is widespread existing practice.  Lots and lots of news software
   uses article IDs as numbers to do numeric comparisons (in fact, one has
   to do so to reasonably implement some portions of the NNTP protocol),
   and that software overwhelmingly uses 32-bit integers to do so.
   Requiring 64-bit article IDs would immediately declare out of
   compliance quite a lot of existing software and using them in practice
   would break quite a bit of software.  (Let alone arbitrary numbers.
   Adding a bignum library to news software to be able to do range
   calculations and range compaction seems like it's asking a lot to me.)

 * The article ID space is not being exhausted quickly for normal usage.
   The most heavily used regular group has probably exhausted around 5%
   of the available article ID space.  While I think it's likely that some
   group will eventually overflow, it's not certain, and it's quite some
   distance into the future.  *Assuming* that one doesn't care about the
   configuration that puts all articles into a single group (a very large
   assumption), it's not clear that this is a problem we should be
   worrying about right now, as opposed to getting out a better starting
   point for future work.

 * Large article IDs may be better handled by an extension than a revision
   of the base specification, since that leaves an out for older software
   that hasn't been revised to support larger article IDs by forcing the
   server to make some accomodation.

 * Availability of 64-bit integers is only now becoming widespread, and
   weren't widespread when this question was first considered by the
   working group.

My personal preference (not speaking as chair) would be to leave this
limit as is and deal with large article numbers via an extension.  The
details of how that extension would work would have to be worked out; the
simplest approach would be to make groups with large article numbers
inaccessible to clients that don't declare that extension, but there may
be a more elegant solution.  However, that's just my personal preference,
and if the working group reaches a different conclusion, I'm not going to
stand in the way of that.

Steve is entirely correct in his statement that RFC 977 puts no limit on
the article IDs.  RFC 977 did not reflect what people implemented in a
number of details, this being one of them.  While I'm sure there is
software out there that supports arbitrarily large article IDs, I'm not
personally aware of any and have not seen any; 32-bit article IDs are
universal in my experience.  The charter of this working group was to
produce a revision to RFC 977 that documents the existing situation.  I
believe that specification of a 32-bit article ID space makes sense within
that charter.  However, I can also see the objection that it represents a
regression of sorts from what RFC 977 says on paper.

On the question of timing, while it is in theory possible to put the
brakes on publication of the revised document at this stage, I believe it
would be a fairly serious thing to do.  So that everyone is aware, my
current intention is to take a few months break after we get all of our
documents out, put the work into INN to bring it up to snuff with the
specification, and then start gathering information and start the process
for a revision to draft standard.  We could certainly revisit topics like
this at that time.  (Somewhere in that range we should probably also do
the informational revision of RFC 2980.)

Note that this is a long-standing point of discussion for this working
group.  We first reached consensus on the current text about eight years
ago; Clive was the one who drafted it originally.  Since then, the topic
has been revisited every couple of years or so, and consensus was tested
and re-established each time.  However, this is the first time that I
recall someone bringing up a configuration that files all articles into a
single group.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Steve Walker <[email-masked]>
Date: Fri, 08 Jul 2005 16:28:41 -0500

Russ has already heard most of this in private, but I thought I 
would post it here.

>    that it's likely to take another 20 years or so, but assuming that

There can be many theories on how to estimate the point of 
collapse (I calculate <8 years), but I think everyone can agree 
that it will happen at some point.  NNTP V2 is the correct place 
to solve this problem.  If we solve it now, everyone can quit 
wasting their time talking about it.

>  * Arbitrary limits are bad and should be avoided wherever possible.

Which is how RFC977 solved it.

>    calculations and range compaction seems like it's asking a lot to me.)

They are already non RFC977 compliant.  The developers choose to 
use 32 bit counters and they saw it as an acceptable trade off. 
In the real world, nothing changes if we declare no limits or 
even 64 bit limits.  Their software breaks at 2^32 regardless of 
what the protocol says.  If the protocol specifies 64 bit 
counters we have the hope that software will be updated in time. 
  If the new protocol specifies 32 bit counters we have no hope 
and the existing RFC977 compliant software become non-complaint. 
  This is very similar to Y2K problems.  Had software developers 
used 4 digit years in the first place there wouldn't have been 
any Y2K issues.

>    weren't widespread when this question was first considered by the

Personally, I feel that any protocol that deals with text based 
numbers should not place any restrictions other than line length. 
    If people feel some overwhelming need to place limits in the 
protocol then either 1) use a limit that is large enough that it 
doesn't matter or 2) specify what should happen when the limit is 
reached.

The current protocol specifies that high counters can't be less 
than low counters and you can't exceed 2^32-1.  You can't have 
both without breaking stuff.

> limit as is and deal with large article numbers via an extension.  The

It is more logical to not change RFC977 limits in a non 
compatible way.  Nothing changed means nothing broken.

> brakes on publication of the revised document at this stage, I believe it

Making a major non-RFC977 compatible change is serious enough to 
warrant removing one line and leaving the existing RFC977 rules 
unchanged.

> ago; Clive was the one who drafted it originally.  Since then, the topic

Eight years ago no one thought there would be 6 million articles 
posted each day, year here we are and still growing.  In another 
eight years you can expect that number to be over 100+ million 
per day.  Protocols need to consider the future, not just what 
happens today.  Which is why the RFC977 didn't place a limit and 
allowed the software developers the freedom to adapt to current 
needs.

Steve Walker
NNTPServer.com

---

From: Ken Murchison <[email-masked]>
Date: Sat, 09 Jul 2005 12:13:07 -0400

If no current server/group has exhausted the 32-bit space as of yet, I 
don't see the problem in expanding the space to 64-bits now in NNTPv2. 
Let's get implementations moving forward *before* we run into a problem.

If I change my server to use 64-bits today (actually it might be 
already, I'd have to look), its not going to break any existing clients, 
since all article numbers returned by the server will still be below the 
32-bit threshold.  Conversely, if a client uses 64-bits to fetch 
articles from a 32-bit server, it will still work because all existing 
article numbers will still be below the 32-bit threshold.

I'd propose that NNTPv2 use language such as:

"Clients and servers MUST support article numbers between 1 and 
4,294,967,295 inclusive, but SHOULD support article numbers between 1 
and 18,446,744,073,709,551,615 inclusive."

This documents existing practice via the 32-bit limit but urges 
implementations to upgrade to 64-bit for the future.  Obviously the 
language in the current draft regarding a maximum of 16 digits would 
have to change.

Or we just mandate that NNTPv2 implementations use 64-bits, since it 
won't break existing implementations for at least 2 years and possibly 
longer, depending on implementation and the growth of Usenet.

I've spent a little bit of time thinking about how this could be handled 
by an extension, but it just seems too messy.  IMO, the best course of 
action is to urge client/server authors to start rolling out 64-bit 
implementations now, before the problem occurs.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Chris Caputo <[email-masked]>
Date: Mon, 11 Jul 2005 15:59:24 +0000 (GMT)

> over, since Steve has already heard my view on this.

I tend to stand by what I wrote in 1997 - copied below.

But I'd also be fine with an extension being defined which allows for 
numbers greater than 2^32-1.

Maybe the fix for now should just be to say that client software should 
assume a 32-bit wrap-around has occurred if the high article number is 
more than one less than the low article number.  The would allow servers 
using more than 32-bits to use a MOD 2^32 to create an standards compliant 
number.  For that to work we'd also have to adjust the draft to say that 
zero is a valid article number.

Chris

---

Date: Mon, 6 Jan 1997 10:40:02 -0800 (PST)
From: Chris Caputo <[email-masked]>
To: [email-masked]
Subject: Re: ietf-nntp New wording on article numbers - draft 2

On Mon, 6 Jan 1997, Brian Kantor wrote:
> Is that one's-complement, two's-complement, Burroughs mantissa/exponent,
> or double-precision IEEE-FP bits?
> The whole world isn't Microsoft/Intel yet, thank God.

On Mon, 6 Jan 1997, Clive D.W. Feather wrote:
> Because the protocol sends decimal digits, not binary numbers. The actual
> *value* is limited to 2^32-1 (so if you send 16 digits, the first five will
> all be zero).

The preceeding two comments have really got me thinking we shouldn't place
any limitations on decimal length or range of article numbers.  Why don't
we just let the market decide how many decimal digits to use?  Since this
is a text based protocol, it seems we shouldn't even worry about what
range a 32-bit number will allow.  I certainly am thankful Brian and
others didn't limit article numbers to 16-bits in RFC977, a bit length
that might have been appropriate for the market when the rfc was drafted.
We'd all be having flag days several times a year, if they did.  In this
same light, let's not limit RFC977bis.  The market will decide when it is
time to grow the range.

I propose we change the draft to not place limitations on decimal length
or range.  Coders can make their code handle whatever they feel is
appropriate.  Ie, Metscape may go off and make it so they can handle
infinite numbers (memory allowing), while Nicrosoft may decide to limit
their code to 64-bits.  Who knows...  The implementors get to decide what
trade-offs to take, and users make a decision of what to use based on this
kind of thing.  When a server and client get a conflict, it becomes an
issue of one side needing to upgrade to more timely code.  I think it's
reasonable that a newsreader from 1997 won't be able to handle a server
from 2017 without some upgrades.  The 1997 reader would become obsolete,
while modern readers handle the ranges that are seen in 2017.

Further, if I am a server operator of a server that can handle a range
more than some of my clients, I would like it to be up to me to be able to
decide whether to have a flag day or whether to encourage/force users to
upgrade their clients.

Therefore, I recommend a change in the draft from:

     Article numbers MUST lie between 1 and 4 294 967 295 inclusive. The
     client and server SHOULD NOT use leading zeroes in specifying article
     numbers, and MUST NOT use more than 16 digits. In some situations the
     value zero replaces an article number to show some special situation.

to:

     Article numbers MUST lie between 1 and infinity inclusive. The
     client and server SHOULD NOT use leading zeroes in specifying article
     numbers. In some situations the value zero replaces an article number
     to show some special situation. The actual article number range
     supported by an implementation is up to the implementor, but it is
     intended that the implementor will choose a range that corresponds to
     modern needs, while maximizing interoperability.

Chris Caputo
President, Altopia Corporation

---

From: Steve Walker <[email-masked]>
Date: Wed, 13 Jul 2005 21:25:51 -0500

Chris Caputo wrote:

 > But I'd also be fine with an extension being defined which
 > allows for numbers greater than 2^32-1.

I think 64 bit counters is the best solution.  I just had a 
conversation with the software developer of one of the popular 
commercial news clients.  He said his client already uses 64 bit 
numbers internally.

 > Maybe the fix for now should just be to say that client
 > software should assume a 32-bit wrap-around has occurred if the
 > high article number is more than one less than the low article
 > number.  The would allow servers using more than 32-bits to use
 > a MOD 232 to create an standards compliant number.  For that to
 > work we'd also have to adjust the draft to say that zero is a
 > valid article number.

While it may work, it's not perfect.  I think it will be prone to 
problems, as some clients will do it correctly and some won't. It 
is certainly better than the current proposed wording which 
basically says Usenet is over in X years and there is no way to 
fix it without whole new RFC being wrote.

RFC977 had no limit, which personally I think is best, but if 
others feel there MUST be a limit, then at least make it 
something reasonable.  A 32bit limit is not reasonable when you 
consider the big picture.

Steve.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 14 Jul 2005 09:33:48 +0100

>    current traffic.  I was personally unaware that anyone was doing this.

I'm also not entirely sure how they're conformant to Usefor, unless this is
a "secret" group that's being added as well as those in the article header.

>    there's no good way of dealing with it at present.

Agreed, which is something that we knew at the time.

>  * Arbitrary limits are bad and should be avoided wherever possible.

A good principle, but not always practical.

>    and that software overwhelmingly uses 32-bit integers to do so.

This was, as I recall, why we did it this way. We did, as I recall, spend a
little time looking at ways to address this and decided that none were
worth the complexity - on the rare occasion that a group wrapped round,
server operators could declare a flag day.

>    server to make some accomodation.

That would be a sensible transition approach. Then at a later point we make
the 64-bit behaviour mandatory.

> number of details, this being one of them.

I also strongly suspect that "nobody expected anything other than 32 bits".
I really don't accept the "RFC 977 didn't have a limit" argument, because
stuff written in those days tended to be much looser than would be
acceptable today.

> I
> that charter.

Agreed.

> ago; Clive was the one who drafted it originally.

True. I'm going to say more in another message.

My overriding view on this is "this discussion MUST NOT hold up publication
of the document". Since it's already at the RFC Editor (and IANA have
already done their actions) I don't believe we can address it in this
version.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 14 Jul 2005 10:06:46 +0100

> ago; Clive was the one who drafted it originally.

True.

I've had a look back. My first wording was written on 1996-12-27 and
proposed a maximum of 999,999,999.

> However, this is the first time that I

Actually, to my slight amazement, *I* wrote on 1996-12-15:

| as a thought experiment,
| would the following conform to 977 and, if not, why not ?
[...]
|   - Articles are numbered uniquely across the entire newsbase (with an
|     article having the same number in every group it appears in).
|   - Articles are numbered sequentially as they arrive from 1.
|
| I see nothing stating that article numbers must be less than (say) 2^32.

64-bit systems were mentioned in the ensuing threads. For example, Brian
Kantor wrote:

| Since the article numbers are not transmitted in a binary form, I see
| no reason to artificially restrict the range of article numbers by
| specifying the size or length of the representation.  A specification
| that the numbers are DECIMAL and represent actual article counts should
| be sufficient.  (I.e., we should not force epochal resets of a newsgroup
| article count just because it won't fit in N digits.)

and I replied:

| We need to specify the representation used in the protocol (decimal unsigned,
| leading zeroes allowed).
|
| If there is no upper limit on article numbers, all client software needs to
| implement arbitrary-precision arithmetic "just in case". This is, to my
| mind, unreasonable, and so we should put an upper bound.
|
| All reasonable systems can handle unsigned integers of at least 32 bits
| (the ISO C Standard requires them to). Therefore 4 294 967 295 (2^32-1)
| seems a reasonable limit. [I know I said 999999999 before; I won't embarrass
| myself by repeating my reasoning.]

The ISO C Standard point is an interesting one. The current version of the
Standard requires 64 bit support, but is not yet widely rolled out.

I replied to Chris Caputo:

| > If Usenet (as an example ;-) continues to grow as it has, we may eat this
| > space pretty quickly in which case we either need to expand the range to
| > 64 bits and/or precisely define how to handle rollovers.
| 
| There's no existing practice for handling such rollovers. Here's some
| possibilities:
| 
| (1) Ignore it. If a server reaches the limit for a group, the server
| operator declares a flag day when article numbers in several groups will
| be reset.
| 
| (2) Assume that, by the time the problem is significant, we can write
| 977-ter (replacement for 977-bis) to say that 64 bits are allowed (I think
| it's too early for that).
| 
| (3) Define some mechanism for giving groups epoch numbers. I don't like
| this offhand - too much has to change.
| 
| (4) Make article numbers be modulo 2^32. Actually, this idea can be
| improved on. Divide the number space into 4 quadrants:
|     Q0 = 1         to 2^30-1
|     Q1 = 2^30      to 2^31-1
|     Q2 = 2^31      to 2^31+2^30-1
|     Q3 = 2^31+2^30 to 2^32-1
| Some time after the low water mark for a group enters Q3 and before the
| high water mark is reaching danger, the server should reset the group by
| subtracting 2^31 from all article numbers. If the client has a recorded HWM
| (or LWM) in Q3, and sees a GROUP response in Q1, it should assume this has
| happened and adjust its records in the same way. Obviously, the reset has
| to be atomic, but this could be done on Unix by:
|     - link each article to its new number
|     - change the active file
|     - wait for all clients using the old numbers to disconnect (or
|       forcibly disconnect them);
|     - remove the links with the old numbers.

Later on, Chris Caputo wrote:

| The preceeding two comments have really got me thinking we shouldn't place
| any limitations on decimal length or range of article numbers.  Why don't
| we just let the market decide how many decimal digits to use?  Since this
| is a text based protocol, it seems we shouldn't even worry about what
| range a 32-bit number will allow.  I certainly am thankful Brian and
| others didn't limit article numbers to 16-bits in RFC977, a bit length
| that might have been appropriate for the market when the rfc was drafted.
| We'd all be having flag days several times a year, if they did.  In this
| same light, let's not limit RFC977bis.  The market will decide when it is
| time to grow the range. 
| 
| I propose we change the draft to not place limitations on decimal length
| or range.

and the topic seems then to have died.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 14 Jul 2005 10:10:57 +0100

> zero is a valid article number.

Actually, at the time I suggested a slightly better way (any time after the
LWM passes 2^31+2^30, reduce all numbers by 2^31; this avoids the zero
issue while still providing a clear flag).

But I think that there needs to be a fixed limit. Bignums are too expensive
in this context.

---

From: Steve Walker <[email-masked]>
Date: Thu, 14 Jul 2005 06:15:45 -0500

> But I think that there needs to be a fixed limit. Bignums are too expensive

No limits have worked very well so far.  Hardware has kept up 
with need.  People used 32 bit numbers in the past because that's 
what the hardware/software supported and it was all that was 
needed at the time.  People can now use 64 bit numbers because 
that's what modern hardware/software supports.  In reality, I 
don't see 64 bit article numbers overflowing in my children 
lifetime.  I can live with 64 bit numbers, they will work.

If everyone hates text based numbers then does anyone have a 
major problem with this:

6.
[snip]
Article numbers MUST lie between 1 and 2^64-1 inclusive.
The client and server MAY use leading zeros in specifying
article numbers, but MUST NOT use more than 20 digits.

It seems the least likely to cause anything to break that wasn't 
going to break regardless.  It also appears to follow what some 
of the software developers are already doing, myself included.

Steve.

---

From: Steve Walker <[email-masked]>
Date: Thu, 14 Jul 2005 06:28:25 -0500

> already done their actions) I don't believe we can address it in this

I totally disagree.  This is a major issue that must be resolved.
You can not push forward a proposed standard that is so
completely broken that it specifies a limit without any
corrective action.  Changing two lines of text fixes the problem
forever (well, almost forever).

Steve.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 14 Jul 2005 07:59:35 -0700

Steve Walker <[email-masked]> writes:

> I totally disagree.  This is a major issue that must be resolved.  You
> can not push forward a proposed standard that is so completely broken
> that it specifies a limit without any corrective action.  Changing two
> lines of text fixes the problem forever (well, almost forever).

Well, no, changing two lines of text does not fix the problem.  Your
argument is rather that changing two lines of text will get software
authors to fix the problem in all of their code so that 64-bit article
counters will then be usable.

Standards text has no magical effect on running software.  It's possible
(and in fact I believe it is likely) that 64-bit article counters will not
be usable in practice in the forseeable future even if our document
requires them.  That's a key part of this discussion that I don't want
people to miss.  If we say that article counters are 64-bit, but in
practice nearly all clients are 32-bit, we're not actually doing anyone
any favors; if that is the case, anyone implementing 64-bit article
counters following our standard will encounter significant breakage as
soon as they exercise that facility without any warning at all from the
standard.

The purpose of standards is to get people to do the right thing, yes, but
it's also to ensure interoperability.

Out of curiosity, and to be sure I wasn't overestimating the problem, I
checked slrn, a widely used Unix news reader for which it was easy to find
the source.  Here is the function that implements GROUP:

int nntp_select_group (NNTP_Type *s, char *name, int *minp, int *maxp)
{
   int estim;
   int min, max;
   
   switch (nntp_server_vcmd (s, "GROUP %s", name))
     {
      case -1:
        return -1;

      case OK_GROUP:

        if (3 != sscanf(s->rspbuf + 4, "%d %d %d", &estim, &min, &max))
          return -1;

        if (minp != NULL) *minp = min;
        if (maxp != NULL) *maxp = max;

        slrn_strncpy (s->group_name, name, NNTP_MAX_GROUP_NAME_LEN);
        break;
        
      case ERR_ACCESS:
      default:
        break;
     }

   if (NNTP_Try_Authentication == 2)
     NNTP_Try_Authentication = 1;
   return s->code;
}

Note that this fails silently with 64-bit article numbers in ways that are
likely to cause unexpected behavior in the rest of the program, and note
that there is no portable way to easily fix this code since there is no
portable sscanf directive for reading a 64-bit article number that works
on all of the platforms to which slrn has been ported.  This code would
need to be redone to use either Autoconf macros to determine the right
sscanf directive or to use strtoull with a fallback for platforms without
long long.

Note also that, as one might guess from the above, int is used all over
the slrn code base for article numbers.

I would expect to see similar things in most widely used news readers.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 14 Jul 2005 16:07:56 +0100

[...]

> likely to cause unexpected behavior in the rest of the program,

Actually, because it uses signed integers it will fail on some platforms
anyway.

> and note
> on all of the platforms to which slrn has been ported.

On platforms supporting C99, this code should be written as:

    uint_least64_t estim;
    uint_least64_t min, max;
[...]
        if (3 != sscanf(s->rspbuf + 4,
                        SCNuLEAST64 " " SCNuLEAST64 " " SCNuLEAST64,
                        &estim, &min, &max))

and will then work correctly on all such platforms.

(Incidentally, the spaces can be omitted from the format specifiers in both
cases.)

---

From: Russ Allbery <[email-masked]>
Date: Thu, 14 Jul 2005 08:32:23 -0700

> Actually, because it uses signed integers it will fail on some platforms

Yup, good point.

> and will then work correctly on all such platforms.

Right.  However, the only platform I personally have handy (of seven) that
actually supports a sufficient amount of C99 for that to work is Linux.
Various necessary bits of the above are missing on everything else I have
handy.

You can make it work with Autoconf glue -- there aren't that many systems
left that don't have any 64-bit type whatsoever (although there are some,
particularly if one isn't using gcc).  My question is more, will enough
people do so in order to really make this an interoperable practice?

(I wonder how much software will fail at 31 bits, too.  I dug a lot of
signed integers for article numbers out of INN when I started doing
cleanups, and I think there are still a few left in the corners.)

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 14 Jul 2005 16:44:29 +0100

> Various necessary bits of the above are missing on everything else I have

Which is why I think we're still at the "too early" stage. Another year or
two, perhaps.

> You can make it work with Autoconf glue

It's also possible to write the relevant header files for your system,
after which it Just Works. But the same comment applies.

> (I wonder how much software will fail at 31 bits, too.

The fact that nobody has worried about this is - to my mind - another stake
through the "977 had no limit" argument.

---

From: Steve Walker <[email-masked]>
Date: Fri, 15 Jul 2005 06:32:25 -0500

> counters will then be usable.

What about all the modern code that is already using 64 bit 
numbers?  We had a standard that said no limit.  Some used 32 and 
some used 64bit numbers.  The 64bit people are closer to the no 
limit and are not likely to ever have an overflow problem.  I 
know my code is 64 bit and at least one commercial client author 
I spoke with said they as as well.  I think more modern software 
is 64 bit clean than you think.

> Standards text has no magical effect on running software.  It's possible

What we have now is that some clients do one thing and some do 
something else.  This is exactly what a standard should solve. 
If we change the standard now the effects will not be noticed for 
years.  The servers are going to push numbers past 2^32-1 at some 
point.  They clients authors need to be warned (in the standard) 
and prepare for the time.

> soon as they exercise that facility without any warning at all from the

But you can't have it both ways.  You can't say in the standard 
that numbers MUST not roll over and also place a 32 bit limit on 
the number of articles knowing that it's just a time bomb waiting 
to happen.  There are but three logical choices:

1. Use a 64 bit limit.
2. Use a 32 bit limit but allow counters to roll over
3. Don't change RFC977 and use no limit.

The current text says:

The server MUST ensure that article numbers are issued in order
of arrival timestamp; that is, articles arriving later MUST have
higher numbers than those that arrive earlier.

> it's also to ensure interoperability.

It's a fact that the servers will need to exceed 2^32-1 at some 
point.  These clients are doomed to fail if they are not updated 
regardless.  At least we can get everyone to do the same thing.

> the source.  Here is the function that implements GROUP:

In all reality, slrn users are reading text groups.  They will be 
the last group of users to be effected by a 32bit limit.  I'm 
sure someone can bother to do a s/int/long long/ and recompile.

What you are proposing is changing the standard (RFC977) to place 
a new limit so a few easily changed open source clients don't 
have to be updated, even if it means breaking other clients  and 
servers in ways that can not be fixed.

> on all of the platforms to which slrn has been ported.  This code would

Who doesn't have access to the GNU glibc?

s/sscanf(s->rspbuf + 4, "%d %d %d", &estim, &min, &max)/
  /sscanf(s->rspbuf + 4, "%lld %lld %lld", &estim, &min, &max)/

That's not very hard.  And it's hardly an argument to cripple a 
standard.

> I would expect to see similar things in most widely used news readers.

Do you mean to say, most widely used text/unix readers.  What 
about the 100+ million Windows/binary client users that already 
support 64 bit numbers and are not likely to downgrade to 32 bit 
just because the standard changed on them?

Steve.

---

From: Steve Walker <[email-masked]>
Date: Fri, 15 Jul 2005 06:37:19 -0500

> through the "977 had no limit" argument.

No, it's just lazy programmers in general.  Typing 'int' is 
shorter, then 'unsigned long long'.

Steve.