Bug: Ultimate C translation fails to handle static asserts in global scope
The current C translation fails to handle static asserts in the global scope of the code (outside of the program's control flow). This issue can be reproduced with the latest version of Ultimate Automizer (0.3.0-dev-cdb3e27 with OpenJDK 21.0.6) using the following input:
//#SAFE
_Static_assert(1, "STATIC_ASSERT_IS_NOT_WORKING");
int main(void)
{
return 0;
}
When verifying the example program, Ultimate reports the following syntax error:
- SyntaxErrorResult [Line: 3]: Incorrect Syntax
Syntax error (declaration problem) in C program: Syntax error (_Static_assert(1, "STATIC_ASSERT_IS_NOT_WORKING");)
The error message indicates a declaration problem. However, this is incorrect. The issue is neither a declaration problem nor a syntax error.
The error message indicates a declaration problem. However, this is incorrect. The issue is neither a declaration problem nor a syntax error.
Yes and no 😆
_Static_assert(1, "STATIC_ASSERT_IS_NOT_WORKING"); is of course not a declaration, but a macro-"call". The problem is that our parser tries to parse this a declaration and crashes while doing so and thus produces an IASTProblemDeclaration.
We could only try to add some kind of workaround when dispatching such a IASTProblemDeclaration (see here).
Maybe this is a use case where we would have to actually tell the CDT parser that this is a macro, rather than implicitly relying on it being parsed as function call or, in this case, declaration? If we do that, it should be parsed correctly, right? Though I don't know yet how the macro should be replaced 🤔
Though I don't know yet how the macro should be replaced
Maybe by int __dummy = { assert(condition, message); return 0; }; ie initializing a fresh dummy variable to a statement expression? 😁
Though I don't know yet how the macro should be replaced
Maybe by
int __dummy = { assert(condition, message); return 0; };ie initializing a fresh dummy variable to a statement expression? 😁
Yes, that should work indeed -- but creating a variable seems a bit dangerous (possible name-clash / backtranslation)... 😆