PVS-StudioでClang11をチェックする

時々、コンパイラの次のバージョンのチェックに関する記事を書かなければなりません。面白くないです。ただし、実践が示すように、これが長期間行われない場合、人々はPVS-Studioアナライザーがバグや潜在的な脆弱性の優れたキャッチャーの称号に値するかどうか疑問に思い始めます。おそらく、新しいコンパイラはすでにこれを行う方法を知っていますか？はい、コンパイラは静止していません。ただし、PVS-Studioも開発中であり、コンパイラなどの高品質プロジェクトのコードでもエラーを検出できることを何度も示しています。

Clangコードを再確認する時間

正直なところ、このテキストの基礎として、「PVS-Studioを使用したGCC10コンパイラのチェック」という記事を取り上げました。したがって、すでにどこかでいくつかの段落を読んだように思われる場合は、そうは思わないでしょう:)。



コンパイラーに独自の静的コードアナライザーが組み込まれていることは周知の事実であり、それらも開発されています。したがって、PVS-Studio静的アナライザーがコンパイラー内でもエラーを検出する方法と、何もせずにパンを食べていないことについての記事を時々書いています:)。



実際、従来の静的アナライザーをコンパイラーと比較することはできません。静的アナライザーは、コード内のエラーを見つけるだけでなく、開発されたインフラストラクチャーでもあります。たとえば、これはSonarQube、PlatformIO、Azure DevOps、Travis CI、CircleCI、GitLab CI / CD、Jenkins、VisualStudioなどのシステムとの統合です。これらは警告を大量に抑制するための高度なメカニズムであり、大規模な古いプロジェクトでもPVS-Studioの使用をすばやく開始できます。これは通知配布です。などなど。ただし、それでも最初に尋ねられる質問は、「PVS-Studioは、コンパイラーが見つけられないものを見つけることができるか」というものです。これは、これらのコンパイラ自体のチェックに関する記事を何度も書くことを意味します。



Clangプロジェクトのチェックのトピックに戻りましょう。このプロジェクトにこだわる必要はなく、それが何であるかを伝える必要はありません。実際、Clang 11自体のコードだけでなく、それが構築されているLLVM11ライブラリもテストされました。この記事の観点からは、コンパイラまたはライブラリコードのどちらに欠陥が見つかったかは関係ありません。



Clang / LLVMコードは、GCCコードよりもはるかに明確に見えました。少なくともこれらのひどいマクロはすべて欠落しており、C ++言語の最新機能が積極的に使用されています。



それにもかかわらず、プロジェクトは大規模であり、アナライザーの事前設定がないと、レポートを表示するのは依然として非常に面倒です。基本的に、半誤検知は干渉します。「半偽」陽性とは、アナライザーが正式に正しいが、警告に意味がない状況を意味します。たとえば、そのようなポジティブの多くは、ユニットテストと生成されたコードに対して発行されます。



テストの例：

Spaces.SpacesInParentheses = false;               // <=
Spaces.SpacesInCStyleCastParentheses = true;      // <=
verifyFormat("Type *A = ( Type * )P;", Spaces);
verifyFormat("Type *A = ( vector<Type *, int *> )P;", Spaces);
verifyFormat("x = ( int32 )y;", Spaces);
verifyFormat("int a = ( int )(2.0f);", Spaces);
verifyFormat("#define AA(X) sizeof((( X * )NULL)->a)", Spaces);
verifyFormat("my_int a = ( my_int )sizeof(int);", Spaces);
verifyFormat("#define x (( int )-1)", Spaces);

// Run the first set of tests again with:
Spaces.SpacesInParentheses = false;               // <=
Spaces.SpaceInEmptyParentheses = true;
Spaces.SpacesInCStyleCastParentheses = true;      // <=
verifyFormat("call(x, y, z);", Spaces);
verifyFormat("call( );", Spaces);

