IntelのPMDKライブラリコレクションの静的コード分析とエラーではないエラー

PVS-Studioアナライザーを使用して、不揮発性メモリをサポートするアプリケーションの開発とデバッグ用に設計されたオープンPMDKライブラリのコレクションをチェックするように提案されました。実際、どうしてですか。さらに、これはCおよびC ++の小さなプロジェクトであり、コメントを除いた合計コードベースサイズは約170KLOCです。これは、分析結果のレビューに多くの時間と労力がかからないことを意味します。行こう。



ソースコードを分析するには、PVS-Studioツールバージョン7.08を使用します。当然のことながら、私たちのブログの読者は私たちのツールに長い間精通しているので、私はそれにこだわるつもりはありません。初めての私達に来た人のために、私は「記事を参照勧め迅速？CおよびC ++コードのPVS-Studioのアナライザによって発行されている興味深い警告を表示する方法」としてみてくださいアナライザの無料試用版を。



今回はPMDKプロジェクトの内部を見て、気付いたエラーと欠点について説明します。私の内面では、それらの数は多くありませんでした。これは、このプロジェクトのコードの品質が高いことを示しています。興味深いことに、間違ったコードのフラグメントがいくつか見つかったにもかかわらず、正しく機能していることがわかります:)。私が言いたいことは、さらなるナレーションからより明確になるでしょう。



要約すると、PMDKは、不揮発性メモリ対応アプリケーションの開発、デバッグ、および管理を簡素化するように設計されたオープンソースライブラリとツールのコレクションです。詳細はこちら：PMDKの紹介。ここのソース：pmdk。



私がそこに見つけることができるエラーと欠点を見てみましょう。私は、レポートを分析するときに常に注意を払うことはできず、多くのことを見逃していた可能性があることをすぐに言わなければなりません。したがって、プロジェクトの作成者は、欠陥を修正するときにこの記事だけに導かれるのではなく、自分でコードを再確認することをお勧めします。そして、記事を書くには、警告のリストを見て、私が書いたもので十分です:)。

動作する間違ったコード

メモリ割り当てサイズ

プログラムが本来の動作をしないときに、プログラマーがコードのデバッグに時間を費やすことは珍しくありません。ただし、プログラムが正しく機能していても、コードにエラーが含まれている場合があります。プログラマーは幸運であり、エラーは現れません。PMDKプロジェクトでは、このような興味深い状況に一度に遭遇したため、それらを別の章にまとめることにしました。

int main(int argc, char *argv[])
{
  ....
  struct pool *pop = malloc(sizeof(pop));
  ....
}

PVS-Studioの警告：V568'sizeof（） '演算子がクラスへのポインターのサイズを評価するが、' pop 'クラスオブジェクトのサイズは評価しないのは奇妙なことです。util_ctl.c717



誤った量のメモリが割り当てられる原因となる古典的なタイプミス。sizeof演算子は、構造のサイズではなく、この構造へのポインターのサイズを返します。正しいオプションは次のとおりです。

struct pool *pop = malloc(sizeof(pool));

または

struct pool *pop = malloc(sizeof(*pop));

ただし、この誤って記述されたコードはうまく機能します。重要なのは、プール構造には1つのポインターが含まれているということです。

struct pool {
  struct ctl *ctl;
};

構造はポインタとまったく同じ量を占めることがわかります。物事は良いです。

線の長さ

次のケースに移りましょう。ここでも、sizeof演算子を使用してエラーが発生しました。

typedef void *(*pmem2_memcpy_fn)(void *pmemdest, const void *src, size_t len,
    unsigned flags);

static const char *initial_state = "No code.";

static int
test_rwx_prot_map_priv_do_execute(const struct test_case *tc,
  int argc, char *argv[])
{
  ....
  char *addr_map = pmem2_map_get_address(map);
  map->memcpy_fn(addr_map, initial_state, sizeof(initial_state), 0);
  ....
}

PVS-Studio警告：V579 [CWE-687] memcpy_fn関数は、ポインターとそのサイズを引数として受け取ります。おそらく間違いです。 3番目の引数を調べます。 pmem2_map_prot.c 513



特殊なコピー関数へのポインターは、文字列をコピーするために使用されます。この関数の呼び出し、またはむしろその3番目の引数に注意してください。



プログラマーは、sizeof演算子が文字列リテラルのサイズを計算すると想定しています。しかし、実際には、ポインターのサイズが再度計算されます。



