This is an archive of the discontinued LLVM Phabricator instance.

[NFC][Clang] Fix static code analyzer concern about null value dereference
ClosedPublic

Authored by Manna on Aug 18 2023, 9:35 AM.

Details

Summary

CurLexer is dereferenced and should not be null in clang::​Preprocessor::​SkipExcludedConditionalBlock(clang::​SourceLocation, clang::​SourceLocation, bool, bool, clang::​SourceLocation)

This patch adds an assert for NULL value check of pointer CurLexer.

Diff Detail

Event Timeline

Manna created this revision.Aug 18 2023, 9:35 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptAug 18 2023, 9:35 AM
Manna requested review of this revision.Aug 18 2023, 9:35 AM
owenpan added inline comments.Aug 18 2023, 1:22 PM
clang/lib/Format/TokenAnnotator.cpp
2009–2010 ↗(On Diff #551552)

Current.Previous can't be null here because AutoFound is true.

tahonermann added inline comments.Aug 18 2023, 2:38 PM
clang/lib/Format/TokenAnnotator.cpp
2009–2010 ↗(On Diff #551552)

Could you please elaborate on why you believe it is safe to move the check of Current.Previous inside the body of the if statement? Doing so will short circuit the remaining else if cases such that Current.setType() will not be called at all. It isn't obvious to me that those cases should not be considered if the previous token was not one of kw_operator or identifier. This looks like it has potential to change behavior.

The change that was originally proposed is clearly safe.

owenpan added inline comments.Aug 18 2023, 5:29 PM
clang/lib/Format/TokenAnnotator.cpp
2009–2010 ↗(On Diff #551552)

Could you please elaborate on why you believe it is safe to move the check of Current.Previous inside the body of the if statement? Doing so will short circuit the remaining else if cases such that Current.setType() will not be called at all. It isn't obvious to me that those cases should not be considered if the previous token was not one of kw_operator or identifier. This looks like it has potential to change behavior.

Ahh, you are right.

The change that was originally proposed is clearly safe.

My point that Previous can't be null still stands. So we should either make no changes here or add an assertion just before the if statement at line 1991 above.

Manna updated this revision to Diff 552347.Aug 22 2023, 7:22 AM
Manna retitled this revision from [NFC][CLANG] Fix potential dereferencing of null return values to [NFC][Clang] Fix static code analyzer concern about null value dereference.
This comment was removed by Manna.
Manna edited the summary of this revision. (Show Details)Aug 22 2023, 7:23 AM
Manna added inline comments.Aug 22 2023, 7:26 AM
clang/lib/Format/TokenAnnotator.cpp
2009–2010 ↗(On Diff #551552)

Thank you @owenpan and @tahonermann for reviews and feedbacks, I have removed my previous change since Current.Previous can't be null here.

tahonermann requested changes to this revision.Aug 22 2023, 9:18 AM
tahonermann added inline comments.
clang/lib/Lex/PPDirectives.cpp
494–496

Perhaps it would make sense to assert CurLexer here as well.

557

I don't think this change is sufficient. If CurLexer is null, then the else branch will be entered and an unconditional dereference occurs there as well. It looks like more analysis is needed, but perhaps the correct fix is to add a non-null assertion somewhere above.

This revision now requires changes to proceed.Aug 22 2023, 9:18 AM
owenpan resigned from this revision.Aug 22 2023, 5:56 PM
Manna updated this revision to Diff 552706.Aug 23 2023, 7:31 AM
Manna edited the summary of this revision. (Show Details)
Manna marked an inline comment as done.Aug 23 2023, 7:34 AM
Manna added inline comments.
clang/lib/Lex/PPDirectives.cpp
557

Thank you @tahonermann for review and feedback. Yes, my analysis was wrong.

perhaps the correct fix is to add a non-null assertion somewhere above.

It sounds reasonable to me. I have added an assert above.

tahonermann requested changes to this revision.Aug 25 2023, 3:49 PM
tahonermann added inline comments.
clang/lib/Lex/PPDirectives.cpp
494–497

I would prefer that this assert be split up so that, when/if a failure occurs, we'll be able to tell which predicate failed.

This revision now requires changes to proceed.Aug 25 2023, 3:49 PM
Manna updated this revision to Diff 554762.Aug 30 2023, 9:52 AM
Manna marked an inline comment as done.

Thanks @tahonermann for review and feedback. I have added an assert separately to tell which predicate failed if a failure occurs in future.

Manna marked 2 inline comments as done.Aug 30 2023, 9:55 AM
tahonermann added inline comments.Aug 30 2023, 12:47 PM
clang/lib/Lex/PPDirectives.cpp
494–497

Would you mind splitting out all of the predicates? The updates to the messages in the suggested edit are intended to match the style present in other similar assertions.

Manna updated this revision to Diff 554810.Aug 30 2023, 12:55 PM

This patch splits all predicates and updates assert messages.

Manna marked an inline comment as done.Aug 30 2023, 12:56 PM
Manna added inline comments.
clang/lib/Lex/PPDirectives.cpp
494–497

Thanks @tahonermann for the suggestion. Done

tahonermann accepted this revision.Aug 30 2023, 1:00 PM

Thanks, Soumi, looks good to me!

This revision is now accepted and ready to land.Aug 30 2023, 1:00 PM
This revision was landed with ongoing or failed builds.Sep 5 2023, 12:49 PM
This revision was automatically updated to reflect the committed changes.
Manna marked an inline comment as done.
Manna added a comment.Sep 5 2023, 12:49 PM

Thanks, Soumi, looks good to me!

Thank you @tahonermann for reviews!