Bug 485 - operator precedence is inconsistent with C++
Summary: operator precedence is inconsistent with C++
Status: RESOLVED FIXED
Alias: None
Product: UPPAAL
Classification: Unclassified
Component: libutap (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Assignee: Alexandre David
URL:
Depends on:
Blocks:
 
Reported: 2010-03-26 10:11 CET by Marius Mikučionis
Modified: 2010-05-25 17:03 CEST (History)
0 users

See Also:
Architecture:


Attachments
model for testing some operator precedence (3.20 KB, text/xml)
2010-03-26 12:46 CET, Marius Mikučionis
Details
queries for testing some operator precedence (both modeling and properties) (409 bytes, application/octet-stream)
2010-03-26 12:47 CET, Marius Mikučionis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marius Mikučionis 2010-03-26 10:11:30 CET
I take this page as C++ reference:
http://www.cppreference.com/wiki/operator_precedence

In particular the problem is with operator "not" (also "and" and "or") which has very low precedence in Uppaal (see Help and UTAP library source).

For example the following expressions evaluates differently in Uppaal than in C++:
"not(true) && false" is true in Uppaal and false in C++.
The same holds for "not true && false".

We propose to change the precedence of "not" to be the same as "!".
Similarly "and" should have precedence the same as "&&" and "or" like "||".

Also bitwise not "~" would be nice to include for the sake of completeness.
Comment 1 Marius Mikučionis 2010-03-26 12:46:02 CET
Created attachment 230 [details]
model for testing some operator precedence

model for testing some operator precedence
Comment 2 Marius Mikučionis 2010-03-26 12:47:06 CET
Created attachment 231 [details]
queries for testing some operator precedence (both modeling and properties)
Comment 3 Marius Mikučionis 2010-03-26 12:55:18 CET
Fixed precedence of "not", "and" and "or" on trunk in revision 4508.
I suspect there will be more issues, in particular with pre-increment and post-increment (they are treated differently in C++), but I don't see any difference between them in the parser.
Also cannot think of an example for now...

The bitwise not "~" is possible but it creates a mess with ranges and how many bits are used to encode a particular variable, thus it is not going to be implemented. Better use bitwise xor with explicit number of bits.
Comment 4 Alexandre David 2010-05-25 17:03:06 CEST
The fix looks reasonable :).
We can have bit inversion but we would need to check that the range is compatible with the operation, basically lower == -(upper+1).