Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more rules on preprocessor expressions and their types #16

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+16 −7
Open

Add more rules on preprocessor expressions and their types #16

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 16 additions & 7 deletions drafts/25-revise-24-177 Fortran preprocessor requirements.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,13 +58,22 @@ from C and Fortran syntax in the following ways:
7. FPP recognizes /* ... */ C-style comments on directive lines.
8. Expressions in #if and #elif directives contain constructs from
both Fortran and CPP.
9. Expressions in #if and #elif directives that evaluate to LOGICAL
or INTEGER values. .TRUE. or a non-zero integer are considered
true.
10. Undefined identifiers are treated as zero, as in CPP.
11. Integer expressions in preprocessor directives are calculated in
the maximum precision the processor supports. (There are no KIND
specifiers on integer constants in the preprocessor.)
9. Expressions in #if and #elif directives evaluate to INTEGER values.
Zero values are treated as 'false'. Non-zero values are treated as
'true'.
Comment on lines +61 to +63
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When it comes time to actually write spec wording for this, it's not enough to say the expression "evaluate to INTEGER values". There must be additional constraints to rule out (for example) character strings in preprocessor conditional expressions.

For now it might be sufficient to say something like

Suggested change
9. Expressions in #if and #elif directives evaluate to INTEGER values.
Zero values are treated as 'false'. Non-zero values are treated as
'true'.
9. Expressions in #if and #elif directives must be integer constant expressions as in CPP
(with the extensions described below), and evaluate to INTEGER values.
As in CPP, zero values are treated as 'false'. Non-zero values are treated as
'true'.

10 .FALSE. is treated as the integer 0. .TRUE. is treated as the
integer 1.
Comment on lines +64 to +65
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about .false. and .true.?

11. Undefined identifiers are treated as zero, as in CPP.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor clarification, inspired by C spec wording:

Suggested change
11. Undefined identifiers are treated as zero, as in CPP.
11. Any undefined identifiers that remain after macro expansion (including those
lexically identical to keywords or intrinsics) are treated as zero, as in CPP.

12. C character constants (such as 'A', '\n') are treated as
integer values, as they are in C.
Comment on lines +67 to +68
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This run-on list of rules needs to be restructured to clarify that the rule above (and possibly others?) only apply to the conditional expression in #if/#elif. For example this does not impact macro expansion in source.

13. The Fortran operators .AND., .OR., ,NOT., .EQ., .NE., .EQV., and
.NEQV. calculate the save values as the C operators &&, ||, !, ==,
!=, ==, and !=, respectively.
Comment on lines +69 to +71
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you're assuming we also accept the suggestion in issue #13 to add these additional Fortran operators to the draft. If we were to merge this PR alone as-is, these new rules would be inconsistent with the earlier list of operators.

This PR purports to address only #14 (which IMO has a strong stand-alone motivation), and I'd like to keep it focused on that proposal without conflating the orthogonal issue #13 (where the motivation may be seen as potentially weaker).

Please decouple these two PRs. I suggest removing the "new" operators above and getting this PR into a mergeable state to address solely #14, and then PR #15 can later introduce the obvious extension for the operators proposed by #13.

Suggested change
13. The Fortran operators .AND., .OR., ,NOT., .EQ., .NE., .EQV., and
.NEQV. calculate the save values as the C operators &&, ||, !, ==,
!=, ==, and !=, respectively.
13. The Fortran operators .AND., .OR., ,NOT., =, /= evaluate to the same values as
the C operators &&, ||, !, ==, and !=, respectively.

14. The Fortran operators .LT., .LE., .GT., and .GE. calculate the
same values as the C operators <, <=, >, and >=, respectively.
Comment on lines +72 to +73
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here, please move this new rule to PR #15

Suggested change
14. The Fortran operators .LT., .LE., .GT., and .GE. calculate the
same values as the C operators <, <=, >, and >=, respectively.

15. Integer expressions in preprocessor directives are calculated in
the maximum precision the processor supports. (There are no KIND
specifiers on integer constants in the preprocessor.)
Comment on lines +74 to +76
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like it should be two separate rules. IIUC the parenthetical is actually prohibiting certain syntax, so it should not be parenthetical.



3. FPP Phase 1: Line conjoining
Expand Down