ស្វែងរកកំហុសនៅក្នុង LLVM 8 ដោយប្រើឧបករណ៍វិភាគ PVS-Studio

ជាងពីរឆ្នាំបានកន្លងផុតទៅចាប់តាំងពីការត្រួតពិនិត្យលេខកូដចុងក្រោយនៃគម្រោង LLVM ដោយប្រើឧបករណ៍វិភាគ PVS-Studio របស់យើង។ ចូរប្រាកដថា ឧបករណ៍វិភាគ PVS-Studio នៅតែជាឧបករណ៍ឈានមុខគេសម្រាប់កំណត់អត្តសញ្ញាណកំហុស និងភាពងាយរងគ្រោះដែលអាចកើតមាន។ ដើម្បីធ្វើដូចនេះយើងនឹងពិនិត្យមើលនិងស្វែងរកកំហុសថ្មីនៅក្នុងការចេញផ្សាយ LLVM 8.0.0 ។

អត្ថបទដែលត្រូវសរសេរ

និយាយឱ្យត្រង់ទៅ ខ្ញុំមិនចង់សរសេរអត្ថបទនេះទេ។ វាមិនគួរឱ្យចាប់អារម្មណ៍ក្នុងការសរសេរអំពីគម្រោងមួយដែលយើងបានពិនិត្យច្រើនដងរួចមកហើយ (1, 2, 3) វាជាការប្រសើរក្នុងការសរសេរអំពីអ្វីដែលថ្មី ប៉ុន្តែខ្ញុំគ្មានជម្រើសទេ។

រាល់ពេលដែលកំណែថ្មីនៃ LLVM ត្រូវបានចេញផ្សាយ ឬធ្វើបច្ចុប្បន្នភាព Clang Static Analyzerយើងទទួលបានសំណួរនៃប្រភេទខាងក្រោមនៅក្នុងសំបុត្ររបស់យើង៖

មើល កំណែថ្មីរបស់ Clang Static Analyzer បានរៀនស្វែងរកកំហុសថ្មី! វាហាក់ដូចជាខ្ញុំថាភាពពាក់ព័ន្ធនៃការប្រើប្រាស់ PVS-Studio កំពុងថយចុះ។ Clang រកឃើញកំហុសច្រើនជាងមុន ហើយតាមទាន់សមត្ថភាពរបស់ PVS-Studio ។ តើប្រិយមិត្តយល់យ៉ាងណាដែរចំពោះរឿងនេះ?

ចំពោះរឿងនេះខ្ញុំតែងតែចង់ឆ្លើយអ្វីមួយដូចជា៖

យើងក៏មិនអង្គុយទំនេរដែរ! យើងបានធ្វើឱ្យប្រសើរឡើងយ៉ាងខ្លាំងនូវសមត្ថភាពរបស់អ្នកវិភាគ PVS-Studio ។ ដូច្នេះកុំបារម្ភ យើងបន្តដឹកនាំដូចមុន។

ជាអកុសល នេះគឺជាចម្លើយមិនល្អ។ មិនមានភស្តុតាងនៅក្នុងវាទេ។ នោះហើយជាមូលហេតុដែលខ្ញុំកំពុងសរសេរអត្ថបទនេះឥឡូវនេះ។ ដូច្នេះ គម្រោង LLVM ត្រូវបានពិនិត្យម្តងទៀត ហើយកំហុសជាច្រើនត្រូវបានរកឃើញនៅក្នុងវា។ ឥឡូវនេះ ខ្ញុំនឹងបង្ហាញអ្វីដែលគួរឱ្យចាប់អារម្មណ៍សម្រាប់ខ្ញុំ។ Clang Static Analyzer មិន​អាច​រក​ឃើញ​កំហុស​ទាំង​នេះ​ទេ (ឬ​វា​ជា​ការ​រអាក់រអួល​ខ្លាំង​ក្នុង​ការ​ធ្វើ​ដូច្នេះ​ដោយ​មាន​ជំនួយ​របស់​វា)។ ប៉ុន្តែយើងអាចធ្វើបាន។ ជាងនេះទៅទៀត ខ្ញុំបានរកឃើញ និងសរសេរកំហុសទាំងអស់នេះនៅល្ងាចមួយ។

ប៉ុន្តែការសរសេរអត្ថបទចំណាយពេលច្រើនសប្តាហ៍។ ខ្ញុំ​មិន​អាច​យក​ខ្លួន​ខ្ញុំ​ទៅ​ដាក់​ទាំង​អស់​នេះ​ជា​អត្ថបទ :) ។

ដោយវិធីនេះ ប្រសិនបើអ្នកចាប់អារម្មណ៍នឹងបច្ចេកវិទ្យាណាដែលត្រូវបានប្រើនៅក្នុងឧបករណ៍វិភាគ PVS-Studio ដើម្បីកំណត់អត្តសញ្ញាណកំហុស និងភាពងាយរងគ្រោះដែលអាចកើតមាននោះ ខ្ញុំស្នើឱ្យស្គាល់វា ចំណាំ.

ការធ្វើរោគវិនិច្ឆ័យថ្មីនិងចាស់

ដូចដែលបានកត់សម្គាល់រួចហើយ ប្រហែលពីរឆ្នាំមុន គម្រោង LLVM ត្រូវបានពិនិត្យម្តងទៀត ហើយកំហុសដែលបានរកឃើញត្រូវបានកែដំរូវ។ ឥឡូវ​នេះ​អត្ថបទ​នេះ​នឹង​បង្ហាញ​កំហុស​មួយ​បាច់​ថ្មី។ ហេតុអ្វីបានជាមេរោគថ្មីត្រូវបានរកឃើញ? មានហេតុផល ៣ យ៉ាងសម្រាប់រឿងនេះ៖

1. គម្រោង LLVM កំពុងវិវឌ្ឍ ផ្លាស់ប្តូរលេខកូដចាស់ និងបន្ថែមកូដថ្មី។ ជាធម្មតា មានកំហុសថ្មីនៅក្នុងកូដដែលបានកែប្រែ និងសរសេរ។ នេះបង្ហាញយ៉ាងច្បាស់ថាការវិភាគឋិតិវន្តគួរតែត្រូវបានប្រើជាទៀងទាត់ មិនមែនម្តងម្កាលទេ។ អត្ថបទរបស់យើងបង្ហាញយ៉ាងច្បាស់ពីសមត្ថភាពរបស់អ្នកវិភាគ PVS-Studio ប៉ុន្តែនេះមិនមានអ្វីដែលត្រូវធ្វើជាមួយការកែលម្អគុណភាពកូដ និងកាត់បន្ថយការចំណាយលើការជួសជុលកំហុសនោះទេ។ ប្រើឧបករណ៍វិភាគកូដឋិតិវន្តជាប្រចាំ!
2. យើងកំពុងបញ្ចប់ និងកែលម្អការវិនិច្ឆ័យដែលមានស្រាប់។ ដូច្នេះ អ្នកវិភាគអាចកំណត់អត្តសញ្ញាណកំហុសដែលវាមិនបានកត់សម្គាល់ក្នុងអំឡុងពេលស្កេនពីមុន។
3. ការធ្វើរោគវិនិច្ឆ័យថ្មីបានបង្ហាញខ្លួននៅក្នុង PVS-Studio ដែលមិនមានកាលពី 2 ឆ្នាំមុន។ ខ្ញុំបានសម្រេចចិត្តរំលេចពួកវានៅក្នុងផ្នែកដាច់ដោយឡែក ដើម្បីបង្ហាញយ៉ាងច្បាស់ពីការអភិវឌ្ឍន៍របស់ PVS-Studio ។

ពិការភាពដែលកំណត់ដោយរោគវិនិច្ឆ័យដែលមានកាលពី 2 ឆ្នាំមុន

បំណែក N1៖ ចម្លង-បិទភ្ជាប់