アナライザーは、変数にすでに含まれているのと同じ値が割り当てられていることを警告します：

• V1048'Spaces.SpacesInParentheses '変数に同じ値が割り当てられました。FormatTest.cpp 11554
• V1048'Spaces.SpacesInCStyleCastParentheses '変数に同じ値が割り当てられました。FormatTest.cpp 11556

正式には、アナライザーは正しい応答を返しました。これは、簡略化または修正する必要があるコードフラグメントです。同時に、実際にはすべてが正常であり、何かを編集しても意味がないことは明らかです。



別の例：アナライザーは、自動生成されたOptions.incファイルに膨大な数の警告を発行します。ファイルに「コードシート」があります。





そして、PVS-Studioはこれらすべてに警告を送信します。

• V501 '=='演算子の左側と右側に同一の部分式があります：nullptr == nullptr Options.inc 26
• V501 '=='演算子の左側と右側に同一の部分式があります：nullptr == nullptr Options.inc 27
• V501 '=='演算子の左側と右側に同一の部分式があります：nullptr == nullptr Options.inc 28
• 各行についてなど...

これはすべて怖いことではありません。これはすべて無効にすることができます。不要なファイルのチェックを無効にしたり、一部のマクロや関数をマークアップしたり、特定の種類のアラームを抑制したりします。可能ですが、記事を書くタスクの一部としてこれを行うことは面白くありません。したがって、GCCコンパイラに関する記事とまったく同じことをしました。記事を書くための11の興味深いコード例ができるまで、レポートを調べました。なぜ11？Clangのバージョンは11なので、フラグメントを11にすると思いました:)。

11の疑わしいコードスニペット

フラグメントN1、1によるモジュロ除算





かっこいい間違い！私はこれらが大好き！

void Act() override {
  ....
  // If the value type is a vector, and we allow vector select, then in 50%
  // of the cases generate a vector select.
  if (isa<FixedVectorType>(Val0->getType()) && (getRandom() % 1)) {
    unsigned NumElem =
        cast<FixedVectorType>(Val0->getType())->getNumElements();
    CondTy = FixedVectorType::get(CondTy, NumElem);
  }
  ....
}

PVS-Studio警告：V10631回の操作によるモジュロは無意味です。結果は常にゼロになります。 llvm-stress.cpp 631モジュロ



除算は、0または1のランダム値を取得するために使用されます。しかし、明らかに、この1の値は紛らわしく、2で割る必要はありますが、人々は1で割るという古典的なエラーパターンを作成します。結果は常に0であるため、操作X％1は無意味です。コードの正しいバージョン：

if (isa<FixedVectorType>(Val0->getType()) && (getRandom() % 2)) {

最近PVS-Studioに登場したDiagnosticsV1063はとてつもなくシンプルですが、ご覧のとおり、機能します。



ご存知のように、コンパイラ開発者は私たちが行っていることを見て、ベストプラクティスを借りています。それは何も悪いことではありません。PVS-Studioが進歩の原動力であることを嬉しく思います。同じ診断がClangとGCCに表示されるまでの時間を設定します:)。



フラグメントN2、状態のタイプミス

class ReturnValueSlot {
  ....
  bool isNull() const { return !Addr.isValid(); }
  ....
};

static bool haveSameParameterTypes(ASTContext &Context, const FunctionDecl *F1,
                                   const FunctionDecl *F2, unsigned NumParams) {
  ....
  unsigned I1 = 0, I2 = 0;
  for (unsigned I = 0; I != NumParams; ++I) {
    QualType T1 = NextParam(F1, I1, I == 0);
    QualType T2 = NextParam(F2, I2, I == 0);
    if (!T1.isNull() && !T1.isNull() && !Context.hasSameUnqualifiedType(T1, T2))
      return false;
  }
  return true;
}

PVS-Studio警告：V501 '&&'演算子の左側と右側に同一の部分式があります：！T1.isNull（）&&！T1.isNull（）SemaOverload.cpp 9493