幸い、文字列は8文字で構成されており、64ビットアプリケーションを構築する場合、そのサイズはポインタと同じです。その結果、文字列の8文字すべてが「コードなし」になります。正常にコピーされます。



実際、状況はさらに複雑で興味深いものです。このエラーの解釈は、ターミナル0をコピーするかどうかによって異なります。2つのシナリオを考えてみましょう。



シナリオ1.端子0をコピーする必要がありました。それから私は間違っています、そしてこれはそれ自体が現れない無害な間違いではありません。9バイトではなく、8バイトのみがコピーされました。ターミナルゼロはなく、結果を予測することはできません。この場合、定数文字列initial_stateの定義を次のように変更することで、コードを修正できます。

static const char initial_state [] = "No code.";

これで、sizeof（initial_state）値は9になります。



シナリオ2.ターミナルゼロはまったく必要ありません。たとえば、以下に次のコード行を示します。

UT_ASSERTeq(memcmp(addr_map, initial_state, strlen(initial_state)), 0);

ご覧のとおり、strlen関数は値8を返し、端子ゼロは比較に関与しません。それからそれは本当に幸運であり、すべてが順調です。

ビットシフト

次の例は、ビット単位のシフト操作に関連しています。

static int
clo_parse_single_uint(struct benchmark_clo *clo, const char *arg, void *ptr)
{
  ....
  uint64_t tmax = ~0 >> (64 - 8 * clo->type_uint.size);
  ....
}

PVS-Studio警告：V610 [CWE-758]不特定の動作。シフト演算子 '>>'を確認してください。左のオペランド '〜0'は負です。clo.cpp 205



負の値を右にシフトした結果は、コンパイラの実装によって異なります。したがって、このようなコードは正しく機能し、現在存在するすべてのアプリケーションコンパイルモードで期待どおりに機能する可能性がありますが、それでも幸運です。

運用の優先順位

そして、操作の優先順位に関連する最後のケースを考えてみましょう。

#define BTT_CREATE_DEF_SIZE  (20 * 1UL << 20) /* 20 MB */

PVS-Studio警告：V634 [CWE-783]「*」操作の優先度は「<<」操作の優先度よりも高くなっています。式で括弧を使用する必要がある可能性があります。bttcreate.c 204



20 MBに等しい定数を取得するために、プログラマーは次のことを行うことにしました。

• 1 x 20ビットシフトして1048576を取得します。つまり、1MB。
• 1MBに20を掛けます。

言い換えれば、プログラマーは計算が次のように行われると考えます：（20 *（1UL << 20））



しかし実際には、乗算演算子の優先度はシフト演算子の優先度よりも高く、式は次のように評価されます：（（20 * 1UL）<< 20）。



同意します、プログラマーは式がそのような順序で評価されることをほとんど望んでいませんでした。20に1を掛けても意味がありません。したがって、これは、コードがプログラマーの意図したとおりに機能しない場合です。



しかし、このエラーは決して現れません。どのように書くかは問題ではありません。

• （20 * 1UL << 20）
• （20 *（1UL << 20））
• （（20 * 1UL）<< 20）

結果は常に同じです！必要な値は常に20971520であり、プログラムは完全に正しく機能します。

その他のエラー

間違った場所の括弧

#define STATUS_INFO_LENGTH_MISMATCH 0xc0000004

static void
enum_handles(int op)
{
  ....
  NTSTATUS status;
  while ((status = NtQuerySystemInformation(
      SystemExtendedHandleInformation,
      hndl_info, hi_size, &req_size)
        == STATUS_INFO_LENGTH_MISMATCH)) {
    hi_size = req_size + 4096;
    hndl_info = (PSYSTEM_HANDLE_INFORMATION_EX)REALLOC(hndl_info,
        hi_size);
  }
  UT_ASSERT(status >= 0);
  ....
}

PVS-Studioの警告：V593 [CWE-783]「A = B == C」の種類の式を確認することを検討してください。式は次のように計算されます： 'A =（B == C）'。ut.c 641



ここをよく見てください：

while ((status = NtQuerySystemInformation(....) == STATUS_INFO_LENGTH_MISMATCH))

