#2069 [PATCH] LexCPP: fix bug in arithmetic calculation

[Jannick]

Hi,

this is a bug fix for LexCPP (Scintially 4.1.2): The attached patch introduces precedence levels for arithmetic calculations. Examples fixed by the patch included in the patch documentation.

[Neil Hodgson]

According to https://en.cppreference.com/w/c/language/operator_precedence, there are only two precedence levels here : "*/%" and "+-", so "%" should be included in setMultOp and setBinaryOp removed.

The change to string conversion appears unrelated so should be a separate patch.

[Jannick]

Attached the patch as requested.

Some comments:

• Could you please point to the reference that C operator precedences are relevant for preprocessor expression evaluation? I checked some examples with gcc's CPP and it appears to be right.
• Would it be appropriate to check integer limits during the expression evaluation process?
• To be implemented are remaining arithmetic operators (like left/right shifts).

[Neil Hodgson]

Could you please point to the reference that C operator precedences are relevant for preprocessor expression evaluation?

I only have a pre-release of the C11 standard. 6.10.1.4 (Conditional inclusion) says

The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6.

6.6.11 (Constant expressions) says

The semantic rules for the evaluation of a constant expression are the same as for nonconstant expressions.

In the standard section 6.5 (Expressions) there is no precedence table. Different expressions like multiplicative-expression and additive-expression are used to indicate precedence as syntax.

Would it be appropriate to check integer limits during the expression evaluation process?

Its possible but it would probably have to be done according to the machine on which the compiler will run or maybe the destination machine, not the machine on which editing is being performed.

[Jannick]

Many thanks for pulling this together. This is a good foundation for the patch.

Integer limit check:

• What about a check if macros like INT_MAX are (pre-)defined (cf. N1570, 6.10.1.4, footnote 167)? In case the constant exceeds the limits, it would be set to the default 0.
• Then compile time limit macros could be pushed into the lexer and/or they are defined in the file. However, I am not sure if this push feature exists already for LexCPP. Does it?

Thanks for pushing the patches, too.

[Neil Hodgson]

It would be more likely for code to have explicit checks against limits rather than rely on implicit numeric failures. Do you have examples where code relies on limited precision?

Macros are set up in preprocessorDefinitionsStart through the 5th keyword list.

[Jannick]

Actually, I have seen that somewhere, but I cannot recall from the top of my head where that was, unfortunately.

I'll have a look at preprocessorDefinitionsStart. Thanks for hint.

From my side this ticket could be closed.

[Neil Hodgson]

Committed as [48861f], [bff457].