php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #81456 chr(48) is falsy
Submitted: 2021-09-18 05:26 UTC Modified: 2021-09-18 06:03 UTC
From: gib-o-master at mail dot ru Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 8.0.10 OS:
Private report: No CVE-ID: None
 [2021-09-18 05:26 UTC] gib-o-master at mail dot ru
Description:
------------
previous was marked as spam. this is a language problem, not spam.

Test script:
---------------
if (chr(48)) {
    echo 'never happen';
}

if (chr(0)) {
    echo 'always happen';
}

Expected result:
----------------
never happen
always happen

Actual result:
--------------
always happen

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-09-18 06:03 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2021-09-18 06:03 UTC] requinix@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php


 [2021-09-18 06:19 UTC] gib-o-master at mail dot ru
i doubt that '0' or chr(48) should be given special powers, it's not intuitive for JS/Python folks that rely on common behavior.


if ($string) {# '0' will not pass here
}

$x = $string ?: 'default';# '0' will not be selected as $x


if ([0]) {# will not look into array but string will
}
 [2021-09-19 01:49 UTC] a at b dot c dot de
chr(48) evaluates to the string "0". This is defined and documented as falsy and always has been; you're complaining about "giving" it "special powers" when what you're actually asking for is taking away properties that it has always had. It is something that PHP newbies are frequently surprised by and frequently complain about, but really turns out not to be a big deal if you pay attention to what you're doing.

This is also not JavaScript nor Python. Apologies if this means that programming in three languages means more mental work for you than programming in two.
 [2021-09-19 21:50 UTC] gib-o-master at mail dot ru
a at b dot c dot de,

im not sure you'll read this :]

1) look at my name, it states "master", so im not a newbie. a b c.

2) argument about '0' was always special, oke, i understand, let it stay special in older versions of language. the reason of complain is about dragging this little inconsistency into future, again [0] is not checked, '0' is checked, means different behavior/logic, array vs string, which are similar constructs, you can access $string[1] and you can access $array[1]. 

3) manual. ye, manuals may contain anything. let's make chr(0) special and drag it into manual, it's not JS and Python, right.
 [2021-09-26 05:14 UTC] gib-o-master at mail dot ru
$a = '0';
var_dump(empty($a));// true
 [2021-09-29 14:16 UTC] gib-o-master at mail dot ru
another inconvenience i encounter with '0' is when i need to check for mixed empty values returned (falsy checks)

function func(): string|array|int {...}

if (!($a = func()) # '0' will enter which is not intended
{...}

if (!($a = func()) && $a !== '0') # this is correct variant
{...}

so it's always have to be double checks if there is a string.
 [2021-10-07 02:40 UTC] a at b dot c dot de
1) Look, I did read it, oh Master of Gibs. Sounds like a DOOM fanatic.

2) Weigh that up against the impact the change would have on all current code.

3) The manual can say anything, but it's more useful if it's accurate.

Don't rip out something until you know why it's there in the first place. Find out the design principles behind _why_ 0 and "0" are both considered equal, empty, and cast to false.

Another inconvenience: sloppy return values makes for sloppy return value handling.


Regardless. This is not a bug. It is known documented and deliberate behaviour.
 [2021-11-09 16:03 UTC] gib-o-master at mail dot ru
a b c

1) yes, DOOM zandronum's very good, works well. i'm creating a revolver for it will be functional soon.

2) yes, the old php code could break apart. It won't run in php v.8 anyway, so that is not a problem, right? right. A lot of code/work to do in php, i agree, much easier to play around some "new" features, but refactoring is hard as a rock.

3) not much to reply, manual is manual, ok.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Nov 27 12:03:14 2021 UTC