php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #35874 base_convert is off on numbers greater than 13 decimal places
Submitted: 2006-01-03 02:04 UTC Modified: 2006-01-04 16:31 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: chris at acsi dot ca Assigned:
Status: Not a bug Package: Documentation problem
PHP Version: 5.1.1 OS: Windows XP Sp2
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: chris at acsi dot ca
New email:
PHP Version: OS:

 

 [2006-01-03 02:04 UTC] chris at acsi dot ca 
Description:
------------
base_convert($str, 10, 16) will not function properly with numbers greater than 13 characters.  

Reproduce code:
---------------
-BEGIN SCRIPT-

	$string=(string)"Hello Kitty".(string)time();
	$hash=md5($string);
	$hash=strtoupper($hash);				// Easier to Read
	echo("<br>1Hash is '$hash'<br>");
	settype($hash, "string");			
	echo("<br>2Hash is '$hash'<br>");
	$hash=base_convert($hash, '16', '10');		// Flick the string from hex to dec
	echo("<br>3Hash is '$hash'<br>");
	$hash=base_convert($hash, '10', '16');		$hash=strtoupper($hash);
	echo("<br>4Hash is '$hash'<br>");		// Flick the string back
	$hash=strtoupper($hash);				// Easier to read
	echo("<br>5Hash is '$hash'<br>");

-END SCRIPT-

Expected result:
----------------
I can't show the exact expected number, as my MS Calc in hex mode can't handle this number, but it's pretty obvious that all the trailing 0's are wrong. 

Actual result:
--------------
Here is the output text:

1Hash is '9789A9C80C9BFB6B40AD83670F14D64A'

2Hash is '9789A9C80C9BFB6B40AD83670F14D64A'

3Hash is '201428215609899446868600620602402480202'

4Hash is '9789A9C80C9BF8000000000000000000'

5Hash is '9789A9C80C9BF8000000000000000000'

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-01-03 13:24 UTC] chris at acsi dot ca 
Yes, I'm familiar with processor limitations, but there is no reason why this function should be limited that way. This problem shows up with a number of 8 bits at maximum size (18446744073709551615 dec unsigned). You can also get the problem with a number of FFFFFFFFFFFFF hex unsigned, which is between 4 and 8 bits. 

What type of math is the function doing that an 8 bit number is being mangled by a 32 bit OS/CPU limitation?

The documentation does not mention any limitation, so either the documentation should be updated to reflect it's limitations (which is a cop out), or the logic should be updated to follow something similar to the many posts people have left under the base_convert() manual entry. 

Am I missing something here? It still sounds like the function is broken.
 [2006-01-04 10:20 UTC] mgf@php.net 
You're confusing bits and bytes. #FFFFFFFFFFFFF is a 6-1/2 byte number, which is 52 bits -- somewhat beyond the 32-bit (4-byte) integer limitation.

Maximum value of a signed 32-bit integer is 2147483647 (or 4294967295 unsigned), not even close to the huge number you quote.
 [2006-01-04 16:31 UTC] chris at acsi dot ca 
Ah, my bad, couldn't see the forest for the trees. In light of the facts, I make the following suggestion then;

1) Update the documentation to reflect the fact that this function is limited as you've pointed out. You may want to include warns in the other similar functions. 

2) Propose that somewhere down the road, someone create a new function that is able to work with at least a MySQL BIGINT (8 byte) integer. 

Thanks, that's the end of my $0.02..
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Oct 29 08:00:01 2025 UTC