This is an archive of the discontinued LLVM Phabricator instance.

[NFC][CLANG] Fix uninitialized scalar field issues
ClosedPublic

Authored by Manna on May 16 2023, 6:23 PM.

Diff Detail

Event Timeline

Manna created this revision.May 16 2023, 6:23 PM
Herald added a project: Restricted Project. · View Herald Transcript
Manna requested review of this revision.May 16 2023, 6:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 16 2023, 6:23 PM
Manna updated this revision to Diff 522877.May 16 2023, 7:00 PM
Manna abandoned this revision.May 17 2023, 4:11 AM
Manna updated this revision to Diff 523025.May 17 2023, 6:19 AM
Manna updated this revision to Diff 523030.May 17 2023, 6:24 AM
Manna retitled this revision from [NFC][CLANG] Fix uninitialized scalar field issues with Coverity to [NFC][CLANG] Fix uninitialized scalar field issues found by Coverity.May 17 2023, 7:06 AM
Manna added a reviewer: erichkeane.

Speaking of the StaticAnalyzer, I think setting some default value is a fair point, and I think it's a good practice.
In our case, we initialized that field from the registration function, like this:

void ento::registerMoveChecker(CheckerManager &mgr) {
  MoveChecker *chk = mgr.registerChecker<MoveChecker>();
  chk->setAggressiveness(
      mgr.getAnalyzerOptions().getCheckerStringOption(chk, "WarnOn"), mgr); // <--- initialized here
}
clang/lib/StaticAnalyzer/Checkers/MoveChecker.cpp
187

By looking at the default value of the Move.WarnOn checker option here, we should probably initialize this field to the default value matching the default value of the config.

Manna updated this revision to Diff 523071.May 17 2023, 8:57 AM

Thank you @steakhal for reviews. I have addressed review comment.

erichkeane accepted this revision.May 17 2023, 8:59 AM

CFE changes look fine to me!

This revision is now accepted and ready to land.May 17 2023, 8:59 AM
Manna added a comment.May 17 2023, 9:00 AM

In our case, we initialized that field from the registration function, like this:

void ento::registerMoveChecker(CheckerManager &mgr) {
  MoveChecker *chk = mgr.registerChecker<MoveChecker>();
  chk->setAggressiveness(
      mgr.getAnalyzerOptions().getCheckerStringOption(chk, "WarnOn"), mgr); // <--- initialized here
}

Yes, While investigating other Coverity bugs about uninitialized scaler fields in StaticAnalyzer, i noticed about the registration function.

Manna added a comment.May 17 2023, 9:01 AM

CFE changes look fine to me!

Thank you @erichkeane for reviews!

Manna marked an inline comment as done.May 17 2023, 9:05 AM
Manna added inline comments.
clang/lib/StaticAnalyzer/Checkers/MoveChecker.cpp
187
void setAggressiveness(StringRef Str, CheckerManager &Mgr) {
    Aggressiveness =
        llvm::StringSwitch<AggressivenessKind>(Str)
            .Case("KnownsOnly", AK_KnownsOnly)
            .Case("KnownsAndLocals", AK_KnownsAndLocals)
            .Case("All", AK_All)
            .Default(AK_Invalid);

    if (Aggressiveness == AK_Invalid)
      Mgr.reportInvalidCheckerOptionValue(this, "WarnOn",
          "either \"KnownsOnly\", \"KnownsAndLocals\" or \"All\" string value");

By looking at the codes above, my understanding was that default value is AK_Invalid. Thank you @steakhal for the pointer and the explanation.

Manna marked an inline comment as done.May 17 2023, 11:27 AM

@steakhal, do you have any more concerns with StaticAnalyzer changes?

steakhal accepted this revision.May 17 2023, 11:37 AM

I'm not opposed to these changes, but please note that these changes mean is will no longer be possible to use ubsan to discover when these data members are used before having been assigned an appropriate value. That is only a concern when an appropriate value would differ from the member initializers added via this change. I haven't reviewed the changes in depth, so I don't know if there are any such cases for which such a concern is applicable.

shafik added a subscriber: shafik.May 18 2023, 9:16 AM
shafik added inline comments.
clang/include/clang/Parse/Parser.h
1190

@tahonermann I feel like we should have a default member initializer for any member that by default is not initialized. I realize in this case there currently should be no way for this to be bot initialized but that may not stay true and I don't believe there will be a penalty for doing this since it is initialized in the mem-initializer-list and therefore the default init should be omitted when calling the constructor.

tahonermann added inline comments.May 18 2023, 11:01 AM
clang/include/clang/Parse/Parser.h
1190

I think that is very reasonable and I'm not opposed to such a policy. Per my other comment, the trade off to always initializing is that a default initializer can prevent use of tools like ubsan to discover when an appropriate (presumably non-default) value has not been assigned. I suspect (but have no data to draw on) that adding a default member initializer prevents more bugs than would be found by tools like ubsan detecting use of an uninitialized data member that should have a (non-default) assigned value.

I'm definitely in favor of using default member initializers over mem-initializer-list!

Manna added inline comments.May 19 2023, 12:06 PM
clang/include/clang/Parse/Parser.h
1190

since it is initialized in the mem-initializer-list and therefore the default init should be omitted when calling the constructor.

Agreed. That is motivated me to add default initialization.

he trade off to always initializing is that a default initializer can prevent use of tools like ubsan to discover when an appropriate (presumably non-default) value has not been assigned. I suspect (but have no data to draw on) that adding a default member initializer prevents more bugs than would be found by tools like ubsan detecting use of an uninitialized data member that should have a (non-default) assigned value.

Thanks @tahonermann for the information! i was not aware of this ubsan tool.

@shafik and @tahonermann, thank you for your comments. Do you think we should hold off these changes for merging?

Manna retitled this revision from [NFC][CLANG] Fix uninitialized scalar field issues found by Coverity to [NFC][CLANG] Fix uninitialized scalar field issues.May 25 2023, 12:01 PM

@tahonermann @shafik - is it ok to land this patch?

tahonermann accepted this revision.Jun 22 2023, 10:37 AM

is it ok to land this patch?

No objection from me!

This revision was automatically updated to reflect the committed changes.

Thank you everyone for reviews!