static bool ShouldUpgradeX86Intrinsic(Function *F, StringRef Name) {
  if (Name == "addcarryx.u32" || // Added in 8.0
    ....
    Name == "avx512.mask.cvtps2pd.128" || // Added in 7.0
    Name == "avx512.mask.cvtps2pd.256" || // Added in 7.0
    Name == "avx512.cvtusi2sd" || // Added in 7.0
    Name.startswith("avx512.mask.permvar.") || // Added in 7.0     // <=
    Name.startswith("avx512.mask.permvar.") || // Added in 7.0     // <=
    Name == "sse2.pmulu.dq" || // Added in 7.0
    Name == "sse41.pmuldq" || // Added in 7.0
    Name == "avx2.pmulu.dq" || // Added in 7.0
  ....
}

ការព្រមាន PVS-Studio៖ V501 [CWE-570] មានកន្សោមរងដូចគ្នាបេះបិទ 'Name.startswith("avx512.mask.permvar")' នៅខាងឆ្វេង និងទៅខាងស្តាំនៃ '||' ប្រតិបត្តិករ។ AutoUpgrade.cpp ៧៣

វាត្រូវបានត្រួតពិនិត្យពីរដងថាឈ្មោះចាប់ផ្តើមដោយអក្សររង "avx512.mask.permvar" ។ នៅក្នុងការត្រួតពិនិត្យលើកទីពីរ ពួកគេច្បាស់ជាចង់សរសេរអ្វីផ្សេង ប៉ុន្តែភ្លេចកែអត្ថបទដែលបានចម្លង។

បំណែក N2៖ វាយអក្សរ

enum CXNameRefFlags {
  CXNameRange_WantQualifier = 0x1,
  CXNameRange_WantTemplateArgs = 0x2,
  CXNameRange_WantSinglePiece = 0x4
};

void AnnotateTokensWorker::HandlePostPonedChildCursor(
    CXCursor Cursor, unsigned StartTokenIndex) {
  const auto flags = CXNameRange_WantQualifier | CXNameRange_WantQualifier;
  ....
}

ការព្រមាន PVS-Studio៖ V501 មានកន្សោមរងដូចគ្នាបេះបិទ 'CXNameRange_WantQualifier' នៅខាងឆ្វេង និងទៅខាងស្តាំនៃ '|' ប្រតិបត្តិករ។ CIndex.cpp 7245

ដោយ​សារ​ការ​វាយ​អក្សរ​មួយ ថេរ​ដែល​មាន​ឈ្មោះ​ដូចគ្នា​ត្រូវ​បាន​ប្រើ​ពីរដង CXNameRange_WantQualifier.

Fragment N3៖ ភាពច្របូកច្របល់ជាមួយប្រតិបត្តិករនាំមុខ

int PPCTTIImpl::getVectorInstrCost(unsigned Opcode, Type *Val, unsigned Index) {
  ....
  if (ISD == ISD::EXTRACT_VECTOR_ELT && Index == ST->isLittleEndian() ? 1 : 0)
    return 0;
  ....
}

ការព្រមាន PVS-Studio៖ V502 [CWE-783] ប្រហែល '?:' ប្រតិបត្តិករដំណើរការតាមរបៀបខុសពីអ្វីដែលរំពឹងទុក។ ប្រតិបត្តិករ '?:' មានអាទិភាពទាបជាងប្រតិបត្តិករ '==' ។ PPCTargetTransformInfo.cpp 404

នៅក្នុងគំនិតរបស់ខ្ញុំ នេះគឺជាកំហុសដ៏ស្រស់ស្អាតខ្លាំងណាស់។ បាទខ្ញុំដឹងថាខ្ញុំមានគំនិតចម្លែកអំពីភាពស្រស់ស្អាត :) ។

ឥឡូវនេះបើយោងតាម អាទិភាពប្រតិបត្តិករកន្សោមត្រូវបានវាយតម្លៃដូចខាងក្រោមៈ

(ISD == ISD::EXTRACT_VECTOR_ELT && (Index == ST->isLittleEndian())) ? 1 : 0

តាមទស្សនៈជាក់ស្តែង លក្ខខណ្ឌបែបនេះមិនសមហេតុផលទេ ព្រោះវាអាចត្រូវបានកាត់បន្ថយទៅជា៖

(ISD == ISD::EXTRACT_VECTOR_ELT && Index == ST->isLittleEndian())

នេះគឺជាកំហុសច្បាស់លាស់។ ភាគច្រើនទំនងជាពួកគេចង់ប្រៀបធៀប 0/1 ជាមួយនឹងអថេរមួយ។ សន្ទស្សន៍. ដើម្បីជួសជុលកូដ អ្នកត្រូវបន្ថែមវង់ក្រចកជុំវិញប្រតិបត្តិករ ternary៖

if (ISD == ISD::EXTRACT_VECTOR_ELT && Index == (ST->isLittleEndian() ? 1 : 0))

ដោយវិធីនេះ ប្រតិបត្តិករ ternary គឺមានគ្រោះថ្នាក់ខ្លាំងណាស់ហើយបង្កឱ្យមានកំហុសឡូជីខល។ សូមប្រយ័ត្នជាមួយវា ហើយកុំលោភលន់ជាមួយវង់ក្រចក។ ខ្ញុំបានមើលប្រធានបទនេះយ៉ាងលំអិត នៅទីនេះនៅក្នុងជំពូក “Beware of the ?: Operator and Enclose It in the partheses”។

បំណែក N4, N5៖ ទ្រនិចគ្មានន័យ

Init *TGParser::ParseValue(Record *CurRec, RecTy *ItemType, IDParseMode Mode) {
  ....
  TypedInit *LHS = dyn_cast<TypedInit>(Result);
  ....
  LHS = dyn_cast<TypedInit>(
    UnOpInit::get(UnOpInit::CAST, LHS, StringRecTy::get())
      ->Fold(CurRec));
  if (!LHS) {
    Error(PasteLoc, Twine("can't cast '") + LHS->getAsString() +
                    "' to string");
    return nullptr;
  }
  ....
}

ការព្រមាន PVS-Studio៖ V522 [CWE-476] ការបដិសេធនៃទ្រនិចទទេ 'LHS' អាចកើតឡើង។ TGParser.cpp 2152

ប្រសិនបើទ្រនិច អិលអេស ទុកជាមោឃៈ ការព្រមានគួរតែត្រូវបានចេញ។ ទោះយ៉ាងណាក៏ដោយ ផ្ទុយទៅវិញ ទ្រនិចទទេដូចគ្នានេះនឹងត្រូវបានយោង៖ LHS->getAsString().

នេះគឺជាស្ថានភាពធម្មតាបំផុត នៅពេលដែលកំហុសត្រូវបានលាក់នៅក្នុងឧបករណ៍ដោះស្រាយកំហុស ដោយសារគ្មាននរណាម្នាក់សាកល្បងពួកគេ។ ឧបករណ៍វិភាគឋិតិវន្តពិនិត្យមើលកូដដែលអាចទៅដល់បានទាំងអស់ ទោះបីជាវាត្រូវបានគេប្រើញឹកញាប់ប៉ុណ្ណាក៏ដោយ។ នេះគឺជាឧទាហរណ៍ដ៏ល្អមួយអំពីរបៀបដែលការវិភាគឋិតិវន្តបំពេញបន្ថែមការធ្វើតេស្ត និងបច្ចេកទេសការពារកំហុសផ្សេងៗ។

កំហុសក្នុងការដោះស្រាយទ្រនិចស្រដៀងគ្នា HRH ត្រូវបានអនុញ្ញាតនៅក្នុងកូដខាងក្រោម៖ V522 [CWE-476] ការបដិសេធនៃទ្រនិចគ្មានលេខ 'RHS' អាចកើតឡើង។ TGParser.cpp 2186

Fragment N6: ការប្រើទ្រនិចបន្ទាប់ពីផ្លាស់ទី

static Expected<bool>
ExtractBlocks(....)
{
  ....
  std::unique_ptr<Module> ProgClone = CloneModule(BD.getProgram(), VMap);
  ....
  BD.setNewProgram(std::move(ProgClone));                                // <=
  MiscompiledFunctions.clear();

  for (unsigned i = 0, e = MisCompFunctions.size(); i != e; ++i) {
    Function *NewF = ProgClone->getFunction(MisCompFunctions[i].first);  // <=
    assert(NewF && "Function not found??");
    MiscompiledFunctions.push_back(NewF);
  }
  ....
}

ការព្រមាន PVS-Studio៖ V522 [CWE-476] ការបដិសេធនៃទ្រនិចគ្មានន័យ 'ProgClone' អាចកើតឡើង។ Miscompilation.cpp 601

នៅដើមទ្រនិចដ៏ឆ្លាតវៃ ProgClone ឈប់ធ្វើជាម្ចាស់វត្ថុ៖

BD.setNewProgram(std::move(ProgClone));

តាមពិតឥឡូវនេះ ProgClone គឺ​ជា​ទ្រនិច​ទទេ។ ដូច្នេះ សេចក្តីយោង null pointer គួរតែកើតឡើងដូចខាងក្រោម៖

Function *NewF = ProgClone->getFunction(MisCompFunctions[i].first);

ប៉ុន្តែតាមពិត រឿងនេះនឹងមិនកើតឡើងទេ! ចំណាំថារង្វិលជុំមិនត្រូវបានប្រតិបត្តិតាមពិតទេ។

នៅដើមធុង មុខងារខុស ជម្រះ៖

MiscompiledFunctions.clear();

បន្ទាប់ ទំហំនៃកុងតឺន័រនេះត្រូវបានប្រើក្នុងលក្ខខណ្ឌរង្វិលជុំ៖

for (unsigned i = 0, e = MisCompFunctions.size(); i != e; ++i) {

វាងាយស្រួលក្នុងការឃើញថារង្វិលជុំមិនចាប់ផ្តើមទេ។ ខ្ញុំ​គិត​ថា​នេះ​ក៏​ជា​កំហុស​ដែរ ហើយ​កូដ​គួរ​តែ​ត្រូវ​បាន​សរសេរ​ខុស​គ្នា។

វាហាក់បីដូចជាយើងបានជួបប្រទះកំហុសស្រដៀងគ្នាដ៏ល្បីនោះ! កំហុសមួយបិទបាំងមួយទៀត :) ។

Fragment N7: ការប្រើទ្រនិចបន្ទាប់ពីផ្លាស់ទី

static Expected<bool> TestOptimizer(BugDriver &BD, std::unique_ptr<Module> Test,
                                    std::unique_ptr<Module> Safe) {
  outs() << "  Optimizing functions being tested: ";
  std::unique_ptr<Module> Optimized =
      BD.runPassesOn(Test.get(), BD.getPassesToRun());
  if (!Optimized) {
    errs() << " Error running this sequence of passes"
           << " on the input program!n";
    BD.setNewProgram(std::move(Test));                       // <=
    BD.EmitProgressBitcode(*Test, "pass-error", false);      // <=
    if (Error E = BD.debugOptimizerCrash())
      return std::move(E);
    return false;
  }
  ....
}

