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

Frontc.parse_standalone_exp doesn't handle typedef-s #159

Open
sim642 opened this issue Nov 23, 2023 · 1 comment
Open

Frontc.parse_standalone_exp doesn't handle typedef-s #159

sim642 opened this issue Nov 23, 2023 · 1 comment

Comments

@sim642
Copy link
Member

sim642 commented Nov 23, 2023

PR #97 exposed this functionality for Goblint to parse invariant expressions from witnesses:

cil/src/frontc/frontc.ml

Lines 273 to 282 in c7ffc37

let parse_standalone_exp s =
try
if !E.verboseFlag then ignore (E.log "Frontc is parsing string: %s\n" s);
flush !E.logChannel;
(* if !E.verboseFlag then ignore @@ Parsing.set_trace true; *)
let lexbuf = Clexer.initFromString s in
let (cabs, _) = Stats.time "parse" (Cparser.expression (Whitetrack.wraplexer clexer)) lexbuf in
Whitetrack.setFinalWhite (Clexer.get_white ());
Clexer.finish ();
cabs

This produces a parsing error when the expression contains a cast to a typedef-ed type. It is because of the ✨lexer hack✨ which makes the lexer stateful, even though parse_standalone_exp just seems to take a string and parse it to Cabs. Currently only the Cabs2cil process for such standalone expression requires some environment information (e.g. global variables, various type declarations) as argument.

However, due to the lexer hack, lexing of an identifier depends on knowing whether it is a variable name or a type name. Since parse_standalone_exp doesn't do anything about it, the lexer hack table isn't appropriately initialized and the lexer assumes everything to be a variable name. But variable names are not valid syntax in the cast type.

I'm not sure if we can really do anything about this because the lexer hack is a mutable hashtable during the parsing process. We have no way of restoring the state of this hashtable for any location required for invariant parsing. Unless the mutable hashtable is replaced with some persistent data structure that efficiently records the lexer hack table for all program points and allows us to time/location travel within it.
This is surprisingly complex and I'm not sure how, if at all, anyone else in SV-COMP manages to do this correctly.

@michael-schwarz
Copy link
Member

At least for our own witnesses, we can remidy this to some extent by fullying unrolling all type expressions in casts when we generate them.

sim642 added a commit to goblint/analyzer that referenced this issue Mar 1, 2024
We have problems parsing them for validation: goblint/cil#159.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants