php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #22736 change of operator precedence
Submitted: 2003-03-16 07:28 UTC Modified: 2003-03-17 08:44 UTC
From: soletan at toxa dot de Assigned:
Status: Not a bug Package: Feature/Change Request
PHP Version: 4.3.0 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: soletan at toxa dot de
New email:
PHP Version: OS:

 

 [2003-03-16 07:28 UTC] soletan at toxa dot de
Hi,

maybe this can't be done because of scripts relying on current operator precedence, but for the statement

$a & ~$b != 0

your current precedence rules would do

$a & ~( $b != 0 )

which is quite unusual. Traditional logics (used by Frege and others) would first compute the negation, it is the most strongly bound operator. For instance, having 

~p ^ q 

as a structured expression the negation would precede any other operator p is argument of, or: p is not argument of the conjunction, but the negation's result is.


Maybe I'm still false, but that's what I have expected to write logical calculations like for years.


Best Regards,
Thomas Urban

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-17 08:11 UTC] mgf@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

I think your precedence information seems to be a little awry.  According to the manual page at http://www.php.net/manual/en/language.operators.php, ~ has greater priority than != has greater priority than &, ^, | (in that order).  This means that your example of

   $a & ~$b != 0

actually equates to
  
   $a & ((~$b) != 0)

(and I've just tested this, so I'm sure it's right.)  This isn't nearly as bad as you suggest (but, I agree, a little unexpected -- until I checked, I'd have expected &, ^, | to be higher-precedence than ==, != etc!).

So, your example of ~p ^ q *will* be evaluated as (~p) ^ q, and, indeed, any expression containing solely bitwise operators will function as expected -- only if you add comparison operators into the mix will you have to be careful to add parentheses to get the required result.

 [2003-03-17 08:44 UTC] soletan at toxa dot de
Sorry, I thought it would be some change request and you offer that category here at "bug reporting". What is it for, else?

But okay, I read the table false way before, and more carefully this time ... I still encounter some problem in using logical equations like that one ... and apparently it's not because of negation but arithmetic conjunction, which is lower than comparison operators in precedence ranking. That's maybe what I think of being quite unusual, because it's hard to me to find some practical example where the result of comparison might be used as an argument to arithmetic conjunction, while I often use the latter one to mask out bits from an integer AND THEN compare it to some fixed value or similar.

01110111110101101011b & 00000111111100000 != 0


Best regards and sorry, if this is still false to the bug reporting system, so I would shut up further on and handle this unhandy malfunction myself.
Thomas Urban
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon May 20 18:01:36 2024 UTC