ការព្រមាន PVS-Studio៖ V522 [CWE-476] ការបដិសេធនៃទ្រនិចទ្រនិច 'ការធ្វើតេស្ត' អាចនឹងកើតឡើង។ Miscompilation.cpp 709

ស្ថានភាពដដែលម្តងទៀត។ ដំបូង មាតិការបស់វត្ថុត្រូវបានផ្លាស់ទី ហើយបន្ទាប់មកវាត្រូវបានគេប្រើដូចជាគ្មានអ្វីកើតឡើង។ ខ្ញុំឃើញស្ថានភាពនេះកាន់តែច្រើនឡើងៗជាញឹកញាប់នៅក្នុងកូដកម្មវិធីបន្ទាប់ពីចលនា semantics បានបង្ហាញខ្លួននៅក្នុង C ++ ។ នេះជាមូលហេតុដែលខ្ញុំស្រលាញ់ភាសា C++! មានវិធីថ្មីកាន់តែច្រើនឡើងក្នុងការបាញ់ជើងខ្លួនឯង។ ឧបករណ៍វិភាគ PVS-Studio នឹងតែងតែមានការងារ :) ។

បំណែក N8៖ ទ្រនិច​ទទេ

void FunctionDumper::dump(const PDBSymbolTypeFunctionArg &Symbol) {
  uint32_t TypeId = Symbol.getTypeId();
  auto Type = Symbol.getSession().getSymbolById(TypeId);
  if (Type)
    Printer << "<unknown-type>";
  else
    Type->dump(*this);
}

ការព្រមាន PVS-Studio៖ V522 [CWE-476] ការបដិសេធនៃទ្រនិចគ្មានន័យ 'ប្រភេទ' អាចកើតឡើង។ PrettyFunctionDumper.cpp ២៣៣

បន្ថែមពីលើឧបករណ៍ដោះស្រាយកំហុស មុខងារលុបការបោះពុម្ពជាធម្មតាមិនត្រូវបានសាកល្បងទេ។ យើង​មាន​ករណី​បែប​នេះ​នៅ​ចំពោះ​មុខ​យើង។ មុខងារកំពុងរង់ចាំអ្នកប្រើប្រាស់ ដែលជំនួសឱ្យការដោះស្រាយបញ្ហារបស់គាត់ នឹងត្រូវបង្ខំឱ្យជួសជុលវា។

ត្រឹមត្រូវ៖

if (Type)
  Type->dump(*this);
else
  Printer << "<unknown-type>";

បំណែក N9៖ ទ្រនិច​ទទេ

void SearchableTableEmitter::collectTableEntries(
    GenericTable &Table, const std::vector<Record *> &Items) {
  ....
  RecTy *Ty = resolveTypes(Field.RecType, TI->getType());
  if (!Ty)                                                              // <=
    PrintFatalError(Twine("Field '") + Field.Name + "' of table '" +
                    Table.Name + "' has incompatible type: " +
                    Ty->getAsString() + " vs. " +                       // <=
                    TI->getType()->getAsString());
   ....
}

ការព្រមាន PVS-Studio៖ V522 [CWE-476] ការបដិសេធនៃទ្រនិចគ្មានលេខ 'Ty' អាចកើតឡើង។ SearchableTableEmitter.cpp 614

ខ្ញុំ​គិត​ថា​អ្វី​គ្រប់​យ៉ាង​គឺ​ច្បាស់​លាស់ ហើយ​មិន​ទាមទារ​ការ​ពន្យល់​ទេ។

បំណែក N10៖ វាយអក្សរ

bool FormatTokenLexer::tryMergeCSharpNullConditionals() {
  ....
  auto &Identifier = *(Tokens.end() - 2);
  auto &Question = *(Tokens.end() - 1);
  ....
  Identifier->ColumnWidth += Question->ColumnWidth;
  Identifier->Type = Identifier->Type;                    // <=
  Tokens.erase(Tokens.end() - 1);
  return true;
}

ការព្រមាន PVS-Studio៖ V570 អថេរ 'Identifier->Type' ត្រូវបានកំណត់ទៅខ្លួនវាផ្ទាល់។ FormatTokenLexer.cpp 249

វាគ្មានចំណុចណាក្នុងការកំណត់អថេរទៅខ្លួនវាទេ។ ភាគច្រើនទំនងជាពួកគេចង់សរសេរ៖

Identifier->Type = Question->Type;

បំណែក N11: ការបំបែកគួរឱ្យសង្ស័យ