プログラマーは、NtQuerySystemInformation関数が返す値をステータス変数に格納し、それを定数と比較したいと考えていました。 プログラマーは、比較演算子（==）の優先度が割り当て演算子（=）よりも高いことを知っている可能性が高いため、括弧を使用する必要があります。しかし、彼は自分自身を封印し、それらを間違った場所に置きました。結果として、括弧はまったく役に立ちません。正しいコード：

while ((status = NtQuerySystemInformation(....)) == STATUS_INFO_LENGTH_MISMATCH)

このエラーのため、UT_ASSERTマクロは機能しません。実際、ステータス変数には常に比較の結果、つまりfalse（0）またはtrue（1）が含まれます。したがって、条件（[0..1]> = 0）は常に真です。

潜在的なメモリリーク

static enum pocli_ret
pocli_args_obj_root(struct pocli_ctx *ctx, char *in, PMEMoid **oidp)
{
  char *input = strdup(in);
  if (!input)
    return POCLI_ERR_MALLOC;

  if (!oidp)
    return POCLI_ERR_PARS;
  ....
}

PVS-Studio警告：V773 [CWE-401]「入力」ポインターを解放せずに関数が終了しました。メモリリークが発生する可能性があります。pmemobjcli.c 238 oidpがnullポインターであることが判明した



場合、strdup関数を呼び出して作成された文字列のコピーは失われます。最善の策は、メモリを割り当てる前にチェックを延期することです。

static enum pocli_ret
pocli_args_obj_root(struct pocli_ctx *ctx, char *in, PMEMoid **oidp)
{
  if (!oidp)
    return POCLI_ERR_PARS;

  char *input = strdup(in);
  if (!input)
    return POCLI_ERR_MALLOC;
  ....
}

または、メモリを明示的に解放できます。

static enum pocli_ret
pocli_args_obj_root(struct pocli_ctx *ctx, char *in, PMEMoid **oidp)
{
  char *input = strdup(in);
  if (!input)
    return POCLI_ERR_MALLOC;

  if (!oidp)
  {
    free(input);
    return POCLI_ERR_PARS;
  }
  ....
}

オーバーフローの可能性

typedef long long os_off_t;

void
do_memcpy(...., int dest_off, ....., size_t mapped_len, .....)
{
  ....
  LSEEK(fd, (os_off_t)(dest_off + (int)(mapped_len / 2)), SEEK_SET);
  ....
}

PVS-Studio警告：V1028 [CWE-190]オーバーフローの可能性があります。結果ではなく、オペランドをキャストすることを検討してください。memcpy_common.c 62os_off_t



タイプへの追加の結果を明示的にキャストすることは意味がありません。まず、2つのint値を追加するときに発生する可能性のあるオーバーフローから保護しません。第二に、追加の結果は、とにかくos_off_tタイプに暗黙的に拡張されます。明示的な型キャストは単に冗長です。 私はこのように書く方が正しいと思います：

LSEEK(fd, dest_off + (os_off_t)(mapped_len) / 2, SEEK_SET);

ここで、size_tタイプの符号なしの値が符号付きの値に変換されます（コンパイラからの警告がないようにするため）。同時に、追加時にオーバーフローが発生することはありません。

不適切なオーバーフロー保護

static DWORD
get_rel_wait(const struct timespec *abstime)
{
  struct __timeb64 t;
  _ftime64_s(&t);
  time_t now_ms = t.time * 1000 + t.millitm;
  time_t ms = (time_t)(abstime->tv_sec * 1000 +
    abstime->tv_nsec / 1000000);

  DWORD rel_wait = (DWORD)(ms - now_ms);

  return rel_wait < 0 ? 0 : rel_wait;
}

PVS-Studio警告：V547 [CWE-570]式 'rel_wait <0'は常にfalseです。符号なしタイプの値が0未満になることはありません。os_thread_windows.c359



チェックがどの状況から保護する必要があるかについてはよくわかりませんが、とにかく機能しません。rel_wait変数は符号なしDWORDタイプです。これは、結果が常に真であるため、rel_wait <0の比較は意味がないことを意味します。

メモリが正常に割り当てられたことの確認の欠如

メモリが割り当てられていることの確認は、アプリケーションのリリースバージョンがコンパイルされている場合は何もしないassertマクロを使用して行われます。したがって、malloc関数がNULLを返す状況の処理はないと言えます。例：

static void
remove_extra_node(TOID(struct tree_map_node) *node)
{
  ....
  unsigned char *new_key = (unsigned char *)malloc(new_key_size);
  assert(new_key != NULL);
  memcpy(new_key, D_RO(tmp)->key, D_RO(tmp)->key_size);
  ....
}

