[PEAR-BUG] Bug #17689 [Fbk->Csd]: Int casting causes incorrect values for large groups on 32-bit systems

[email protected]
Newsgroups php.pear.bugs
Message-ID <[email protected]>
Edit report at http://pear.php.net/bugs/bug.php?id=17689&edit=1

 ID:               17689
 Updated by:       [email protected]
 Reported By:      pear at pmow dot org
 Summary:          Int casting causes incorrect values for large groups
                    on 32-bit systems
-Status:           Feedback
+Status:           Closed
 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:

-Status: Feedback
+Status: Closed
Thank you for your bug report. This issue has been fixed
in the latest released version of the package, which you can download at
http://pear.php.net/get/

Closed without feedback :-(


Previous Comments:
------------------------------------------------------------------------

[2010-12-24 13:32:04] heino

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

------------------------------------------------------------------------

[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

or

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
option?

------------------------------------------------------------------------

[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 
appropriate!

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
automatically 
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?
And 
believe me users will end up having PHP recast the numbers strings to 
numbers!

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
numbers 
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
and 
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
possible 
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
2,147,483,647 
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
between 
related packages). In case you should be interested I would search the 
archieves…

------------------------------------------------------------------------

[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?

------------------------------------------------------------------------

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
    http://pear.php.net/bugs/bug.php?id=17689

-- 
Edit this bug report at http://pear.php.net/bugs/bug.php?id=17689&edit=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.