void SystemZOperand::print(raw_ostream &OS) const {
  switch (Kind) {
    break;
  case KindToken:
    OS << "Token:" << getToken();
    break;
  case KindReg:
    OS << "Reg:" << SystemZInstPrinter::getRegisterName(getReg());
    break;
  ....
}

ការព្រមាន PVS-Studio៖ V622 [CWE-478] ពិចារណាពិនិត្យមើលសេចក្តីថ្លែងការណ៍ 'ប្តូរ' ។ វាអាចទៅរួចដែលថាប្រតិបត្តិករ 'ករណី' ដំបូងត្រូវបានបាត់។ SystemZAsmParser.cpp 652

មានប្រតិបត្តិករគួរឱ្យសង្ស័យណាស់នៅដើមដំបូង បំបែក. តើអ្នកភ្លេចសរសេរអ្វីផ្សេងទៀតនៅទីនេះទេ?

Fragment N12៖ ពិនិត្យ​ទ្រនិច​មួយ​បន្ទាប់​ពី​ការ​បដិសេធ

InlineCost AMDGPUInliner::getInlineCost(CallSite CS) {
  Function *Callee = CS.getCalledFunction();
  Function *Caller = CS.getCaller();
  TargetTransformInfo &TTI = TTIWP->getTTI(*Callee);

  if (!Callee || Callee->isDeclaration())
    return llvm::InlineCost::getNever("undefined callee");
  ....
}

ការព្រមាន PVS-Studio៖ V595 [CWE-476] ទ្រនិច 'Callee' ត្រូវបានប្រើប្រាស់ មុនពេលវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 172, 174. AMDGPUInline.cpp 172

ចង្អុល Callee នៅ​ដើម​ដំបូង​ត្រូវ​បាន​គេ​បដិសេធ​នៅ​ពេល​ដែល​មុខងារ​ត្រូវ​បាន​ហៅ​ ទទួលបានTTI.

ហើយបន្ទាប់មកវាប្រែថាទ្រនិចនេះគួរតែត្រូវបានពិនិត្យសម្រាប់សមភាព nullptr:

if (!Callee || Callee->isDeclaration())

ប៉ុន្តែវាយឺតពេលហើយ…

Fragment N13 - N... : ពិនិត្យ​ទ្រនិច​បន្ទាប់​ពី​ការ​បដិសេធ

ស្ថានភាពដែលបានពិភាក្សានៅក្នុងបំណែកកូដពីមុនគឺមិនមានតែមួយទេ។ វាបង្ហាញនៅទីនេះ៖

static Value *optimizeDoubleFP(CallInst *CI, IRBuilder<> &B,
                               bool isBinary, bool isPrecise = false) {
  ....
  Function *CalleeFn = CI->getCalledFunction();
  StringRef CalleeNm = CalleeFn->getName();                 // <=
  AttributeList CalleeAt = CalleeFn->getAttributes();
  if (CalleeFn && !CalleeFn->isIntrinsic()) {               // <=
  ....
}

ការព្រមាន PVS-Studio៖ V595 [CWE-476] ទ្រនិច 'CalleeFn' ត្រូវបានប្រើប្រាស់មុនពេលវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 1079, 1081. SimplifyLibCalls.cpp 1079

ហើយនៅទីនេះ៖

void Sema::InstantiateAttrs(const MultiLevelTemplateArgumentList &TemplateArgs,
                            const Decl *Tmpl, Decl *New,
                            LateInstantiatedAttrVec *LateAttrs,
                            LocalInstantiationScope *OuterMostScope) {
  ....
  NamedDecl *ND = dyn_cast<NamedDecl>(New);
  CXXRecordDecl *ThisContext =
    dyn_cast_or_null<CXXRecordDecl>(ND->getDeclContext());         // <=
  CXXThisScopeRAII ThisScope(*this, ThisContext, Qualifiers(),
                             ND && ND->isCXXInstanceMember());     // <=
  ....
}

ការព្រមាន PVS-Studio៖ V595 [CWE-476] ទ្រនិច 'ND' ត្រូវបានប្រើមុនពេលវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 532, 534. SemaTemplateInstantiateDecl.cpp 532

ហើយនៅទីនេះ៖

• V595 [CWE-476] ទ្រនិច 'U' ត្រូវបានប្រើប្រាស់ មុនពេលវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 404, 407. DWARFormValue.cpp 404
• V595 [CWE-476] ទ្រនិច 'ND' ត្រូវបានប្រើប្រាស់ មុនពេលវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 2149, 2151. SemaTemplateInstantiate.cpp 2149

ហើយបន្ទាប់មក ខ្ញុំមិនចាប់អារម្មណ៍ក្នុងការសិក្សាការព្រមានជាមួយលេខ V595 ទេ។ ដូច្នេះ​ខ្ញុំ​មិន​ដឹង​ថា​តើ​មាន​កំហុស​ស្រដៀង​គ្នា​នេះ​បន្ថែម​ទៀត​ដែរ​ឬ​អត់​ក្រៅ​ពី​អ្វី​ដែល​បាន​រាយ​នៅ​ទីនេះ។ ភាគច្រើនទំនងជាមាន។

បំណែក N17, N18៖ ការផ្លាស់ប្តូរគួរឱ្យសង្ស័យ

static inline bool processLogicalImmediate(uint64_t Imm, unsigned RegSize,
                                           uint64_t &Encoding) {
  ....
  unsigned Size = RegSize;
  ....
  uint64_t NImms = ~(Size-1) << 1;
  ....
}

ការព្រមាន PVS-Studio៖ V629 [CWE-190] ពិចារណាពិនិត្យមើលកន្សោម '~(ទំហំ - 1) << 1' ។ ការផ្លាស់ប្តូរប៊ីតនៃតម្លៃ 32 ប៊ីតជាមួយនឹងការពង្រីកជាបន្តបន្ទាប់ទៅប្រភេទ 64 ប៊ីត។ AArch64AddressingModes.h ២៦០

វាប្រហែលជាមិនមែនជាកំហុសទេ ហើយលេខកូដដំណើរការយ៉ាងពិតប្រាកដដូចបំណង។ ប៉ុន្តែ​នេះ​ច្បាស់​ជា​កន្លែង​ដែល​គួរ​ឲ្យ​សង្ស័យ​ខ្លាំង ហើយ​ត្រូវ​ពិនិត្យ​មើល។

ចូរនិយាយថាអថេរ ទំហំ គឺស្មើនឹង 16 ហើយបន្ទាប់មកអ្នកនិពន្ធនៃកូដគ្រោងនឹងយកវាទៅជាអថេរ NImms តម្លៃ៖

1111111111111111111111111111111111111111111111111111111111100000

ទោះយ៉ាងណាក៏ដោយតាមពិតលទ្ធផលនឹងមានៈ

0000000000000000000000000000000011111111111111111111111111100000

ការពិតគឺថាការគណនាទាំងអស់កើតឡើងដោយប្រើប្រភេទ 32-bit unsigned ។ ហើយមានតែពេលនោះទេ ប្រភេទដែលមិនបានចុះហត្ថលេខា 32 ប៊ីតនេះនឹងត្រូវបានពង្រីកយ៉ាងជាក់ស្តែង uint64_t. ក្នុងករណីនេះ ប៊ីតដ៏សំខាន់បំផុតនឹងជាសូន្យ។

អ្នកអាចជួសជុលស្ថានភាពដូចនេះ៖

uint64_t NImms = ~static_cast<uint64_t>(Size-1) << 1;

ស្ថានភាពស្រដៀងគ្នា៖ V629 [CWE-190] ពិចារណាពិនិត្យមើលកន្សោម 'Immr << 6' ។ ការផ្លាស់ប្តូរប៊ីតនៃតម្លៃ 32 ប៊ីតជាមួយនឹងការពង្រីកជាបន្តបន្ទាប់ទៅប្រភេទ 64 ប៊ីត។ AArch64AddressingModes.h ២៦៩

បំណែក N19៖ បាត់ពាក្យគន្លឹះ ផ្សេងទៀត?

void AMDGPUAsmParser::cvtDPP(MCInst &Inst, const OperandVector &Operands) {
  ....
  if (Op.isReg() && Op.Reg.RegNo == AMDGPU::VCC) {
    // VOP2b (v_add_u32, v_sub_u32 ...) dpp use "vcc" token.
    // Skip it.
    continue;
  } if (isRegOrImmWithInputMods(Desc, Inst.getNumOperands())) {    // <=
    Op.addRegWithFPInputModsOperands(Inst, 2);
  } else if (Op.isDPPCtrl()) {
    Op.addImmOperands(Inst, 1);
  } else if (Op.isImm()) {
    // Handle optional arguments
    OptionalIdx[Op.getImmTy()] = I;
  } else {
    llvm_unreachable("Invalid operand type");
  }
  ....
}

ការព្រមាន PVS-Studio៖ V646 [CWE-670] ពិចារណាពិនិត្យមើលតក្កវិជ្ជារបស់កម្មវិធី។ វាអាចទៅរួចដែលពាក្យគន្លឹះ 'else' បាត់។ AMDGPUAsmParser.cpp 5655

មិនមានកំហុសនៅទីនេះទេ។ ចាប់តាំងពីពេលនោះមក - ប្លុកទីមួយ if បញ្ចប់នៅ បន្តបន្ទាប់មកវាមិនមានបញ្ហាទេ មានពាក្យគន្លឹះ ផ្សេងទៀត ឬ​មិន​មែន។ វិធីណាក៏ដោយ កូដនឹងដំណើរការដូចគ្នា។ នៅតែនឹក ផ្សេងទៀត ធ្វើឱ្យកូដកាន់តែមិនច្បាស់លាស់ និងគ្រោះថ្នាក់។ ប្រសិនបើនៅពេលអនាគត បន្ត បាត់ កូដនឹងចាប់ផ្តើមដំណើរការខុសគ្នាទាំងស្រុង។ នៅក្នុងគំនិតរបស់ខ្ញុំវាជាការល្អប្រសើរជាងមុនដើម្បីបន្ថែម ផ្សេងទៀត.

Fragment N20៖ វាយអក្សរបួនប្រភេទដូចគ្នា។

LLVM_DUMP_METHOD void Symbol::dump(raw_ostream &OS) const {
  std::string Result;
  if (isUndefined())
    Result += "(undef) ";
  if (isWeakDefined())
    Result += "(weak-def) ";
  if (isWeakReferenced())
    Result += "(weak-ref) ";
  if (isThreadLocalValue())
    Result += "(tlv) ";
  switch (Kind) {
  case SymbolKind::GlobalSymbol:
    Result + Name.str();                        // <=
    break;
  case SymbolKind::ObjectiveCClass:
    Result + "(ObjC Class) " + Name.str();      // <=
    break;
  case SymbolKind::ObjectiveCClassEHType:
    Result + "(ObjC Class EH) " + Name.str();   // <=
    break;
  case SymbolKind::ObjectiveCInstanceVariable:
    Result + "(ObjC IVar) " + Name.str();       // <=
    break;
  }
  OS << Result;
}

ការព្រមាន PVS-Studio៖

• V655 [CWE-480] ខ្សែត្រូវបានភ្ជាប់គ្នា ប៉ុន្តែមិនត្រូវបានប្រើប្រាស់ទេ។ ពិចារណាពិនិត្យមើលកន្សោម 'លទ្ធផល + Name.str()'។ Symbol.cpp ៣២
• V655 [CWE-480] ខ្សែត្រូវបានភ្ជាប់គ្នា ប៉ុន្តែមិនត្រូវបានប្រើប្រាស់ទេ។ ពិចារណាពិនិត្យមើលកន្សោម 'លទ្ធផល + "(ObjC Class)" + Name.str()'។ Symbol.cpp ៣៥
• V655 [CWE-480] ខ្សែត្រូវបានភ្ជាប់គ្នា ប៉ុន្តែមិនត្រូវបានប្រើប្រាស់ទេ។ ពិចារណាពិនិត្យមើលកន្សោម 'លទ្ធផល + "(ObjC Class EH)" + Name.str()' ។ Symbol.cpp ៣៨
• V655 [CWE-480] ខ្សែត្រូវបានភ្ជាប់គ្នា ប៉ុន្តែមិនត្រូវបានប្រើប្រាស់ទេ។ ពិចារណាពិនិត្យមើលកន្សោម 'លទ្ធផល + "(ObjC IVar)" + Name.str()' ។ Symbol.cpp ៤១

ដោយចៃដន្យ ប្រតិបត្តិករ + ត្រូវបានប្រើជំនួសឱ្យ += operator ។ លទ្ធផលគឺការរចនាដែលមិនមានអត្ថន័យ។

Fragment N21៖ ឥរិយាបទដែលមិនបានកំណត់

static void getReqFeatures(std::map<StringRef, int> &FeaturesMap,
                           const std::vector<Record *> &ReqFeatures) {
  for (auto &R : ReqFeatures) {
    StringRef AsmCondString = R->getValueAsString("AssemblerCondString");

    SmallVector<StringRef, 4> Ops;
    SplitString(AsmCondString, Ops, ",");
    assert(!Ops.empty() && "AssemblerCondString cannot be empty");

    for (auto &Op : Ops) {
      assert(!Op.empty() && "Empty operator");
      if (FeaturesMap.find(Op) == FeaturesMap.end())
        FeaturesMap[Op] = FeaturesMap.size();
    }
  }
}

ព្យាយាមស្វែងរកលេខកូដគ្រោះថ្នាក់ដោយខ្លួនឯង។ ហើយ​នេះ​ជា​រូបភាព​ដើម្បី​បង្វែរ​ការ​ចាប់​អារម្មណ៍​ដើម្បី​កុំ​ឲ្យ​ក្រឡេក​មើល​ចម្លើយ​ភ្លាមៗ៖

ការព្រមាន PVS-Studio៖ V708 [CWE-758] សំណង់គ្រោះថ្នាក់ត្រូវបានប្រើប្រាស់៖ 'FeaturesMap[Op] = FeaturesMap.size()' ដែល 'FeaturesMap' ជាថ្នាក់ 'map'។ នេះអាចនាំឱ្យមានអាកប្បកិរិយាដែលមិនបានកំណត់។ RISCVCompressInstEmitter.cpp 490

បន្ទាត់បញ្ហា៖

FeaturesMap[Op] = FeaturesMap.size();

ប្រសិនបើធាតុ Op រកមិនឃើញទេ បន្ទាប់មកធាតុថ្មីត្រូវបានបង្កើតនៅក្នុងផែនទី ហើយចំនួនធាតុនៅក្នុងផែនទីនេះត្រូវបានសរសេរនៅទីនោះ។ វាគ្រាន់តែមិនដឹងថាតើមុខងារនឹងត្រូវបានហៅ ទំហំ មុន ឬក្រោយពេលបន្ថែមធាតុថ្មី។

បំណែក N22-N24៖ កិច្ចការដដែលៗ

Error MachOObjectFile::checkSymbolTable() const {
  ....
  } else {
    MachO::nlist STE = getSymbolTableEntry(SymDRI);
    NType = STE.n_type;                              // <=
    NType = STE.n_type;                              // <=
    NSect = STE.n_sect;
    NDesc = STE.n_desc;
    NStrx = STE.n_strx;
    NValue = STE.n_value;
  }
  ....
}

ការព្រមាន PVS-Studio៖ V519 [CWE-563] អថេរ 'NType' ត្រូវបានផ្តល់តម្លៃពីរដងជាប់ៗគ្នា។ ប្រហែលជានេះគឺជាកំហុសមួយ។ ពិនិត្យបន្ទាត់៖ 1663, 1664. MachOObjectFile.cpp 1664

ខ្ញុំមិនគិតថាមានកំហុសពិតប្រាកដនៅទីនេះទេ។ គ្រាន់តែជាកិច្ចការដដែលៗដែលមិនចាំបាច់។ ប៉ុន្តែនៅតែជាកំហុស។

ដូចគ្នានេះដែរ៖

• V519 [CWE-563] អថេរ 'B.NDesc' ត្រូវបានផ្តល់តម្លៃពីរដងជាប់ៗគ្នា។ ប្រហែលជានេះគឺជាកំហុសមួយ។ ពិនិត្យបន្ទាត់៖ 1488, 1489. llvm-nm.cpp 1489
• V519 [CWE-563] អថេរត្រូវបានផ្តល់តម្លៃពីរដងជាប់ៗគ្នា។ ប្រហែលជានេះគឺជាកំហុសមួយ។ ពិនិត្យបន្ទាត់: 59, 61. coff2yaml.cpp 61

បំណែក N25-N27៖ ការចាត់តាំងបន្ថែមទៀត

ឥឡូវនេះ សូមក្រឡេកមើលកំណែខុសគ្នាបន្តិចនៃការចាត់តាំងឡើងវិញ។

bool Vectorizer::vectorizeLoadChain(
    ArrayRef<Instruction *> Chain,
    SmallPtrSet<Instruction *, 16> *InstructionsProcessed) {
  ....
  unsigned Alignment = getAlignment(L0);
  ....
  unsigned NewAlign = getOrEnforceKnownAlignment(L0->getPointerOperand(),
                                                 StackAdjustedAlignment,
                                                 DL, L0, nullptr, &DT);
  if (NewAlign != 0)
    Alignment = NewAlign;
  Alignment = NewAlign;
  ....
}

ការព្រមាន PVS-Studio៖ V519 [CWE-563] អថេរ 'តម្រឹម' ត្រូវបានផ្តល់តម្លៃពីរដងជាប់ៗគ្នា។ ប្រហែលជានេះគឺជាកំហុសមួយ។ ពិនិត្យបន្ទាត់៖ 1158, 1160. LoadStoreVectorizer.cpp 1160

នេះ​ជា​កូដ​ចម្លែក​ណាស់​ដែល​ទំនង​ជា​មាន​កំហុស​ឡូជីខល។ នៅដើម, ប្រែប្រួល តម្រឹម តម្លៃត្រូវបានកំណត់អាស្រ័យលើលក្ខខណ្ឌ។ ហើយបន្ទាប់មកកិច្ចការកើតឡើងម្តងទៀត ប៉ុន្តែឥឡូវនេះដោយគ្មានការត្រួតពិនិត្យណាមួយឡើយ។

ស្ថានភាពស្រដៀងគ្នានេះអាចមើលឃើញនៅទីនេះ៖

• V519 [CWE-563] អថេរ 'Effects' ត្រូវបានផ្តល់តម្លៃពីរដងជាប់ៗគ្នា។ ប្រហែលជានេះគឺជាកំហុសមួយ។ ពិនិត្យបន្ទាត់៖ 152, 165. WebAssemblyRegStackify.cpp 165
• V519 [CWE-563] អថេរ 'ExpectNoDerefChunk' ត្រូវបានផ្តល់តម្លៃពីរដងជាប់ៗគ្នា។ ប្រហែលជានេះគឺជាកំហុសមួយ។ ពិនិត្យបន្ទាត់៖ 4970, 4973. SemaType.cpp 4973

បំណែក N28៖ លក្ខខណ្ឌពិតជានិច្ច

static int readPrefixes(struct InternalInstruction* insn) {
  ....
  uint8_t byte = 0;
  uint8_t nextByte;
  ....
  if (byte == 0xf3 && (nextByte == 0x88 || nextByte == 0x89 ||
                       nextByte == 0xc6 || nextByte == 0xc7)) {
    insn->xAcquireRelease = true;
    if (nextByte != 0x90) // PAUSE instruction support             // <=
      break;
  }
  ....
}

ការព្រមាន PVS-Studio៖ V547 [CWE-571] កន្សោម 'nextByte != 0x90' គឺតែងតែជាការពិត។ X86DisassemblerDecoder.cpp 379

ការត្រួតពិនិត្យមិនសមហេតុផលទេ។ អថេរ បៃបន្ទាប់ តែងតែមិនស្មើនឹងតម្លៃ 0x90ដែលបន្តពីការត្រួតពិនិត្យមុន។ នេះគឺជាប្រភេទនៃកំហុសឡូជីខលមួយចំនួន។

Fragment N29 - N...: តែងតែមានលក្ខខណ្ឌពិត/មិនពិត

អ្នកវិភាគចេញការព្រមានជាច្រើនថា ស្ថានភាពទាំងមូល (V547) ឬផ្នែករបស់វា (V560) គឺតែងតែពិតឬមិនពិត។ ជារឿយៗទាំងនេះមិនមែនជាកំហុសពិតទេ ប៉ុន្តែគ្រាន់តែកូដ sloppy លទ្ធផលនៃការពង្រីកម៉ាក្រូ និងផ្សេងទៀត។ ទោះជាយ៉ាងណាក៏ដោយ វាសមហេតុផលក្នុងការមើលការព្រមានទាំងអស់នេះ ចាប់តាំងពីកំហុសឡូជីខលពិតប្រាកដកើតឡើងពីពេលមួយទៅពេលមួយ។ ឧទាហរណ៍ ផ្នែកនៃកូដនេះគឺគួរឱ្យសង្ស័យ៖

static DecodeStatus DecodeGPRPairRegisterClass(MCInst &Inst, unsigned RegNo,
                                   uint64_t Address, const void *Decoder) {
  DecodeStatus S = MCDisassembler::Success;

  if (RegNo > 13)
    return MCDisassembler::Fail;

  if ((RegNo & 1) || RegNo == 0xe)
     S = MCDisassembler::SoftFail;
  ....
}

ការព្រមាន PVS-Studio៖ V560 [CWE-570] ផ្នែកមួយនៃកន្សោមតាមលក្ខខណ្ឌតែងតែមិនពិត៖ RegNo == 0xe ។ ARMDisassembler.cpp 939

0xE ថេរគឺជាតម្លៃ 14 ក្នុងទសភាគ។ ការប្រឡង RegNo == 0xe មិនសមហេតុផលទេព្រោះប្រសិនបើ លេខចុះបញ្ជី > ១៣បន្ទាប់មកមុខងារនឹងបញ្ចប់ការប្រតិបត្តិរបស់វា។

មានការព្រមានជាច្រើនផ្សេងទៀតដែលមានលេខសម្គាល់ V547 និង V560 ប៉ុន្តែដូចជាមួយដែរ។ V595ខ្ញុំមិនចាប់អារម្មណ៍ក្នុងការសិក្សាការព្រមានទាំងនេះទេ។ វាច្បាស់ហើយថាខ្ញុំមានសម្ភារៈគ្រប់គ្រាន់ដើម្បីសរសេរអត្ថបទ :) ។ ដូច្នេះវាមិនដឹងថាមានកំហុសប៉ុន្មាននៃប្រភេទនេះអាចត្រូវបានកំណត់អត្តសញ្ញាណនៅក្នុង LLVM ដោយប្រើ PVS-Studio ។

