Edit report at http://pear.php.net/bugs/bug.php?id=17689&edit=1

ID: 17689
Updated by: heino@gehlsen.dk
Reported By: pear at pmow dot org
Summary: Int casting causes incorrect values for large groups
on 32-bit systems
Status: Feedback
Type: Bug
Package: Net_NNTP
Operating System: Ubuntu
Package Version: 1.5.0a1
PHP Version: 5.2.6
Assigned To: heino
Roadmap Versions:
New Comment:

This bug is still hanging due to lack of final feedback. I'm about to
roll a new version,
and would like to make it a beta, but that won't happen unless I have
some positive
feedback on this bug. This bugfix could theoretically break something,
although it's
unlikely, so if I don't get any feedback from anyone, I'll might roll
back the related
commits to get the other fixes out there...

Previous Comments:

[2010-08-22 16:19:19] heino

-Status: Analyzed
+Status: Feedback
Thank you for taking the time to report a problem with the package.
This problem may have been already fixed by a previous change that
is in the SVN of the package. Please checking out the SVN
repository of this package and upgrade

svn checkout svn.php.net/repository/pear/packages/Net_NNTP/trunk
pear upgrade package2.xml


pear upgrade package.xml

If you are able to reproduce the bug with the latest SVN,
please change the status back to "Open".
Again, thank you for your continued support of PEAR.


[2010-08-13 22:58:37] pmow

Casting to strings will only result in the script converting to float
for calculations. As you say, the only real benefit is when dumping the
string directly into a database which can handle larger numbers.

Yes I mentioned floats but the loss of precision will not practically
happen for another several hundred years. Would this not be the best


[2010-08-13 22:17:55] heino

-Status: Verified
+Status: Analyzed
-Assigned To:
+Assigned To: heino
I’ve looked through the code, and the problem is more profound than
the few
lines you pointed out, yet it’s fixing it doable. To preserve some
degree of
consistency recasting to strings should also be done where otherwise

As you point out floats is out of the picture due to loss of precision,
but strings
would however also be problematic to some degree. PHP would
recast the numbers cast as string into integers/floats at will if the
user did any
calculations, and then we wouldn’t really have solved anything, right?
believe me users will end up having PHP recast the numbers strings to

Fixing this bug, which is actually more of a platform inadequacy to
handle a
certain task, would only allow users on a 32 bit system to treat article
as strings, that’s it. Using the original substring (by not forcefully
recasting to
an integer) would of cause allow one to use Net_NNTP to fetch articles
store them, or at least their meta data, in a database – but one would
have to let
the database do any needed calculations, which would of cause make it
the handle unsigned 32 bit integers...

To be honest I’m considering the possibility that this ‘bug’
shouldn’t be fixed at
all, and that users who wish to handle newsgroups larger than
articles should upgrade to modern 64 bit systems. That said I’m still
willing to
consider applying a patch, but I’m not the one to make any patch to
save your
customer/user from a hardware upgrade!

Please take into consideration that since Net_NNTP (RFC977 et. al.) was

written NNTP has been upgraded to version two (RFC 3977) in the autumn
2006. Also the package was written for PHP4, and doesn’t use
exceptions and
such. This is ancient code, which was optimized for the past – yet
ancient code,
which handles present tasks on current modern 64 bit hardware…

BTW Some seven years ago wrote an unpublished exception based PHP5
packages for NNTP, POP3 and SMTP (it never got into the PEAR community,

since I pretty much left due to the lack of cross package coordination
related packages). In case you should be interested I would search the


[2010-08-11 22:00:11] pmow

It seems not casting at all would be best. Casting as a float would
indeed result in a loss of precision, although at the moment the largest
usenet group a.b.boneless is 3770886011 (10 chars) and the precision
that I get when casting is 12 characters.

The growth in the last year of this particular group was 1.3B posts. If
we assume a linear growth (not really expected) we have 769 years to go.
So if you want to use floats, that's fine I think.

If you simply want to clean the output I'm guessing is_numeric would
work. The output from server would be saved in whatever is most
efficient (integer, float/double, string). It seems like this would be
ideal, no?


[2010-08-11 19:23:25] heino

From my point of view it’s Net_NNTP which doesn’t comply with the
RFC! When I
wrote the code I probably focused on minimizing memory usage and
optimizing serialization/unserialization of the data, and I never
thought of the
possibility of someone accessing huge groups from a 32 bit system (which
supports 2147483647 messages compared to the 64 bit max of
9223372036854775807 messages).

I pretty much agree with you on the flexible casting in PHP, and I
don’t consider
this a major BC-break, especially if casting to floats would fix this
bug. There are
however still possible issues to consider - like cashed serialized data
and such and
whether the precision of floats is a problem. Truth be told, the bug
should only be
relevant on a 32 bit system and, and personally I don’t think the 64
bit users
should be bothered unnecessary…

All that said I honestly don’t expect recasting to strings (by
removing the casting) –
except for perhaps a performance penalty under certain conditions and
certainly a
memory penalty. Floats on the other hand could break something if they
are not

One solution could be to only cast into integers up to PHP_INT_MAX, and
keep the
substring after that – or perhaps only cast into integers on 64-bit
systems. Any


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
postedDec 24, '10 at 12:31p
activeDec 24, '10 at 12:31p

1 user in discussion

Heino: 1 post



site design / logo © 2022 Grokbase