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

go to bug id or search bugs for

Bug #63510 Integer overflow with chr should be able to be detected
Submitted: 2012-11-14 09:36 UTC Modified: 2021-07-26 22:17 UTC
From: idokan at gmail dot com Assigned: cmb (profile)
Status: Not a bug Package: Strings related
PHP Version: 5.4.8 OS:
Private report: No CVE-ID: None
View Developer Edit
 [2012-11-14 09:36 UTC] idokan at gmail dot com 
Description:
------------
The chr function translate a single Byte length integer into it's ASCII value.
When providing a number bigger then 255, it returns the first byte instead of reporting an error about being out of range.

Test script:
---------------
echo chr(1000) . ' ' . ord(chr(1000)) . "\n";

Expected result:
----------------
chr must check the numeric boundaries and report on on an error when they are out of the range.

Actual result:
--------------
returns the first byte out of the result, making it appear like an integer overflow that the carry flag exception was captured.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-11-14 15:28 UTC] laruence@php.net 
I think this check could be done in user script self.

the document said:
chr convert *ascii* code .. so...
 [2012-11-14 15:36 UTC] idokan at gmail dot com 
Huh ?!

ASCII is 0..127 chars, if they are out of range and also from extended ASCII (128..255), then you must report an error like with normal implementation such as Ruby, Python, Pascal, Perl (with strict bytes) etc...
Not to $value & 255 it.
 [2013-10-24 06:56 UTC] yohgaki@php.net
-Assigned To: +Assigned To: yohgaki
 [2013-10-24 06:56 UTC] yohgaki@php.net
-Status: Assigned +Status: Open
 [2015-02-03 06:52 UTC] yohgaki@php.net
-Type: Bug +Type: Feature/Change Request
 [2016-07-01 19:49 UTC] cmb@php.net 
It seems to be appropriate to point out why this ticket had been
changed to feature request. :)

> Not to $value & 255 it.

Actually, the integer is simply cast to char and used as the first
and only byte of the returned string[1].

Of course, this behavior is questionable, but changing it would
cause a BC break, so it can't be done in a minor version or even a
patch release without a very good reason. Simply stating "you must
report an error like XYZ" is not a very good reason, in my
opinion. I'd rather fix the docs and maybe change the behavior in
the next major version.

[1] <https://github.com/php/php-src/blob/php-7.0.8/ext/standard/string.c#L2793>
 [2016-07-01 20:07 UTC] cmb@php.net 
Automatic comment from SVN on behalf of cmb
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=339537
Log: Address #63510: Integer overflow with chr
 [2016-08-28 21:20 UTC] yohgaki@php.net
-Summary: Integer overflow with chr +Summary: Integer overflow with chr should be able to be detected
 [2016-08-28 21:20 UTC] yohgaki@php.net 
Should we close this bug? I'm fine with documentation change. 

chr() may have strict option that detects overflow, also. 

string chr(long $code [, bool $strict=FALSE])
 [2016-08-28 21:22 UTC] yohgaki@php.net 
BTW, we'll have mb_chr()/mb_ord() from PHP 7.2

commit 087dcd9381c33057901dbe1ef89847d6fa87316d
Merge: 4a3188f 15e32fd
Author: Yasuo Ohgaki <yohgaki@php.net>
Date:   Wed Aug 10 09:47:27 2016 +0900

    pull-request/1100
    Request #65081 mb_chr() and mb_ord()
 [2021-07-26 22:17 UTC] cmb@php.net
-Status: Assigned +Status: Not a bug -Type: Feature/Change Request +Type: Bug -Assigned To: yohgaki +Assigned To: cmb
 [2021-07-26 22:17 UTC] cmb@php.net 
Well, after almost five years without further comments, let's call
it desired behavior, and this ticket not-a-bug.

If anyone feels the behavior should be changed, please pursue the
RFC process[1].

[1] <https://wiki.php.net/rfc/howto>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 13:01:29 2024 UTC