Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upEvaluating macro expression in unsafe block #3738
Comments
phansch
added
the
L-lint
label
Feb 6, 2019
This comment has been minimized.
This comment has been minimized.
|
Oh wow. That's not even a footgun that's a whole footnuke. Unfortunately I think we can only detect the problem in expansions of the macro, not in the macro definition itself. Impl instructions for a lint detecting the issue in an expansion:
A better fix would probably be making the compiler to undo the unsafety when leaving the current macro. So the |
oli-obk
added
the
A-correctness
label
Feb 11, 2019
This comment has been minimized.
This comment has been minimized.
|
Thanks for your reply! After some more thought, I agree that it would be preferable for the compiler itself to prevent this behavior from occurring, so I've created a post on the Rust internals forum to encourage discussion there. If a Clippy lint is produced for this issue, one false positive to watch out for would be if the expression is used as a compile time constant, for example the following evaluation of
|
chertl commentedFeb 4, 2019
Requesting a Clippy lint for evaluating macro expressions in an
unsafeblock, such as the following:This is bad code hygiene because although the above may not look dangerous on its own, it can be used to hide
unsafecode in another function. For example, the following program produces an out of bounds read, despite not appearing to contain anyunsafeblocks: