php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #48442 strpos does not attempt to cast needle as string if needle is an object
Submitted: 2009-06-01 00:50 UTC Modified: 2020-10-23 12:49 UTC
Votes:5
Avg. Score:3.8 ± 1.0
Reproduced:5 of 5 (100.0%)
Same Version:1 (20.0%)
Same OS:1 (20.0%)
From: deadowlsurvivor at gmail dot com Assigned: cmb (profile)
Status: Closed Package: *General Issues
PHP Version: Any OS: Irrelevant
Private report: No CVE-ID: None
 [2009-06-01 00:50 UTC] deadowlsurvivor at gmail dot com
Description:
------------
Currently, if you attempt to set 

Reproduce code:
---------------
class foo {
private $bar;
public function __construct($bar) {
$this->bar = $bar;
}
public function __toString() {
return $bar;
}
}

$a = new foo('abc');
$b = new foo('ab');
$pos = strpos($a,$b);


Expected result:
----------------
$pos holds the value of 0.


Actual result:
--------------
While $a is cast to a string, PHP attempts to cast $b into an integer, as documented. However, wouldn't it make sense to attempt to cast $b into a string if casting it as an integer fails? Or even to attempt to cast it into a string first?

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-04-30 22:45 UTC] levim@php.net
-Status: Open +Status: Feedback -Package: Feature/Change Request +Package: *General Issues -Operating System: Ubuntu Linux +Operating System: Irrelevant -PHP Version: 5.2.9 +PHP Version: Any
 [2014-04-30 22:45 UTC] levim@php.net
Is this something you are still interested in seeing?

Personally this looks nonsensical; objects aren't integers and so you need to do any conversion yourself.
 [2014-04-30 23:33 UTC] deadowlsurvivor at gmail dot com
-Status: Feedback +Status: Open
 [2014-04-30 23:33 UTC] deadowlsurvivor at gmail dot com
Wow, it's been a while since I posted this. It's more consistent with other type casting operations to type cast to the traditional expected value if applicable (even integers as an ordinal value). However, to obtain this consistency it would hurt backwards compatibility. I would be gracious if there was a release of PHP that focused on consistency issues that have been neglected for reasons of backwards compatibility, which would likely entail a new major version. If that's not the direction that the PHP developers are interested in, you can go ahead and close this or otherwise assign it to a new larger version number.
 [2014-05-25 01:41 UTC] chx@php.net
1. AFAIK when casting something that is neither a string nor a number into an integer it can only be 0 or 1 and are you really looking for chr(0) when calling strpos(foo, FALSE)? I'd say a warning would be much better than casting. Anyways...

2. Objects have no ways to be cast into an integer however they may have a way to be cast into a string so instead of trying to cast integer which can only fail why not try to cast into string? This would be a very small BC break because previously this emitted an error message so probably it is not in any code.
 [2017-08-17 12:50 UTC] maggus dot staab at googlemail dot com
I totally agree with the initial poster.

objects implementing __toString() should be converted to a string automatically when used for parameters which are expected to be string.

my example is:

<?php

class stringable {
    function __toString() {
        return "abc";
    }
}

$s = new stringable();

// AS EXPECTED: converts the object into a string executes the replace in the same fashion with a plain php string
var_dump(str_replace('a', 'x', $s)); // print xbc

// both of the following lines emit a warning but are expected to use the given object as a string and proceed
// both emit: Notice: Object of class stringable could not be converted to int
var_dump(strpos('abcd', $s));
var_dump(stripos('abcd', $s));

see https://3v4l.org/Bf3Ah
 [2020-10-23 12:49 UTC] cmb@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2020-10-23 12:49 UTC] cmb@php.net
> I would be gracious if there was a release of PHP that focused
> on consistency issues that have been neglected for reasons of
> backwards compatibility, which would likely entail a new major
> version.

That would be PHP 8.0, where the issue at hand has been resolved,
see <https://3v4l.org/7X8QE>.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 00:01:28 2024 UTC