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

go to bug id or search bugs for

Bug #79592 Converting string to bool when "0" passed
Submitted: 2020-05-12 21:14 UTC Modified: 2020-05-13 15:39 UTC
From: 6562680 at gmail dot com Assigned:
Status: Not a bug Package: Filter related
PHP Version: 7.3.17 OS: Win10
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: 6562680 at gmail dot com
New email:
PHP Version: OS:

 

 [2020-05-12 21:14 UTC] 6562680 at gmail dot com 
Description:
------------
I know, i know...
"you should use strict_types()" and so...

But really guys, why, exactly, why string "0" will be converted to false while calling (bool) ?

Please :///

Once i found same joke while comparing two values on usort(), fixed... now i remember used everywhere (! $string) and confused... little bit.

Test script:
---------------
function (string $name) {
  if (! $name) {
    // nice one, junior, you'll lose "0" right here
    // please rewrite your project and use ('' !== $name) or be fired

    throw new \InvalidArgumentException('String should be not empty');
  }

  // some code
}

Expected result:
----------------
(bool) 0 === false
(bool) "0" === true
(bool) (string) 0 === true
...

Actual result:
--------------
(bool) 0 === false
(bool) "0" === false
(bool) (string) 0 === false
...

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-05-12 21:18 UTC] girgias@php.net
-Status: Open +Status: Not a bug
 [2020-05-12 21:18 UTC] girgias@php.net 
This is documented behaviour, if you want a reason why this behaves like this imagine it being converted to an integer first and then converted to a boolean (because in effect a boolean is just an integer that is 0 for false and anything else for true).
 [2020-05-13 13:58 UTC] 6562680 at gmail dot com 
You know, guys, documentation is like exception - it is delayed uncoded solution for the problem.

Good application never thrown exception. But as one coder you cant hold in your mind all possible exceptions so you throw it for future fixing.

The community imagine "documentation" word like "we just write there is a bug and it is not a bug. we're done"
 [2020-05-13 14:00 UTC] 6562680 at gmail dot com 
Damn,

$var = '0';
empty($var); // true

Even there...
 [2020-05-13 15:05 UTC] bugreports at gmail dot com 
come on and fix your expectations given nobody but you expects "0" and 0 which is practically the same when it comes to type juggling evaluate to true

0/1 is the same as true/false, with or without you when it comes too lose types
 [2020-05-13 15:10 UTC] bugreports at gmail dot com 
> Damn,
>
> $var = '0';
> empty($var); // true

damn guess hwat - it's consistent

'0' == 0 == FALSE

nobody right in his mind expects anything else when it comes to https://www.php.net/manual/de/language.types.type-juggling.php and that you refuse to understand language basics by insist it's a bug is a hint that you should refrain from programming to be honest
 [2020-05-13 15:39 UTC] cmb@php.net 
The point is, that even if we wanted to change this, we can't for
backward compatibility reasons.

Thanks.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Dec 26 19:01:30 2024 UTC