PVS-Studio警告：V575 [CWE-628]潜在的なnullポインターが「memcpy」関数に渡されます。最初の引数を調べます。チェック行：340、338。rtree_map.c 340



他の場所では、アサートすらありません：

static void
calc_pi_mt(void)
{
  ....
  HANDLE *workers = (HANDLE *) malloc(sizeof(HANDLE) * pending);
  for (i = 0; i < pending; ++i) {
    workers[i] = CreateThread(NULL, 0, calc_pi,
      &tasks[i], 0, NULL);
    if (workers[i] == NULL)
      break;
  }
  ....
}

PVS-Studio警告：V522 [CWE-690]潜在的なヌルポインター「ワーカー」の参照解除がある可能性があります。チェック行：126、124。pi.c126



少なくとも37のそのようなコードフラグメントを数えました。したがって、それらすべてを記事に記載する理由はありません。



一見、チェックの欠如は単なる怠惰と見なすことができ、これは匂いのあるコードであると言えます。私はこの立場に同意しません。プログラマーは、そのようなチェックを見逃す危険性を過小評価しています。 nullポインターは、参照を解除しようとしたときに、プログラムのクラッシュとしてすぐに現れるとは限りません。特にマルチスレッドプログラムでは、結果はより奇妙で危険なものになる可能性があります。何が問題で、なぜチェックが必要なのかをより詳細に理解するために、記事を読むことを強くお勧めします。malloc関数が何を返したかを確認することが重要なのはなぜですか。

臭いコード

CloseHandleをダブルコール

static void
prepare_map(struct pmem2_map **map_ptr,
  struct pmem2_config *cfg, struct pmem2_source *src)
{
  ....
  HANDLE mh = CreateFileMapping(....);
  ....
  UT_ASSERTne(CloseHandle(mh), 0);
  ....
}

PVS-Studioの警告：V586 [CWE-675]同じリソースの割り当てを解除するために「CloseHandle」関数が2回呼び出されます。pmem2_map.c 76



このコードとPVS-Studioの警告を見ると、明確なものが何もないことは明らかです。どこでCloseHandleを再度呼び出すことができますか？答えを見つけるために、UT_ASSERTneマクロの実装を見てみましょう。

#define UT_ASSERTne(lhs, rhs)\
  do {\
    /* See comment in UT_ASSERT. */\
    if (__builtin_constant_p(lhs) && __builtin_constant_p(rhs))\
      UT_ASSERT_COMPILE_ERROR_ON((lhs) != (rhs));\
    UT_ASSERTne_rt(lhs, rhs);\
  } while (0)

それはそれほど明確にはなりませんでした。UT_ASSERT_COMPILE_ERROR_ONとは何ですか？UT_ASSERTne_rtとは何ですか？



各マクロの説明で記事を乱雑にしたり、読者を苦しめたりせず、頭の中で1つのマクロを他のマクロに挿入するように強制します。前処理されたファイルから取得された、開かれたコードの最終バージョンをすぐに見てみましょう。

do {
  if (0 && 0) (void)((CloseHandle(mh)) != (0));
  ((void)(((CloseHandle(mh)) != (0)) ||
    (ut_fatal(".....", 76, __FUNCTION__, "......: %s (0x%llx) != %s (0x%llx)",
              "CloseHandle(mh)", (unsigned long long)(CloseHandle(mh)), "0",
              (unsigned long long)(0)), 0))); } while (0);

常に誤った条件（0 && 0）と、一般的には無関係なものをすべて削除しましょう。それが判明：

((void)(((CloseHandle(mh)) != (0)) ||
  (ut_fatal(...., "assertion failure: %s (0x%llx) != %s (0x%llx)",
            ....., (unsigned long long)(CloseHandle(mh)), .... ), 0)));

ハンドルが閉じています。エラーが発生した場合、デバッグメッセージが生成され、エラーコードを再度取得するために、同じ無効なハンドルに対してCloseHandleが呼び出されます。



エラー、種類、およびいいえ。ハンドルが無効であるため、CloseHandle関数が2回呼び出されても問題ありません。ただし、このコードは無臭です。関数を1回だけ呼び出して、返されたステータスを保存し、必要に応じてその値をメッセージに表示する方が、より理想的には正しいでしょう。

実装インターフェイスの不整合（constの削除）

static int
status_push(PMEMpoolcheck *ppc, struct check_status *st, uint32_t question)
{
  ....
  } else {
    status_msg_info_and_question(st->msg);            // <=
    st->question = question;
    ppc->result = CHECK_RESULT_ASK_QUESTIONS;
    st->answer = PMEMPOOL_CHECK_ANSWER_EMPTY;
    PMDK_TAILQ_INSERT_TAIL(&ppc->data->questions, st, next);
  }
  ....
}

アナライザーは次のメッセージを表示します。V530[CWE-252]関数 'status_msg_info_and_question'の戻り値を使用する必要があります。check_util.c 293



その理由は、status_msg_info_and_question関数は、アナライザーの観点からは、渡された定数文字列を含め、外部のオブジェクトの状態を変更しないためです。それら。この関数は何かを計算して結果を返すだけです。もしそうなら、この関数が返す結果を使用しないのは奇妙です。そして、今回はアナライザーが間違っていますが、臭いのあるコードを指しています。呼び出されたstatus_msg_info_and_question関数がどのように機能するかを見てみましょう。

static inline int
status_msg_info_and_question(const char *msg)
{
  char *sep = strchr(msg, MSG_SEPARATOR);
  if (sep) {
    *sep = ' ';
    return 0;
  }
  return -1;
}

strchr 関数を呼び出すと、定数の暗黙的な削除が発生します。実際のところ、Cでは次のように宣言されています。

char * strchr ( const char *, int );

最善の解決策ではありません。しかし、C言語はそれが何であるかです:)。



アナライザーは混乱し、渡された文字列が実際に変更されていることを理解しませんでした。もしそうなら、戻り値は最も重要なことではなく、あなたはそれを使うことができません。



ただし、アナライザーは混乱していますが、臭いのあるコードを指しています。パーサーを混乱させるものは、コードを管理する人を混乱させる可能性もあります。constを削除して、関数をより正直に宣言することをお勧めします。

static inline int
status_msg_info_and_question(char *msg)
{
  char *sep = strchr(msg, MSG_SEPARATOR);
  if (sep) {
    *sep = ' ';
    return 0;
  }
  return -1;
}

したがって、意図はすぐに明確になり、アナライザーは無音になります。

複雑すぎるコード

static struct memory_block
heap_coalesce(struct palloc_heap *heap,
  const struct memory_block *blocks[], int n)
{
  struct memory_block ret = MEMORY_BLOCK_NONE;

  const struct memory_block *b = NULL;
  ret.size_idx = 0;
  for (int i = 0; i < n; ++i) {
    if (blocks[i] == NULL)
      continue;
    b = b ? b : blocks[i];
    ret.size_idx += blocks[i] ? blocks[i]->size_idx : 0;
  }
  ....
}

PVS-Studio警告：V547 [CWE-571]式 'ブロック[i]'は常に真です。heap.c 1054



場合はブロック[i]を== NULLが、その後、継続文がトリガされ、ループが次の反復を開始します。したがって、要素ブロック[i]を再チェックすることは意味がなく、3値演算子は不要です。コードは単純化できます。

....
for (int i = 0; i < n; ++i) {
  if (blocks[i] == NULL)
    continue;
  b = b ? b : blocks[i];
  ret.size_idx += blocks[i]->size_idx;
}
....

nullポインタの疑わしい使用

void win_mmap_fini(void)
{
  ....
  if (mt->BaseAddress != NULL)
    UnmapViewOfFile(mt->BaseAddress);
  size_t release_size =
    (char *)mt->EndAddress - (char *)mt->BaseAddress;
  void *release_addr = (char *)mt->BaseAddress + mt->FileLen;
  mmap_unreserve(release_addr, release_size - mt->FileLen);
  ....
}

PVS-Studio警告：V1004 [CWE-119] nullptrに対して検証された後、 '（char *）mt-> BaseAddress'ポインターが安全に使用されませんでした。ラインチェック：226、235 win_mmap.c 235はMT-> BASEADDRESSポインタのチェックにより証明されるように、nullになることができます。

if (mt->BaseAddress != NULL)

ただし、このポインタの下では、チェックなしの算術演算ですでに使用されています。たとえば、ここで：

size_t release_size =
  (char *)mt->EndAddress - (char *)mt->BaseAddress;

