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

[IR] Dereference nullptr #3573

Open
sjwsl opened this issue Nov 21, 2021 · 0 comments
Open

[IR] Dereference nullptr #3573

sjwsl opened this issue Nov 21, 2021 · 0 comments
Assignees
Labels
potential bug Something that looks like a bug but not yet confirmed welcome contribution

Comments

@sjwsl
Copy link
Contributor

sjwsl commented Nov 21, 2021

Using nullptr as a parameter here will cause the dereference of nullptr later, which is an undefined behavior.

ctx->push_back<SNodeOpStmt>(SNodeOpType::is_active, snode, ptr, nullptr);
} else if (op_type == SNodeOpType::length) {
ctx->push_back<SNodeOpStmt>(SNodeOpType::length, snode, ptr, nullptr);
} else if (op_type == SNodeOpType::get_addr) {
ctx->push_back<SNodeOpStmt>(SNodeOpType::get_addr, snode, ptr, nullptr);

This is one of the dereferences, which is the root cause of #3323.
if (auto atomic = op->cast<AtomicOpStmt>()) {

Just to fix this one is easy, but there may (very likely) be similar errors elsewhere not found. I think either we need something like NullStmt to completely avoid nullptr for Stmt*, or check it before each dereference (which is much more verbose).

@sjwsl sjwsl added the potential bug Something that looks like a bug but not yet confirmed label Nov 21, 2021
@sjwsl sjwsl self-assigned this Nov 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
potential bug Something that looks like a bug but not yet confirmed welcome contribution
Projects
None yet
Development

No branches or pull requests

2 participants