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.

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

ppci-cc: switch/case statements should be better tested in the front-end #111

Open
tstreiff opened this issue Jul 12, 2020 · 1 comment
Open

Comments

@tstreiff
Copy link
Contributor

All switch/case contraints are not tested by the front-end, and this makes the code generator crash or generate wrong code:

  • the switch expression must be of integer type (including enum types) (floats are currently possible and the error report when using struct/union is not clear)
  • a default statement must not occur several times in a switch (this is currently possible)
  • integer promotion should be done on the switch expression (this means that we should compare at least ints), and the case constants should be coerced to the promotion type (the comparison is currently made with the size of the switch type)

Side remarks
The compiler ensures that no case value is duplicated, but this is done in the IR code generator, it seems more logical to do this during the semantics checking.

In nodes/types.py some type predicates are a bit confusing because they do not follow the C standards:

  • scalar: in the C standard, pointers are scalar types, whereas type predicate is_scalar returns False for pointers.
  • integer: in the C standard, enumerated types are integer types (they are just integer types with a list of named constants), whereas type predicate is_integer returns False for enum types.
    Predicates such as complete/incomplete should be declared in CType and returns False by default, it would simplify the front-end code.
@tstreiff
Copy link
Contributor Author

I am writing a fix for this issue.

I am fighting with the notion of "constant expression" (which appears at several places in the C grammar).
It looks as if "parse_constant_expression()" does not ensure that the expression is really constant and it returns the found expression unchanged. I haven't found any easy way to compute the value of an expression such as 2+3 or even -1 in the parsing/semantics pass.
Did I miss something obvious?

tstreiff added a commit to tstreiff/ppci-mirror that referenced this issue Jul 21, 2020
… that the switch expression is of integer type and apply integer promotion on it. Ensure default statements is not used twice for a given switch. Ensure case values (or ranges for the GCC extension) are integer constants, and that no case value or range is in conflict with the preceding cases of the same switch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant