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

go to bug id or search bugs for

Bug #75980 greater or equal (formerly >=) is missinterpreted
Submitted: 2018-02-19 12:13 UTC Modified: 2018-02-19 13:22 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: rolf at rolfjentsch dot de Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: 7.2.2 OS: windows 10 xamp
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: rolf at rolfjentsch dot de
New email:
PHP Version: OS:

 

 [2018-02-19 12:13 UTC] rolf at rolfjentsch dot de 
Description:
------------
Problem arrises when >= is processed something like "= 0) { $where="http://qnap/piwik/"; }" is echoed  instead of doing what it did in php 5.6

Below is a test script to reproduce the error

Test script:
---------------
<?
if (isset($_SERVER['SERVER_ADDR'])) 
{
	if (strpos($_SERVER['SERVER_ADDR'],"192.168.10") >= 0)
	{
		$where="http://qnap/piwik/";
	}
	else
	{
		$where="https://someurlhere/";
	} 
} else $where="https://someurlhere/";
?>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-02-19 12:18 UTC] peehaa@php.net
-Status: Open +Status: Feedback
 [2018-02-19 12:18 UTC] peehaa@php.net 
It's not clear at all what this bug report is trying to... report.

Please provide clear information regarding the expected output, the actual output and a proper test case.
 [2018-02-19 12:41 UTC] rolf at rolfjentsch dot de
-Summary: greater or equal formerly >= is missinterpreted +Summary: greater or equal (formerly >=) is missinterpreted -Status: Feedback +Status: Open
 [2018-02-19 12:41 UTC] rolf at rolfjentsch dot de 
Processing a .php document is done wrong imho.

When a statement like "if (strpos($_SERVER['SERVER_ADDR'],"192.168.10") >= 0)"
is proccessed it does not compare but finishes to interpret (which would be fine if there is a "?>") but the compare option ">=" finishes interpretation of the source and echoes in the above example "= 0)"

This appplies to all php 7 versions i have tested so far either on ubuntu or on xammp.
 [2018-02-19 12:43 UTC] spam2 at rhsoft dot net 
it would be a good start to write proper code and then it even works

>= 0 when comparing the boolean 'false' triggers implict type-casting and false weak compared to 0  is the same as int 0 when the string starts with needle

that this worked in some arbitary PHP version was just by luck

- if(strpos($_SERVER['SERVER_ADDR'],"192.168.10") >= 0)
+ if(strpos($_SERVER['SERVER_ADDR'],"192.168.10") !== false)
 [2018-02-19 12:54 UTC] rolf at rolfjentsch dot de 
Formerly versions of php (like 5.6) made it possible to have a <? ?> or <?php ?> anywhere in the source document. 
Now with php 7 (actually tested on 7.2.2) a normal if statement with a ">=" compare opertor finishes interpreting php. (As it would be expected when i had written "?>" )
On top - dont know if related to the above a function defined inside the <html> <body> tag is not recognized as defined. 

aamof i defined a function there definetly before its first usage and it does not work. moving it before the <html> <body> tag solves the problem
 [2018-02-19 13:00 UTC] spam2 at rhsoft dot net 
> made it possible to have a <? ?> or <?php ?> anywhere in the source document

frankly you mix completly different topics to start with
<? ?> aka short-open-tags should not be used for many years
<?=?> got an exception indepdendent if short-open is allowed in config


> a normal if statement with a ">=" compare opertor finishes interpreting php

THIS IS NOT TRUE - PERIOD - otherwise the sample with you broken code won't reach the echo statement at all and when you replace ">= 0" with a proper !== false it even works as intended

[harry@srv-rhsoft:/downloads]$ php test.php
http://qnap/piwik/

[harry@srv-rhsoft:/downloads]$ cat test.php
<?php
$_SERVER['SERVER_ADDR'] = '192.168.196.0';
if (isset($_SERVER['SERVER_ADDR']))
{
        if (strpos($_SERVER['SERVER_ADDR'],"192.168.10") >= 0)
        {
                $where="http://qnap/piwik/";
        }
        else
        {
                $where="https://someurlhere/";
        }
} else $where="https://someurlhere/";
echo $where, "\n";
 [2018-02-19 13:01 UTC] rolf at rolfjentsch dot de 
Thank you for your hint with 

- if(strpos($_SERVER['SERVER_ADDR'],"192.168.10") >= 0)
+ if(strpos($_SERVER['SERVER_ADDR'],"192.168.10") !== false)

But a  if(strpos($_SERVER['SERVER_ADDR'],"192.168.10") !< 0) still does what it does in previous versions

