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 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: 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 May 09 14:01:27 2025 UTC