Now
MAIN commitmail json YAML
src/tests/usr.bin/xlint/lint1/d_gcc_compound_statements2.c@1.5
/
diff
/
nxr@1.5
src/tests/usr.bin/xlint/lint1/t_integration.sh@1.75 / diff / nxr@1.75
src/usr.bin/xlint/lint1/cgram.y@1.381 / diff / nxr@1.381
src/usr.bin/xlint/lint1/externs1.h@1.146 / diff / nxr@1.146
src/usr.bin/xlint/lint1/tree.c@1.404 / diff / nxr@1.404
src/tests/usr.bin/xlint/lint1/t_integration.sh@1.75 / diff / nxr@1.75
src/usr.bin/xlint/lint1/cgram.y@1.381 / diff / nxr@1.381
src/usr.bin/xlint/lint1/externs1.h@1.146 / diff / nxr@1.146
src/usr.bin/xlint/lint1/tree.c@1.404 / diff / nxr@1.404
lint: fix memory corruption in statement expressions (since 2021-12-17)
The commit that introduced the assertion failure looks innocent, it only
adds a few predefined functions for GCC mode. Nevertheless, before that
commit, lint consistently complained about 'error: void type illegal in
expression [109]', which doesn't make sense either.
This fix also removes the creative use of the initialization stack to
store the type of the statement expression. Having a separate stack for
these statement expressions makes the code easier to understand.
The commit that introduced the assertion failure looks innocent, it only
adds a few predefined functions for GCC mode. Nevertheless, before that
commit, lint consistently complained about 'error: void type illegal in
expression [109]', which doesn't make sense either.
This fix also removes the creative use of the initialization stack to
store the type of the statement expression. Having a separate stack for
these statement expressions makes the code easier to understand.