Wbr Rolf Jentsch
 [2018-02-19 13:11 UTC] spam2 at rhsoft dot net 
so what is now with your wrong statement that >= finish interpreting?

> But a  if(strpos($_SERVER['SERVER_ADDR'],"192.168.10") !< 0) 
> still does what it does in previous versions

frankly i have no idea why one would write this code and what it is supposed to do!

strpos() either returns a integer which can be anything including 0 where 0 is the pretty clear fact "haystack starts with needle"

in case needle don't exist in the string it returns a boolean false which is ducmented behavior for decades - so the only correct code tests if the result is  a boolean false and this MUST be done with !== or === depending on the logic you implement 

compare return values which can be 0 or boolean in weak mode is and always was wrong - that's it - when your code for comparison is not strict PHP needs to implicit cast *one* of both values to the type of the other which makes a 0 to false or false to 0 depending on the order and so the result is just by luck

that's it - that didn't change

and completly off-topic assertions like >= stops interpreting making such bugreports even more worse - there is no bug, your expectations are just wrong and with reading the documentation you would not have written >= to start with

http://php.net/manual/en/function.strpos.php
Warning

This function may return Boolean FALSE, but may also return a non-Boolean value which evaluates to FALSE. Please read the section on Booleans for more information. Use the === operator for testing the return value of this function.
 [2018-02-19 13:17 UTC] rolf at rolfjentsch dot de 
well to make it a final 
the problem only arrises when i start my php section with <?.
it does not occur when i start it with <?php
 [2018-02-19 13:18 UTC] jhdxr@php.net
-Status: Open +Status: Not a bug
 [2018-02-19 13:18 UTC] jhdxr@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

> But a  if(strpos($_SERVER['SERVER_ADDR'],"192.168.10") !< 0) still does what it does in previous versions

`!<` is an invalid operator in PHP, please double check the manual (http://php.net/manual/en/language.operators.php) before you try to create something.

btw, rhsoft has already point out that you should read the manual to see how `strpos` works, especially the warning message in red box.
 [2018-02-19 13:18 UTC] nikic@php.net 
Please check your "short_open_tag" ini setting. You have it enabled on PHP 5 and disabled on PHP 7.
 [2018-02-19 13:22 UTC] spam2 at rhsoft dot net 
> well to make it a final the problem only arrises when i 
> start my php section with <?.
> it does not occur when i start it with <?php

well, to make it final: that's why you should not mix different issues in one bugreport and hence your broken snippet has alos no place in https://bugs.php.net/bug.php?id=73232

http://php.net/manual/en/ini.core.php#ini.short-open-tag

<? is short-open-tags which defaults for years now to disabled
that it worked in some configuration with 5.6 was because someone enabled it

you can build PHP7 with --disable-short-tags and that's what you see because you ignored that many years that you shold write <?php and not <?

but as said: this "issue" which is none has no place in that bugreport which is about something cmpletly differnt at all
 [2018-02-19 13:22 UTC] cmb@php.net 
Besides what nikic said: if you're experiencing such strange
behavior again, have a look at the generated HTML source code!
 [2018-02-19 13:38 UTC] rolf at rolfjentsch dot de 
The german documentation does not say that <? is deprecated or should not be used see http://php.net/manual/de/language.basic-syntax.phptags.php. May be that page should be updated ... 
beside that my provider has it enabled and so i enabled the short tags on my development server as well.

So i can only thank you for your advice.
 [2018-02-19 13:45 UTC] spam2 at rhsoft dot net 
> The german documentation does not say that <? is deprecated

it's widely known for around 10 years that you shouldn't rely on this mis-feature

you initial problem with the statement ">= finish interpreting" was that you where not capable to realize that PHP don't get executed at all and the whole source was sent to the client

https://softwareengineering.stackexchange.com/questions/151661/is-it-bad-practice-to-use-tag-in-php
 [2018-02-19 13:49 UTC] spam2 at rhsoft dot net 
> The german documentation does not say that <? is deprecated

this is NOT true, it clearly states that you should not rely on syntax which can be disabled with a single switch in the config and for me that was clear as i started with PHP 4.0.6 that it's dumb when i write code which may not run on a different setup at all 

http://php.net/manual/de/language.basic-syntax.phptags.php

PHP erlaubt ebenfalls kurze öffnende Tags <? (von denen abgeraten wird, da sie nur verfügbar sind, wenn sie durch die short_open_tag php.ini Konfigurationsdirektive aktiviert wurden, oder PHP mit der --enable-short-tags Option konfiguriert wurde).
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Mar 14 15:01:30 2025 UTC