-
-
Notifications
You must be signed in to change notification settings - Fork 21.6k
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
Added/Fixed null pointer checks #10591
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -215,8 +215,8 @@ void TextEdit::Text::_update_line_cache(int p_line) const { | |
|
||
const Map<int, TextEdit::Text::ColorRegionInfo> &TextEdit::Text::get_color_region_info(int p_line) { | ||
|
||
Map<int, ColorRegionInfo> *cri = NULL; | ||
ERR_FAIL_INDEX_V(p_line, text.size(), *cri); //enjoy your crash | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure if just removing the debugging warning here is a good idea. In release mode this crash already doesn't exist. Maybe find out what's at the other end of this and return a value that won't crash? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Or maybe make it a fatal error rather than a warning. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that by removing the explicit handling, the container implementation will crash (on purpose) on index-out-of-bounds. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wouldn't it be better to crash here though, for debugging purposes? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think it matters whether it crashes here or not. The backtrace will still point us to the right line. You can try putting this in, say, the String text;
text[20]; // crashes here This is the
And the backtrace you will get:
It's obvious what's happening just from that, which is why I think those two lines are unnecessary. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the idea is that for the end user, it's better to have the error message induced by There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll check how Godot behaves when those lines get executed in a Clang build then and see if I can get both builds to behave the same way while keeping the messages visible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Changing the for loop to: for (int i = -2000; i < cursor.line_ofs + 2000; i++) { to trigger But passing a static map keeps both builds from crashing: static Map<int, ColorRegionInfo> cri;
ERR_FAIL_INDEX_V(p_line, text.size(), cri); //no more crashes on either builds |
||
static Map<int, ColorRegionInfo> cri; | ||
ERR_FAIL_INDEX_V(p_line, text.size(), cri); | ||
|
||
if (text[p_line].width_cache == -1) { | ||
_update_line_cache(p_line); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching this! I'll go through the diff again and make sure I didn't make this mistake elsewhere (I apparently saw Ref and decided I needed to dereference, whoops)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anytime! You did fix a lot of issues in your pull request.
For what it's worth, I did a quick
egrep
to catch another line like that:but nothing showed up. I think the rest is good.