ខ្ញុំនឹងផ្តល់ឱ្យអ្នកនូវឧទាហរណ៍អំពីមូលហេតុដែលការសិក្សាគន្លឹះទាំងនេះគួរឱ្យធុញ។ អ្នកវិភាគពិតជាត្រឹមត្រូវក្នុងការចេញការព្រមានសម្រាប់កូដខាងក្រោម។ ប៉ុន្តែនេះមិនមែនជាកំហុសទេ។

bool UnwrappedLineParser::parseBracedList(bool ContinueOnSemicolons,
                                          tok::TokenKind ClosingBraceKind) {
  bool HasError = false;
  ....
  HasError = true;
  if (!ContinueOnSemicolons)
    return !HasError;
  ....
}

ការព្រមាន PVS-Studio៖ V547 [CWE-570] កន្សោម '!HasError' គឺតែងតែមិនពិត។ UnwrappedLineParser.cpp 1635

Fragment N30: ​​​ការ​ត្រឡប់​មក​វិញ​គួរ​ឱ្យ​សង្ស័យ

static bool
isImplicitlyDef(MachineRegisterInfo &MRI, unsigned Reg) {
  for (MachineRegisterInfo::def_instr_iterator It = MRI.def_instr_begin(Reg),
      E = MRI.def_instr_end(); It != E; ++It) {
    return (*It).isImplicitDef();
  }
  ....
}