いくつかの大きな整数値が受信されます。これは、実際にはmt-> EndAddressポインターの値です。これはバグではないかもしれませんが、すべて非常に疑わしいように見え、コードを再チェックする必要があるように思われます。匂いは、コードが理解できず、明らかに説明的なコメントがないという事実にあります。

グローバル変数の短縮名

短い名前のグローバル変数が含まれていると、コードの臭いがするのではないかと思います。封印するのは簡単で、誤ってローカルではなくグローバル変数を一部の関数で使用します。例：

static struct critnib *c;

このような変数に対するPVS-Studioの警告：

• V707グローバル変数に短い名前を付けることは悪い習慣と見なされます。'ri'変数の名前を変更することをお勧めします。map.c 131
• V707グローバル変数に短い名前を付けることは悪い習慣と見なされます。'c'変数の名前を変更することをお勧めします。obj_critnib_mt.c 56
• V707グローバル変数に短い名前を付けることは悪い習慣と見なされます。'Id'変数の名前を変更することをお勧めします。obj_list.h 68
• V707グローバル変数に短い名前を付けることは悪い習慣と見なされます。'Id'変数の名前を変更することをお勧めします。obj_list.c 34

奇妙な

私が遭遇した最も奇妙なコードは、do_memmove関数にあります。アナライザーは2つのポジティブを示しました。これは、非常に深刻なエラーか、私が何を意味するのか理解していないことを示しています。コードが非常に奇妙なので、記事の別のセクションで発行された警告を検討することにしました。したがって、最初の警告がここで発行されます。

void
do_memmove(char *dst, char *src, const char *file_name,
    size_t dest_off, size_t src_off, size_t bytes,
    memmove_fn fn, unsigned flags, persist_fn persist)
{
  ....
  /* do the same using regular memmove and verify that buffers match */
  memmove(dstshadow + dest_off, dstshadow + dest_off, bytes / 2);
  verify_contents(file_name, 0, dstshadow, dst, bytes);
  verify_contents(file_name, 1, srcshadow, src, bytes);
  ....
}

PVS-Studio警告：V549 [CWE-688] 'memmove'関数の最初の引数が2番目の引数と同じです。memmove_common.c71



関数の最初の引数と2番目の引数が同じであることに注意してください。したがって、この関数は実際には何もしません。どのようなオプションが思い浮かびますか：

• メモリブロックに「触れ」たかったのです。しかし、これは実際に起こりますか？最適化コンパイラは、メモリブロックをそれ自体にコピーするコードを削除しますか？
• これは、memmove関数のある種のユニットテストです。
• コードにタイプミスが含まれています。

そして、これは同じ関数内の同様に奇妙なスニペットです：

void
do_memmove(char *dst, char *src, const char *file_name,
    size_t dest_off, size_t src_off, size_t bytes,
    memmove_fn fn, unsigned flags, persist_fn persist)
{
  ....
  /* do the same using regular memmove and verify that buffers match */
  memmove(dstshadow + dest_off, srcshadow + src_off, 0);
  verify_contents(file_name, 2, dstshadow, dst, bytes);
  verify_contents(file_name, 3, srcshadow, src, bytes);
  ....
}

PVS-Studio警告：V575 [CWE-628]「memmove」関数は「0」要素を処理します。3番目の引数を調べます。memmove_common.c82



関数は0バイトを移動します。それは何ですか？単体テスト？打ち間違え？



私にとって、このコードは理解できず、奇妙です。

なぜコードアナライザーを使用するのですか？

エラーがほとんど見つかっていないため、コード開発プロセスにアナライザーを導入するのは不合理に思えるかもしれません。ただし、静的分析ツールを使用するポイントは、1回限りのチェックではなく、コードの記述段階でのエラーの定期的な検出にあります。それ以外の場合、これらのエラーは、より高価で低速な方法（デバッグ、テスト、ユーザーレビューなど）で検出されます。このアイデアについては、「静的コード分析が使用されていないために検出できないエラー」という記事で詳しく説明されています。この記事をよく理解しておくことをお勧めします。次に、当社のWebサイトにアクセスして、PVS-Studioをダウンロードして試してプロジェクトを確認してください。



清聴ありがとうございました！

この記事を英語を話す聴衆と共有したい場合は、翻訳リンクを使用してください：AndreyKarpov。IntelによるPMDKライブラリコレクションの静的コード分析と実際のエラーではないエラー。