GNOME Bugzilla – Bug 549655
Support 64 bit article numbers
Last modified: 2009-09-28 23:44:38 UTC
GigaNews is moving to 64 bit article numbers. <http://www.giganews.com/news/article/64-bit-Usenet.html> “Giganews is advising all Usenet client and NNTP software developers to adopt a 64–bit unsigned integer format for article numbering.”
Created attachment 117492 [details] [review] 64 bit article numbers This patch should add all necessary supports for 64 bit article numbers. It passes make check. I have NOT added support for article counts being 64 bit. Note: The test programs need to be updated with cases using 64 bit numbers.
We should note on this bug: Apparently sometime late on Tuesday 21 April 2009 CDT (UTC -0500), some people using Xnews began suddenly logging strange errors showing “bits index out of range” and asking for help in the ‘news.software.readers’ group. Turns out they were trying to access ‘alt.binaries.boneless’ which of course is the largest group by far. And they were using GigaNews. Yep, you guessed it: GN and other servers have finally went over the 31–bit limit for article numbers. ;) [RFC-3977 sets this limit, while older related RFCs had no published limit AFAIK, go figure…] The discussion starts here with tpka ‘pianotech’ getting the error: <news:Xns9BF4EAC7C30A5pianotech@127.0.0.1> Later in that thread, on Thursday 23 April, tpka ‘Guy’ was watching his newsrc counter for boneless. By 3:50pm CDT, it tripped over the limit (not sure what server he was using at the time). Later that same date (night-time 23 April CDT), an Astraweb user posted a confirmation there. Then the discussion touched on how some UseNet–providers are simply effective clones of the major ones. Which means this problem has already begun spreading all over creation. ;) Most people are aware of boneless and do not try to load/sync headers; instead, keen usenetters will resort to NZB indexing sites, or FTD or such, to try locating what–not, which all operate on the “Message-ID” gizmo. But one does not need to actually load any headers from boneless to experience this problem: As soon as you open boneless in your news–reader, the NNTP dialog will try reading the “high–water mark” for the group, which is over the 31–bit limit. *Boom* right there your software might experience an error if it hasn’t been patched yet. There probably are several areas in the code for any news–reader that need patching, as you can see in the attachment for this very bug for pan2. The “open group” code is just one place. So this to me seems to be an historical moment. :) And it is a bit uncanny that GN did predict it occurring within a rough time-frame (re: article published at the URL mentioned at the top of this bug–report). It seems the next–biggest group is ‘alt.binaries.nl’ which has lots of room, but who really knows what will happen in the future…
The patch for this has been applied in my repo: git://github.com/lostcoder/pan2.git
khaley: is the patch in your github repo the same as https://bugzilla.gnome.org/attachment.cgi?id=117492?
Created attachment 144201 [details] [review] updated patch No, I had to fix some minor display bugs. Here is the updated version. I had to pull it from 2.3 commits.
thanks for the update. Committed to git.gnome.org: http://git.gnome.org/cgit/pan2/commit/?id=647b8c2cc79468611ef91637cedc3aebb3921119 diffs from lostcoder repo: use G_GUINT64_FORMAT when printf()ing a uint64_t