ការព្រមាន PVS-Studio៖ V612 [CWE-670] 'ការត្រឡប់មកវិញ' ដោយគ្មានលក្ខខណ្ឌនៅក្នុងរង្វិលជុំមួយ។ R600OptimizeVectorRegisters.cpp ៦៣

នេះ​ជា​កំហុស ឬ​បច្ចេកទេស​ជាក់លាក់​មួយ​ដែល​មាន​បំណង​ពន្យល់​អ្វី​មួយ​ដល់​អ្នក​សរសេរ​កម្មវិធី​ដែល​អាន​កូដ។ ការរចនានេះមិនពន្យល់អ្វីដល់ខ្ញុំទេ ហើយមើលទៅគួរឱ្យសង្ស័យណាស់។ យកល្អកុំសរសេរបែបហ្នឹង :)

ធុញទ្រាន់? បន្ទាប់មក ដល់ពេលធ្វើតែ ឬកាហ្វេ។

ពិការភាពដែលកំណត់ដោយរោគវិនិច្ឆ័យថ្មី។

ខ្ញុំគិតថាការធ្វើឱ្យសកម្មចំនួន 30 នៃការវិនិច្ឆ័យចាស់គឺគ្រប់គ្រាន់ហើយ។ ឥឡូវនេះសូមមើលអ្វីដែលគួរឱ្យចាប់អារម្មណ៍អាចត្រូវបានរកឃើញជាមួយនឹងការធ្វើរោគវិនិច្ឆ័យថ្មីដែលបានបង្ហាញខ្លួននៅក្នុងឧបករណ៍វិភាគបន្ទាប់ពី មុន ពិនិត្យ។ សរុបមក ការវិនិច្ឆ័យគោលបំណងទូទៅចំនួន 66 ត្រូវបានបន្ថែមទៅឧបករណ៍វិភាគ C++ ក្នុងអំឡុងពេលនេះ។

Fragment N31៖ លេខកូដមិនអាចចូលបាន។

Error CtorDtorRunner::run() {
  ....
  if (auto CtorDtorMap =
          ES.lookup(JITDylibSearchList({{&JD, true}}), std::move(Names),
                    NoDependenciesToRegister, true))
  {
    ....
    return Error::success();
  } else
    return CtorDtorMap.takeError();

  CtorDtorsByPriority.clear();

  return Error::success();
}

ការព្រមាន PVS-Studio៖ V779 [CWE-561] បានរកឃើញលេខកូដដែលមិនអាចទៅដល់បាន។ វាអាចទៅរួចដែលថាមានកំហុស។ ExecutionUtils.cpp ១៤៦

ដូចដែលអ្នកអាចឃើញសាខាទាំងពីរនៃប្រតិបត្តិករ if បញ្ចប់ដោយការហៅទៅកាន់ប្រតិបត្តិករ ត្រឡប់មកវិញ. ដូច្នោះហើយធុង CtorDtorsByPriority នឹងមិនដែលត្រូវបានជម្រះឡើយ។

Fragment N32៖ លេខកូដមិនអាចចូលបាន។

bool LLParser::ParseSummaryEntry() {
  ....
  switch (Lex.getKind()) {
  case lltok::kw_gv:
    return ParseGVEntry(SummaryID);
  case lltok::kw_module:
    return ParseModuleEntry(SummaryID);
  case lltok::kw_typeid:
    return ParseTypeIdEntry(SummaryID);                        // <=
    break;                                                     // <=
  default:
    return Error(Lex.getLoc(), "unexpected summary kind");
  }
  Lex.setIgnoreColonInIdentifiers(false);                      // <=
  return false;
}

ការព្រមាន PVS-Studio៖ V779 [CWE-561] បានរកឃើញលេខកូដដែលមិនអាចទាក់ទងបាន។ វាអាចទៅរួចដែលថាមានកំហុស។ LLParser.cpp 835

ស្ថានភាពគួរឱ្យចាប់អារម្មណ៍។ តោះទៅមើលកន្លែងនេះជាមុនសិន៖

return ParseTypeIdEntry(SummaryID);
break;

នៅ glance ដំបូង វាហាក់ដូចជាមិនមានកំហុសនៅទីនេះទេ។ វាមើលទៅដូចជាប្រតិបត្តិករ បំបែក មានការបន្ថែមមួយនៅទីនេះ ហើយអ្នកអាចលុបវាបានយ៉ាងសាមញ្ញ។ ទោះយ៉ាងណាក៏ដោយមិនមែនទាំងអស់សាមញ្ញទេ។

អ្នកវិភាគចេញការព្រមាននៅលើបន្ទាត់៖

Lex.setIgnoreColonInIdentifiers(false);
return false;

ហើយជាការពិតណាស់ លេខកូដនេះមិនអាចទៅដល់បានទេ។ ករណីទាំងអស់នៅក្នុង ការផ្លាស់ប្តូរ បញ្ចប់ដោយការហៅពីប្រតិបត្តិករ ត្រឡប់មកវិញ. ហើយ​ឥឡូវ​នេះ​នៅ​ម្នាក់​ឯង​គ្មាន​ន័យ​ បំបែក មើល​ទៅ​មិន​គ្រោះថ្នាក់​សោះ! ប្រហែលជាសាខាមួយគួរតែបញ្ចប់ដោយ បំបែកមិនមែននៅលើទេ ត្រឡប់មកវិញ?

Fragment N33៖ កំណត់ឡើងវិញដោយចៃដន្យនៃប៊ីតខ្ពស់។

unsigned getStubAlignment() override {
  if (Arch == Triple::systemz)
    return 8;
  else
    return 1;
}

Expected<unsigned>
RuntimeDyldImpl::emitSection(const ObjectFile &Obj,
                             const SectionRef &Section,
                             bool IsCode) {
  ....
  uint64_t DataSize = Section.getSize();
  ....
  if (StubBufSize > 0)
    DataSize &= ~(getStubAlignment() - 1);
  ....
}

ការព្រមាន PVS-Studio៖ V784 ទំហំនៃរបាំងប៊ីតគឺតិចជាងទំហំនៃ operand ដំបូង។ នេះនឹងបណ្តាលឱ្យបាត់បង់ប៊ីតខ្ពស់។ RuntimeDyld.cpp 815

សូមចំណាំថាមុខងារ getStubAlignment ប្រភេទត្រឡប់មកវិញ មិនបានចុះហត្ថលេខា. ចូរយើងគណនាតម្លៃនៃកន្សោម ដោយសន្មតថាអនុគមន៍ត្រឡប់តម្លៃ ៨៖

~(getStubAlignment() - 1)

~(8u-1)

0xFFFFFFFF8u

ឥឡូវកត់សំគាល់ថាអថេរ ទំហំទិន្នន័យ មានប្រភេទ 64 ប៊ីតដែលមិនបានចុះហត្ថលេខា។ វាប្រែថានៅពេលអនុវត្តប្រតិបត្តិការ DataSize & 0xFFFFFFFF8u រាល់ប៊ីតលំដាប់ខ្ពស់សាមសិបពីរនឹងត្រូវបានកំណត់ឡើងវិញទៅសូន្យ។ ភាគច្រើន នេះមិនមែនជាអ្វីដែលអ្នកសរសេរកម្មវិធីចង់បាននោះទេ។ ខ្ញុំសង្ស័យថាគាត់ចង់គណនា៖ DataSize & 0xFFFFFFFFFFFFFF8u ។

ដើម្បីជួសជុលកំហុស អ្នកគួរតែសរសេរនេះ៖

DataSize &= ~(static_cast<uint64_t>(getStubAlignment()) - 1);

ឬអញ្ចឹង៖

DataSize &= ~(getStubAlignment() - 1ULL);

Fragment N34៖ បរាជ័យក្នុងការសម្ដែងប្រភេទជាក់លាក់

template <typename T>
void scaleShuffleMask(int Scale, ArrayRef<T> Mask,
                      SmallVectorImpl<T> &ScaledMask) {
  assert(0 < Scale && "Unexpected scaling factor");
  int NumElts = Mask.size();
  ScaledMask.assign(static_cast<size_t>(NumElts * Scale), -1);
  ....
}

ការព្រមាន PVS-Studio៖ V1028 [CWE-190] លទ្ធភាពហូរហៀរ។ ពិចារណា​ការ​បញ្ជូន​ប្រតិបត្តិករ​នៃ​ប្រតិបត្តិករ 'NumElts * Scale' ទៅ​ជា​ប្រភេទ 'size_t' មិនមែន​លទ្ធផល​ទេ។ X86ISelLowering.h 1577

ការដេញប្រភេទជាក់លាក់ត្រូវបានប្រើដើម្បីជៀសវាងការហៀរចេញនៅពេលគុណនឹងអថេរប្រភេទ int. ទោះជាយ៉ាងណាក៏ដោយ ការសម្ដែងប្រភេទជាក់លាក់នៅទីនេះមិនការពារប្រឆាំងនឹងការហៀរចេញទេ។ ដំបូង អថេរនឹងត្រូវបានគុណ ហើយមានតែលទ្ធផល 32 ប៊ីតនៃការគុណនឹងពង្រីកទៅប្រភេទ ទំហំ _t.

បំណែក N35៖ ការចម្លងបិទភ្ជាប់មិនបានជោគជ័យ