2回チェックしています！T1.isNull （）。これは明らかなタイプミスであり、条件の2番目の部分はT2変数をチェックする必要があります。



フラグメントN3、アレイの範囲外の可能性

std::vector<Decl *> DeclsLoaded;

SourceLocation ASTReader::getSourceLocationForDeclID(GlobalDeclID ID) {
  ....
  unsigned Index = ID - NUM_PREDEF_DECL_IDS;

  if (Index > DeclsLoaded.size()) {
    Error("declaration ID out-of-range for AST file");
    return SourceLocation();
  }

  if (Decl *D = DeclsLoaded[Index])
    return D->getLocation();
  ....
}

PVS-Studioの警告：V557アレイのオーバーランが発生する可能性があります。「インデックス」インデックスは、配列の境界を超えています。ASTReader.cpp 7318



配列に1つの要素が含まれ、Index変数も1つであるとします。条件（1> 1）は偽であり、その結果、配列はオーバーランします。正しいチェック：

if (Index >= DeclsLoaded.size()) {

フラグメントN4、引数の評価の順序

void IHexELFBuilder::addDataSections() {
  ....
  uint32_t SecNo = 1;
  ....
  Section = &Obj->addSection<OwnedDataSection>(
      ".sec" + std::to_string(SecNo++), RecAddr,
      ELF::SHF_ALLOC | ELF::SHF_WRITE, SecNo);
  ....
}

PVS-Studio警告：V567不特定の動作。'addSection'関数では、引数の評価順序が定義されていません。'SecNo'変数を調べることを検討してください。Object.cpp 1223 SecNo



引数が2回使用され、途中でインクリメントされることに注意してください。引数がどのような順序で評価されるかを言うことは不可能です。したがって、結果はコンパイラのバージョンまたはコンパイル設定によって異なります。



これを総合的な例で説明しましょう。

#include <cstdio>
int main()
{
  int i = 1;
  printf("%d, %d\n", i, i++);
  return 0;
}

コンパイラによっては、「1、2」と「2、1」の両方を印刷できます。コンパイラエクスプローラを使用すると、次の結果が得られます。

• Clang 11.0.0でコンパイルされたプログラムは、1、1を生成します。
• GCC 10.2でコンパイルされたプログラムは、2、1を生成します。

興味深いことに、この単純なケースでは、Clangコンパイラは警告を発行します。

<source>:6:26: warning:
unsequenced modification and access to 'i' [-Wunsequenced]
printf("%d, %d\n", i, i++);

どうやら、実際の状況では、この警告は役に立ちませんでした。診断は実際の使用に不便であるため無効になっているか、コンパイラがより複雑なケースについて警告できませんでした。



フラグメントN5、奇妙な再テスト

template <class ELFT>
void GNUStyle<ELFT>::printVersionSymbolSection(const ELFFile<ELFT> *Obj,
                                               const Elf_Shdr *Sec) {

  ....
  Expected<StringRef> NameOrErr =
      this->dumper()->getSymbolVersionByIndex(Ndx, IsDefault);
  if (!NameOrErr) {
    if (!NameOrErr) {
      unsigned SecNdx = Sec - &cantFail(Obj->sections()).front();
      this->reportUniqueWarning(createError(
          "unable to get a version for entry " + Twine(I) +
          " of SHT_GNU_versym section with index " + Twine(SecNdx) + ": " +
          toString(NameOrErr.takeError())));
    }
    Versions.emplace_back("<corrupt>");
    continue;
  }
  ....
}

PVS-Studioの警告：V571定期的なチェック。'if（！NameOrErr）'条件は、4666行目ですでに確認されています。ELFDumper.cpp46672



番目のチェックは最初のチェックと重複しており、冗長です。おそらく、2番目のチェックは簡単に削除できます。ただし、これはタイプミスである可能性が高く、2番目の条件では別の変数を使用する必要があります。



スニペットN6、潜在的にnullポインタを逆参照

void RewriteObjCFragileABI::RewriteObjCClassMetaData(
  ObjCImplementationDecl *IDecl, std::string &Result)
{
  ObjCInterfaceDecl *CDecl = IDecl->getClassInterface();

  if (CDecl->isImplicitInterfaceDecl()) {
    RewriteObjCInternalStruct(CDecl, Result);
  }

  unsigned NumIvars = !IDecl->ivar_empty()
  ? IDecl->ivar_size()
  : (CDecl ? CDecl->ivar_size() : 0);
  ....
}

PVS-Studio警告：V595 nullptrに対して検証される前に、「CDecl」ポインターが使用されました。チェック行：5275、5284。RewriteObjC.cpp 5275



最初のチェック中、CDeclポインターは常に大胆に逆参照されます。

if (CDecl->isImplicitInterfaceDecl())

そして、以下に書かれたコードからのみ、このポインターがnullになる可能性があることが明らかになります。

(CDecl ? CDecl->ivar_size() : 0)

ほとんどの場合、最初のチェックは次のようになります。

if (CDecl && CDecl->isImplicitInterfaceDecl())

スニペットN7、潜在的にnullポインタを逆参照

bool
Sema::InstantiateClass(....)
{
  ....
  NamedDecl *ND = dyn_cast<NamedDecl>(I->NewDecl);
  CXXRecordDecl *ThisContext =
      dyn_cast_or_null<CXXRecordDecl>(ND->getDeclContext());
  CXXThisScopeRAII ThisScope(*this, ThisContext, Qualifiers(),
                              ND && ND->isCXXInstanceMember());
  ....
}

PVS-Studio警告：V595 nullptrに対して検証される前に、「ND」ポインターが使用されました。チェック行：2803、2805。SemaTemplateInstantiate.cpp2803



前のエラーのバリエーション。動的キャストを使用して値が取得されているかどうかを最初に確認せずにポインタを逆参照することは危険です。さらに、以下のコードから、そのようなチェックが必要であることは明らかです。



フラグメントN8、関数はエラー状態にもかかわらず実行を継続します

bool VerifyObject(llvm::yaml::Node &N,
                  std::map<std::string, std::string> Expected) {
  ....
  auto *V = llvm::dyn_cast_or_null<llvm::yaml::ScalarNode>(Prop.getValue());
  if (!V) {
    ADD_FAILURE() << KS << " is not a string";
    Match = false;
  }
  std::string VS = V->getValue(Tmp).str();
  ....
}

PVS-Studio警告：V1004 nullptrに対して検証された後、「V」ポインターが安全に使用されませんでした。チェックライン：61、65。TraceTests.cpp65



ポインタVがnullの可能性があります。これは明らかに誤った状態であり、報告されています。ただし、この後、関数は何も起こらなかったかのように実行を続行します。これにより、この非常にnullのポインターが逆参照されます。おそらく彼らは機能を中断するのを忘れていたので、正しいオプションは次のようになります。

auto *V = llvm::dyn_cast_or_null<llvm::yaml::ScalarNode>(Prop.getValue());
if (!V) {
  ADD_FAILURE() << KS << " is not a string";
  Match = false;
  return false;
}
std::string VS = V->getValue(Tmp).str();

スニペットN9、タイプミス

const char *tools::SplitDebugName(const ArgList &Args, const InputInfo &Input,
                                  const InputInfo &Output) {
  if (Arg *A = Args.getLastArg(options::OPT_gsplit_dwarf_EQ))
    if (StringRef(A->getValue()) == "single")
      return Args.MakeArgString(Output.getFilename());

  Arg *FinalOutput = Args.getLastArg(options::OPT_o);
  if (FinalOutput && Args.hasArg(options::OPT_c)) {
    SmallString<128> T(FinalOutput->getValue());
    llvm::sys::path::replace_extension(T, "dwo");
    return Args.MakeArgString(T);
  } else {
    // Use the compilation dir.
    SmallString<128> T(
        Args.getLastArgValue(options::OPT_fdebug_compilation_dir));
    SmallString<128> F(llvm::sys::path::stem(Input.getBaseInput()));
    llvm::sys::path::replace_extension(F, "dwo");
    T += F;
    return Args.MakeArgString(F);       // <=
  }
}

PVS-Studio警告：V1001「T」変数が割り当てられていますが、関数の最後では使用されていません。CommonArgs.cpp873



関数の終わりに注意してください。ローカル変数Tは変更されますが、使用されません。ほとんどの場合、これはタイプミスであり、関数は次のコード行で終了する必要があります。

T += F;
return Args.MakeArgString(T);

フラグメントN10、除数はゼロ

typedef int32_t si_int;
typedef uint32_t su_int;

typedef union {
  du_int all;
  struct {
#if _YUGA_LITTLE_ENDIAN
    su_int low;
    su_int high;
#else
    su_int high;
    su_int low;
#endif // _YUGA_LITTLE_ENDIAN
  } s;
} udwords;

COMPILER_RT_ABI du_int __udivmoddi4(du_int a, du_int b, du_int *rem) {
  ....
  if (d.s.low == 0) {
    if (d.s.high == 0) {
      // K X
      // ---
      // 0 0
      if (rem)
        *rem = n.s.high % d.s.low;
      return n.s.high / d.s.low;
    }
  ....
}

PVS-Studioの警告：

• ゼロによるV609Mod。分母 'dslow' == 0.udivmoddi4.c 61
• V609ゼロで除算します。分母 'dslow' == 0.udivmoddi4.c 62

これが間違いなのかトリッキーなアイデアなのかはわかりませんが、コードは非常に奇妙です。通常の整数変数は2つあり、一方はもう一方で割り切れます。興味深いことに、これは両方の変数がゼロの場合にのみ発生します。これはどういう意味ですか？



フラグメントN11、コピー＆ペースト

bool MallocChecker::mayFreeAnyEscapedMemoryOrIsModeledExplicitly(....)
{
  ....
  StringRef FName = II->getName();
  ....
  if (FName == "postEvent" &&
      FD->getQualifiedNameAsString() == "QCoreApplication::postEvent") {
    return true;
  }

  if (FName == "postEvent" &&
      FD->getQualifiedNameAsString() == "QCoreApplication::postEvent") {
    return true;
  }
  ....
}

PVS-Studio警告：V581互いに並んで配置されている「if」ステートメントの条件式は同じです。チェック行：3108、3113。MallocChecker.cpp 3113



コードスニペットはコピーされましたが、変更されていません。2番目のスニペットは、いくつかの有用なチェックの実行を開始するために削除または変更する必要があります。

結論

この無料のライセンスオプション を使用して、オープンソースプロジェクトを確認できることをお知らせします。ちなみに、PVS-Studioの無料ライセンスには、クローズドプロジェクトを含む他のオプションがあります。それらはここにリストされています：「無料のPVS-Studioライセンスオプション」。清聴ありがとうございました。

コンパイラチェックに関するその他の記事

• LLVM（Clang）分析（2011年8月）、2番目の分析（2012年8月）、3番目の分析（2016年10月）、4番目の分析（2019年4月）
• GCC分析（2016年8月）、2回目の分析（2020年4月）
• Huawei Arkコンパイラ分析（2019年12月）
• .NETコンパイラプラットフォーム（「Roslyn」）分析（2015年12月）、2回目の分析（2019年4月）
• Roslynアナライザー分析（2019年8月）
• PascalABC.NET分析（2017年3月）

この記事を英語を話す聴衆と共有したい場合は、翻訳リンクを使用してください：AndreyKarpov。PVS-StudioでClang11をチェックしています。