Instruction *InstCombiner::visitFCmpInst(FCmpInst &I) {
  ....
  if (!match(Op0, m_PosZeroFP()) && isKnownNeverNaN(Op0, &TLI)) {
    I.setOperand(0, ConstantFP::getNullValue(Op0->getType()));
    return &I;
  }
  if (!match(Op1, m_PosZeroFP()) && isKnownNeverNaN(Op1, &TLI)) {
    I.setOperand(1, ConstantFP::getNullValue(Op0->getType()));        // <=
    return &I;
  }
  ....
}

V778 [CWE-682] បំណែកកូដស្រដៀងគ្នាពីរត្រូវបានរកឃើញ។ ប្រហែលជា នេះជាការវាយអក្សរ ហើយអថេរ 'Op1' គួរតែត្រូវបានប្រើជំនួសឱ្យ 'Op0'។ InstCombineCompares.cpp 5507

ការវិនិច្ឆ័យគួរឱ្យចាប់អារម្មណ៍ថ្មីនេះកំណត់ស្ថានភាពដែលបំណែកនៃកូដត្រូវបានចម្លង ហើយឈ្មោះមួយចំនួននៅក្នុងវាបានចាប់ផ្តើមត្រូវបានផ្លាស់ប្តូរ ប៉ុន្តែនៅកន្លែងមួយពួកគេមិនបានកែវាទេ។

សូមចំណាំថានៅក្នុងប្លុកទីពីរពួកគេបានផ្លាស់ប្តូរ op0 នៅលើ op1. ប៉ុន្តែ​នៅ​កន្លែង​មួយ​គេ​មិន​បាន​ជួសជុល​វា​ទេ។ ភាគច្រើនទំនងជាវាត្រូវបានសរសេរដូចនេះ៖

if (!match(Op1, m_PosZeroFP()) && isKnownNeverNaN(Op1, &TLI)) {
  I.setOperand(1, ConstantFP::getNullValue(Op1->getType()));
  return &I;
}

បំណែក N36៖ ភាពច្របូកច្របល់អថេរ

struct Status {
  unsigned Mask;
  unsigned Mode;

  Status() : Mask(0), Mode(0){};

  Status(unsigned Mask, unsigned Mode) : Mask(Mask), Mode(Mode) {
    Mode &= Mask;
  };
  ....
};

ការព្រមាន PVS-Studio៖ V1001 [CWE-563] អថេរ 'របៀប' ត្រូវបានចាត់តាំង ប៉ុន្តែមិនត្រូវបានប្រើដោយចុងបញ្ចប់នៃអនុគមន៍ទេ។ SIModeRegister.cpp ៤៨

វាមានះថាក់យា៉ងខាំងណាស់ក្នុងការផ្តល់អាគុយម៉ង់មុខងារនូវឈ្មោះដូចគ្នានឹងសមាជិកថ្នាក់។ វាងាយស្រួលណាស់ក្នុងការយល់ច្រឡំ។ យើង​មាន​ករណី​បែប​នេះ​នៅ​ចំពោះ​មុខ​យើង។ ការបញ្ចេញមតិនេះមិនសមហេតុផលទេ៖

Mode &= Mask;

អាគុយម៉ង់មុខងារផ្លាស់ប្តូរ។ អស់ហើយ។ អាគុយម៉ង់នេះមិនត្រូវបានប្រើទៀតទេ។ ភាគច្រើនអ្នកគួរសរសេរវាដូចនេះ៖

Status(unsigned Mask, unsigned Mode) : Mask(Mask), Mode(Mode) {
  this->Mode &= Mask;
};

បំណែក N37៖ ភាពច្របូកច្របល់អថេរ

class SectionBase {
  ....
  uint64_t Size = 0;
  ....
};

class SymbolTableSection : public SectionBase {
  ....
};

void SymbolTableSection::addSymbol(Twine Name, uint8_t Bind, uint8_t Type,
                                   SectionBase *DefinedIn, uint64_t Value,
                                   uint8_t Visibility, uint16_t Shndx,
                                   uint64_t Size) {
  ....
  Sym.Value = Value;
  Sym.Visibility = Visibility;
  Sym.Size = Size;
  Sym.Index = Symbols.size();
  Symbols.emplace_back(llvm::make_unique<Symbol>(Sym));
  Size += this->EntrySize;
}

ការព្រមាន PVS-Studio៖ V1001 [CWE-563] អថេរ 'ទំហំ' ត្រូវបានចាត់តាំង ប៉ុន្តែមិនត្រូវបានប្រើប្រាស់ដោយចុងបញ្ចប់នៃអនុគមន៍ទេ។ Object.cpp ៤២៤

ស្ថានភាពគឺស្រដៀងនឹងករណីមុន។ វាគួរតែត្រូវបានសរសេរថា:

this->Size += this->EntrySize;

បំណែក N38-N47៖ ពួកគេភ្លេចពិនិត្យសន្ទស្សន៍

ពីមុន យើងបានមើលឧទាហរណ៍នៃការកេះរោគវិនិច្ឆ័យ V595. ខ្លឹមសាររបស់វាគឺថាទ្រនិចត្រូវបានបដិសេធនៅដើមដំបូង ហើយបានតែធីកបន្ទាប់មកប៉ុណ្ណោះ។ ការធ្វើរោគវិនិច្ឆ័យវ័យក្មេង V1004 គឺផ្ទុយពីអត្ថន័យ ប៉ុន្តែក៏បង្ហាញពីកំហុសជាច្រើនផងដែរ។ វាកំណត់ស្ថានភាពដែលទ្រនិចត្រូវបានពិនិត្យនៅដើម ហើយបន្ទាប់មកភ្លេចធ្វើដូច្នេះ។ សូមក្រឡេកមើលករណីបែបនេះដែលរកឃើញនៅខាងក្នុង LLVM ។

int getGEPCost(Type *PointeeType, const Value *Ptr,
               ArrayRef<const Value *> Operands) {
  ....
  if (Ptr != nullptr) {                                            // <=
    assert(....);
    BaseGV = dyn_cast<GlobalValue>(Ptr->stripPointerCasts());
  }
  bool HasBaseReg = (BaseGV == nullptr);

  auto PtrSizeBits = DL.getPointerTypeSizeInBits(Ptr->getType());  // <=
  ....
}

ការព្រមាន PVS-Studio៖ V1004 [CWE-476] ទ្រនិច 'Ptr' ត្រូវបានប្រើដោយគ្មានសុវត្ថិភាព បន្ទាប់ពីវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 729, 738. TargetTransformInfoImpl.h 738

អថេរ ភីធី អាចស្មើគ្នា nullptrដូចដែលបានបង្ហាញដោយមូលប្បទានប័ត្រ៖

if (Ptr != nullptr)

ទោះយ៉ាងណាក៏ដោយ ខាងក្រោមទ្រនិចនេះត្រូវបានយោងដោយមិនមានការត្រួតពិនិត្យបឋម៖

auto PtrSizeBits = DL.getPointerTypeSizeInBits(Ptr->getType());

ចូរយើងពិចារណាករណីស្រដៀងគ្នាមួយទៀត។

llvm::DISubprogram *CGDebugInfo::getFunctionFwdDeclOrStub(GlobalDecl GD,
                                                          bool Stub) {
  ....
  auto *FD = dyn_cast<FunctionDecl>(GD.getDecl());
  SmallVector<QualType, 16> ArgTypes;
  if (FD)                                                                // <=
    for (const ParmVarDecl *Parm : FD->parameters())
      ArgTypes.push_back(Parm->getType());
  CallingConv CC = FD->getType()->castAs<FunctionType>()->getCallConv(); // <=
  ....
}

ការព្រមាន PVS-Studio៖ V1004 [CWE-476] ទ្រនិច 'FD' ត្រូវបានប្រើដោយគ្មានសុវត្ថិភាព បន្ទាប់ពីវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 3228, 3231. CGDebugInfo.cpp 3231

យកចិត្តទុកដាក់លើសញ្ញា FD. ខ្ញុំប្រាកដថាបញ្ហាគឺអាចមើលឃើញយ៉ាងច្បាស់ ហើយមិនត្រូវការការពន្យល់ពិសេសនោះទេ។

និងបន្ថែមទៀត៖

static void computePolynomialFromPointer(Value &Ptr, Polynomial &Result,
                                         Value *&BasePtr,
                                         const DataLayout &DL) {
  PointerType *PtrTy = dyn_cast<PointerType>(Ptr.getType());
  if (!PtrTy) {                                                   // <=
    Result = Polynomial();
    BasePtr = nullptr;
  }
  unsigned PointerBits =
      DL.getIndexSizeInBits(PtrTy->getPointerAddressSpace());     // <=
  ....
}

ការព្រមាន PVS-Studio៖ V1004 [CWE-476] ទ្រនិច 'PtrTy' ត្រូវបានប្រើដោយគ្មានសុវត្ថិភាព បន្ទាប់ពីវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 960, 965. InterleavedLoadCombinePass.cpp 965

តើធ្វើដូចម្តេចដើម្បីការពារខ្លួនអ្នកពីកំហុសបែបនេះ? យកចិត្តទុកដាក់បន្ថែមទៀតលើ Code-Review ហើយប្រើឧបករណ៍វិភាគឋិតិវន្ត PVS-Studio ដើម្បីពិនិត្យមើលកូដរបស់អ្នកឱ្យបានទៀងទាត់។

មិនមានចំណុចណាមួយក្នុងការដកស្រង់បំណែកកូដផ្សេងទៀតដែលមានកំហុសនៃប្រភេទនេះទេ។ ខ្ញុំនឹងទុកតែបញ្ជីនៃការព្រមាននៅក្នុងអត្ថបទ៖

• V1004 [CWE-476] ទ្រនិច 'Expr' ត្រូវបានប្រើដោយគ្មានសុវត្ថិភាព បន្ទាប់ពីវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 1049, 1078. DebugInfoMetadata.cpp 1078
• V1004 [CWE-476] ទ្រនិច 'PI' ត្រូវបានប្រើដោយគ្មានសុវត្ថិភាព បន្ទាប់ពីវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 733, 753. LegacyPassManager.cpp 753
• V1004 [CWE-476] ទ្រនិច 'StatepointCall' ត្រូវបានប្រើដោយគ្មានសុវត្ថិភាព បន្ទាប់ពីវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 4371, 4379. Verifier.cpp 4379
• V1004 [CWE-476] ទ្រនិច 'RV' ត្រូវបានប្រើដោយគ្មានសុវត្ថិភាព បន្ទាប់ពីវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់: 2263, 2268. TGParser.cpp 2268
• V1004 [CWE-476] ទ្រនិច 'CalleeFn' ត្រូវបានប្រើដោយគ្មានសុវត្ថិភាព បន្ទាប់ពីវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់៖ 1081, 1096. SimplifyLibCalls.cpp 1096
• V1004 [CWE-476] ទ្រនិច 'TC' ត្រូវបានប្រើដោយគ្មានសុវត្ថិភាព បន្ទាប់ពីវាត្រូវបានផ្ទៀងផ្ទាត់ប្រឆាំងនឹង nullptr ។ ពិនិត្យបន្ទាត់: 1819, 1824. Driver.cpp 1824

បំណែក N48-N60៖ មិនសំខាន់ ប៉ុន្តែមានពិការភាព (អាចលេចធ្លាយអង្គចងចាំ)

std::unique_ptr<IRMutator> createISelMutator() {
  ....
  std::vector<std::unique_ptr<IRMutationStrategy>> Strategies;
  Strategies.emplace_back(
      new InjectorIRStrategy(InjectorIRStrategy::getDefaultOps()));
  ....
}

ការព្រមាន PVS-Studio៖ V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅកុងតឺន័រ 'យុទ្ធសាស្រ្ត' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-isel-fuzzer.cpp ៥៨

ដើម្បីបន្ថែមធាតុមួយទៅចុងបញ្ចប់នៃធុងដូចជា std:: វ៉ិចទ័រ > អ្នក​មិន​អាច​គ្រាន់​តែ​សរសេរ​ xxx.push_back(X ថ្មី)ចាប់តាំងពីមិនមានការបំប្លែងដោយប្រយោលពី X* в std::unique_ptr.

ដំណោះស្រាយទូទៅគឺសរសេរ xxx.emplace_back(X ថ្មី)ចាប់តាំងពីវាចងក្រង: វិធីសាស្រ្ត emplace_back បង្កើតធាតុដោយផ្ទាល់ពីអាគុយម៉ង់របស់វា ហើយដូច្នេះអាចប្រើអ្នកសាងសង់ច្បាស់លាស់។

វាមិនមានសុវត្ថិភាពទេ។ ប្រសិនបើវ៉ិចទ័រពេញ នោះអង្គចងចាំត្រូវបានបែងចែកឡើងវិញ។ ប្រតិបត្តិការផ្លាស់ប្តូរទីតាំងអង្គចងចាំអាចបរាជ័យ ដែលបណ្តាលឱ្យមានការលើកលែង std::bad_alloc. ក្នុងករណីនេះ ទ្រនិចនឹងបាត់បង់ ហើយវត្ថុដែលបានបង្កើតនឹងមិនត្រូវបានលុបឡើយ។

ដំណោះស្រាយដែលមានសុវត្ថិភាពគឺត្រូវបង្កើត unique_ptrដែលនឹងជាម្ចាស់ទ្រនិច មុនពេលវ៉ិចទ័រព្យាយាមកំណត់ទីតាំងអង្គចងចាំឡើងវិញ៖

xxx.push_back(std::unique_ptr<X>(new X))

ចាប់តាំងពី C++14 អ្នកអាចប្រើ 'std::make_unique':

xxx.push_back(std::make_unique<X>())

ប្រភេទនៃពិការភាពនេះមិនសំខាន់សម្រាប់ LLVM ទេ។ ប្រសិនបើអង្គចងចាំមិនអាចបែងចែកបាន នោះកម្មវិធីចងក្រងនឹងបញ្ឈប់ជាធម្មតា។ ទោះយ៉ាងណាក៏ដោយសម្រាប់កម្មវិធីដែលមានរយៈពេលយូរ ម៉ោងធ្វើការដែលមិនគ្រាន់តែអាចបញ្ចប់ប្រសិនបើការបែងចែកអង្គចងចាំបរាជ័យ វាអាចជាកំហុសដ៏អាក្រក់ពិតប្រាកដ។

ដូច្នេះ ទោះបីជាកូដនេះមិនបង្កការគំរាមកំហែងជាក់ស្តែងចំពោះ LLVM ក៏ដោយ ខ្ញុំយល់ថាវាមានប្រយោជន៍ក្នុងការនិយាយអំពីគំរូកំហុសនេះហើយដែលអ្នកវិភាគ PVS-Studio បានរៀនដើម្បីកំណត់អត្តសញ្ញាណវា។

ការព្រមានផ្សេងទៀតនៃប្រភេទនេះ៖

• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅកុងតឺន័រ 'Passes' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ PassManager.h 546
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'AAs' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ AliasAnalysis.h ៣២៤
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'ធាតុ' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ DWARFDebugFrame.cpp 519
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'AllEdges' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ CFGMST.h ២៦៨
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'VMaps' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ SimpleLoopUnswitch.cpp ឆ្នាំ 2012
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'កំណត់ត្រា' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ FDRLogBuilder.h ៣០
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅកុងតឺន័រ 'PendingSubmodules' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ ModuleMap.cpp 810
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Objects' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ DebugMap.cpp ៨៨
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅកុងតឺន័រ 'យុទ្ធសាស្រ្ត' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-isel-fuzzer.cpp ៦០
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Modifiers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-stress.cpp ៦៨៥
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Modifiers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-stress.cpp ៦៨៥
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Modifiers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-stress.cpp ៦៨៥
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Modifiers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-stress.cpp ៦៨៥
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Modifiers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-stress.cpp ៦៨៥
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Modifiers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-stress.cpp ៦៨៥
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Modifiers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-stress.cpp ៦៨៥
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Modifiers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-stress.cpp ៦៨៥
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Modifiers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ llvm-stress.cpp ៦៨៥
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅកុងតឺន័រ 'Operands' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ GlobalISelEmitter.cpp ឆ្នាំ ១៩១១
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅធុង 'Stash' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ GlobalISelEmitter.cpp 2100
• V1023 [CWE-460] ទ្រនិចដោយគ្មានម្ចាស់ត្រូវបានបន្ថែមទៅកុងតឺន័រ 'Matchers' ដោយវិធីសាស្ត្រ 'emplace_back' ។ ការលេចធ្លាយអង្គចងចាំនឹងកើតឡើងក្នុងករណីមានករណីលើកលែង។ GlobalISelEmitter.cpp 2702

សេចក្តីសន្និដ្ឋាន

ខ្ញុំបានចេញការព្រមានសរុបចំនួន 60 ហើយបន្ទាប់មកឈប់។ តើមានពិការភាពផ្សេងទៀតដែលឧបករណ៍វិភាគ PVS-Studio រកឃើញនៅក្នុង LLVM ដែរឬទេ? បាទ​ឬ​ចាស​ខ្ញុំ​មាន។ ទោះជាយ៉ាងណាក៏ដោយ នៅពេលដែលខ្ញុំកំពុងសរសេរចេញនូវបំណែកកូដសម្រាប់អត្ថបទនោះ វាជាពេលល្ងាច ឬសូម្បីតែយប់ ហើយខ្ញុំបានសម្រេចចិត្តថាវាដល់ពេលដែលត្រូវហៅវាមួយថ្ងៃ។

ខ្ញុំសង្ឃឹមថាអ្នកបានរកឃើញវាគួរឱ្យចាប់អារម្មណ៍ ហើយនឹងចង់សាកល្បងឧបករណ៍វិភាគ PVS-Studio ។

អ្នក​អាច​ទាញ​យក​ឧបករណ៍​វិភាគ​និង​ទទួល​បាន​គ្រាប់​ចុច minesweeper នៅ ទំព័រនេះ.

សំខាន់បំផុត ប្រើការវិភាគឋិតិវន្តជាប្រចាំ។ ការត្រួតពិនិត្យតែម្តងអនុវត្តដោយពួកយើងក្នុងគោលបំណងដើម្បីធ្វើឱ្យពេញនិយមនូវវិធីសាស្រ្តនៃការវិភាគឋិតិវន្ត ហើយ PVS-Studio មិនមែនជាសេណារីយ៉ូធម្មតានោះទេ។

សូមសំណាងល្អក្នុងការកែលម្អគុណភាព និងភាពជឿជាក់នៃកូដរបស់អ្នក!

ប្រសិនបើអ្នកចង់ចែករំលែកអត្ថបទនេះជាមួយទស្សនិកជនដែលនិយាយភាសាអង់គ្លេស សូមប្រើតំណភ្ជាប់ការបកប្រែ៖ Andrey Karpov ។ ស្វែងរកកំហុសនៅក្នុង LLVM 8 ជាមួយ PVS-Studio.

ប្រភព: www.habr.com