ຊອກຫາແມງໄມ້ໃນ 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 ໄດ້ຖືກກວດສອບອີກເທື່ອຫນຶ່ງ, ແລະຄວາມຜິດພາດທີ່ພົບເຫັນໄດ້ຖືກແກ້ໄຂ. ໃນປັດຈຸບັນບົດຄວາມນີ້ຈະນໍາສະເຫນີ batch ໃຫມ່ຂອງຄວາມຜິດພາດ. ເປັນຫຍັງພົບບັກໃໝ່? ມີ 3 ເຫດຜົນສໍາລັບການນີ້:

1. ໂຄງການ LLVM ກໍາລັງພັດທະນາ, ປ່ຽນລະຫັດເກົ່າແລະເພີ່ມລະຫັດໃຫມ່. ຕາມທໍາມະຊາດ, ມີຂໍ້ຜິດພາດໃຫມ່ໃນລະຫັດດັດແກ້ແລະລາຍລັກອັກສອນ. ນີ້ສະແດງໃຫ້ເຫັນຢ່າງຊັດເຈນວ່າການວິເຄາະ static ຄວນຖືກນໍາໃຊ້ເປັນປົກກະຕິ, ແລະບໍ່ແມ່ນບາງຄັ້ງຄາວ. ບົດຄວາມຂອງພວກເຮົາສະແດງໃຫ້ເຫັນເຖິງຄວາມສາມາດຂອງເຄື່ອງວິເຄາະ PVS-Studio, ແຕ່ນີ້ບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບການປັບປຸງຄຸນນະພາບຂອງລະຫັດແລະການຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການແກ້ໄຂຂໍ້ຜິດພາດ. ໃຊ້ຕົວວິເຄາະລະຫັດສະຖິດເປັນປະຈຳ!
2. ພວກ​ເຮົາ​ກໍາ​ລັງ​ສໍາ​ເລັດ​ຮູບ​ແລະ​ປັບ​ປຸງ​ການ​ວິ​ນິດ​ໄສ​ທີ່​ມີ​ຢູ່​ແລ້ວ​. ດັ່ງນັ້ນ, ນັກວິເຄາະສາມາດກໍານົດຄວາມຜິດພາດທີ່ມັນບໍ່ໄດ້ສັງເກດເຫັນໃນລະຫວ່າງການສະແກນທີ່ຜ່ານມາ.
3. ການວິນິດໄສໃໝ່ໄດ້ປະກົດຢູ່ໃນ PVS-Studio ທີ່ບໍ່ມີຢູ່ 2 ປີກ່ອນ. ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈທີ່ຈະເນັ້ນໃຫ້ພວກເຂົາຢູ່ໃນພາກແຍກຕ່າງຫາກເພື່ອສະແດງໃຫ້ເຫັນຢ່າງຊັດເຈນການພັດທະນາຂອງ PVS-Studio.

ຂໍ້ບົກພ່ອງທີ່ຖືກກໍານົດໂດຍການວິນິດໄສທີ່ມີຢູ່ 2 ປີກ່ອນ

Fragment 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 73

ມັນຖືກກວດສອບສອງເທື່ອວ່າຊື່ເລີ່ມຕົ້ນດ້ວຍສາຍຍ່ອຍ "avx512.mask.permvar." ໃນການກວດສອບຄັ້ງທີສອງ, ແນ່ນອນພວກເຂົາຕ້ອງການຂຽນສິ່ງອື່ນ, ແຕ່ລືມແກ້ໄຂຂໍ້ຄວາມທີ່ຖືກຄັດລອກ.

Fragment 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 ແມ່ນອັນຕະລາຍຫຼາຍແລະ provokes ຄວາມຜິດພາດຢ່າງມີເຫດຜົນ. ຈົ່ງລະມັດລະວັງກັບມັນ ແລະຢ່າໂລບມາກກັບວົງເລັບ. ຂ້າພະເຈົ້າໄດ້ເບິ່ງຫົວຂໍ້ນີ້ໃນລາຍລະອຽດເພີ່ມເຕີມ ທີ່ນີ້, ໃນບົດ "ລະວັງຂອງ ?: ຜູ້ປະກອບການແລະປິດມັນຢູ່ໃນວົງເລັບ."

Fragment N4, N5: ຕົວຊີ້ Null

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] ການອ້າງອິງຕົວຊີ້ null 'LHS' ອາດຈະເກີດຂຶ້ນ. TGParser.cpp 2152

ຖ້າຕົວຊີ້ LHS ແມ່ນ null, ການເຕືອນໄພຄວນໄດ້ຮັບການອອກ. ແນວໃດກໍ່ຕາມ, ແທນທີ່ຈະ, ຕົວຊີ້ null ດຽວກັນນີ້ຈະຖືກອ້າງອີງ: LHS->getAsString().

ນີ້ແມ່ນສະຖານະການປົກກະຕິຫຼາຍເມື່ອຂໍ້ຜິດພາດຖືກເຊື່ອງໄວ້ໃນຕົວຈັດການຄວາມຜິດພາດ, ເພາະວ່າບໍ່ມີໃຜທົດສອບພວກມັນ. ການວິເຄາະຄົງທີ່ກວດເບິ່ງລະຫັດທີ່ສາມາດເຂົ້າເຖິງໄດ້ທັງຫມົດ, ບໍ່ວ່າມັນຖືກໃຊ້ເລື້ອຍໆເທົ່າໃດ. ນີ້ແມ່ນຕົວຢ່າງທີ່ດີຫຼາຍຂອງວິທີການວິເຄາະສະຖິດໃຫ້ສົມບູນແບບອື່ນໆໃນການທົດສອບແລະເຕັກນິກການປ້ອງກັນຄວາມຜິດພາດ.

ຄວາມຜິດພາດການຈັດການຕົວຊີ້ທີ່ຄ້າຍຄືກັນ ຮຮ ອະນຸຍາດໃຫ້ຢູ່ໃນລະຫັດຂ້າງລຸ່ມນີ້: V522 [CWE-476] ການປະຕິເສດຕົວຊີ້ null '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] ການປະຕິເສດການອ້າງອີງຂອງຕົວຊີ້ null 'ProgClone' ອາດຈະເກີດຂຶ້ນ. Miscompilation.cpp 601

ໃນຕອນເລີ່ມຕົ້ນຕົວຊີ້ທີ່ສະຫຼາດ ProgClone ຢຸດການເປັນເຈົ້າຂອງວັດຖຸ:

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

ໃນຄວາມເປັນຈິງ, ໃນປັດຈຸບັນ ProgClone ເປັນຕົວຊີ້ null. ດັ່ງນັ້ນ, ການອ້າງອີງຕົວຊີ້ null ຄວນເກີດຂຶ້ນຢູ່ຂ້າງລຸ່ມນີ້:

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

ແຕ່, ໃນຄວາມເປັນຈິງ, ນີ້ຈະບໍ່ເກີດຂຶ້ນ! ໃຫ້ສັງເກດວ່າ loop ບໍ່ໄດ້ຖືກປະຕິບັດຕົວຈິງ.

ໃນຕອນຕົ້ນຂອງຖັງ MiscompiledFunctions ລຶບລ້າງ:

MiscompiledFunctions.clear();

ຕໍ່ໄປ, ຂະຫນາດຂອງຖັງນີ້ຖືກນໍາໃຊ້ໃນສະພາບ loop:

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

ມັນງ່າຍທີ່ຈະເຫັນວ່າ loop ບໍ່ໄດ້ເລີ່ມຕົ້ນ. ຂ້າພະເຈົ້າຄິດວ່ານີ້ຍັງເປັນ bug ແລະລະຫັດຄວນຈະຖືກຂຽນແຕກຕ່າງກັນ.

ມັນເບິ່ງຄືວ່າພວກເຮົາໄດ້ພົບກັບຄວາມຜິດພາດທີ່ມີຊື່ສຽງນັ້ນ! ຄວາມຜິດພາດອັນໜຶ່ງປິດບັງອີກອັນໜຶ່ງ :).

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] ການປະຕິເສດການອ້າງອີງຂອງຕົວຊີ້ null 'ການທົດສອບ' ອາດຈະເກີດຂຶ້ນ. Miscompilation.cpp 709

ສະຖານະການດຽວກັນອີກເທື່ອຫນຶ່ງ. ໃນຕອນທໍາອິດ, ເນື້ອໃນຂອງວັດຖຸໄດ້ຖືກຍ້າຍ, ແລະຫຼັງຈາກນັ້ນມັນຖືກນໍາໃຊ້ຄືກັບວ່າບໍ່ມີຫຍັງເກີດຂຶ້ນ. ຂ້ອຍເຫັນສະຖານະການນີ້ເລື້ອຍໆໃນລະຫັດໂປຼແກຼມຫຼັງຈາກການເຄື່ອນໄຫວ semantics ປາກົດຢູ່ໃນ C ++. ນີ້ແມ່ນເຫດຜົນທີ່ຂ້ອຍຮັກພາສາ C ++! ມີວິທີໃໝ່ໆຫຼາຍຂຶ້ນເພື່ອຍິງຂາຂອງເຈົ້າເອງ. ເຄື່ອງວິເຄາະ PVS-Studio ສະເຫມີຈະມີການເຮັດວຽກ :).

Fragment N8: ຕົວຊີ້ Null

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] ການປະຕິເສດການອ້າງອີງຂອງຕົວຊີ້ null 'ປະເພດ' ອາດຈະເກີດຂຶ້ນ. PrettyFunctionDumper.cpp 233

ນອກເໜືອໄປຈາກຕົວຈັດການຂໍ້ຜິດພາດ, ການແກ້ບັນຫາການພິມອອກໜ້າປົກກະຕິແມ່ນບໍ່ໄດ້ທົດສອບ. ພວກເຮົາມີພຽງແຕ່ກໍລະນີດັ່ງກ່າວກ່ອນພວກເຮົາ. ຟັງຊັນແມ່ນລໍຖ້າຜູ້ໃຊ້, ຜູ້ທີ່, ແທນທີ່ຈະແກ້ໄຂບັນຫາຂອງລາວ, ຈະຖືກບັງຄັບໃຫ້ແກ້ໄຂ.

ຖືກຕ້ອງ:

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

Fragment N9: ຕົວຊີ້ Null

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] ການປະຕິເສດຕົວຊີ້ null 'Ty' ອາດຈະເກີດຂຶ້ນ. SearchableTableEmitter.cpp 614

ຂ້າພະເຈົ້າຄິດວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນຈະແຈ້ງແລະບໍ່ຮຽກຮ້ອງໃຫ້ມີຄໍາອະທິບາຍ.

Fragment 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;

Fragment 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

ຕົວຊີ້ວັດ ໂທ ໃນຕອນເລີ່ມຕົ້ນແມ່ນ dereferenced ໃນເວລາເອີ້ນວ່າຫນ້າທີ່ ໄດ້ຮັບTTI.

ແລະຫຼັງຈາກນັ້ນມັນ turns ໃຫ້ເຫັນວ່າຕົວຊີ້ນີ້ຄວນໄດ້ຮັບການກວດສອບຄວາມສະເຫມີພາບ 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. ສະນັ້ນຂ້ອຍບໍ່ຮູ້ວ່າມີຂໍ້ຜິດພາດທີ່ຄ້າຍຄືກັນຫຼາຍກວ່າທີ່ລະບຸໄວ້ຢູ່ທີ່ນີ້. ສ່ວນຫຼາຍອາດຈະເປັນ.

Fragment 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] ພິຈາລະນາກວດສອບການສະແດງອອກ '~(Size - 1) << 1'. ການປ່ຽນບິດຂອງຄ່າ 32-bit ດ້ວຍການຂະຫຍາຍຕໍ່ໄປເປັນປະເພດ 64-bit. AArch64AddressingModes.h 260

ມັນອາດຈະບໍ່ເປັນ bug ແລະລະຫັດເຮັດວຽກແນ່ນອນຕາມຈຸດປະສົງ. ແຕ່ນີ້ຢ່າງຊັດເຈນເປັນສະຖານທີ່ທີ່ຫນ້າສົງໄສຫຼາຍແລະຕ້ອງໄດ້ຮັບການກວດກາ.

ໃຫ້ເວົ້າວ່າຕົວແປ ເລືອກຂະຫນາດ ແມ່ນເທົ່າກັບ 16, ແລະຫຼັງຈາກນັ້ນຜູ້ຂຽນລະຫັດທີ່ວາງແຜນທີ່ຈະໄດ້ຮັບມັນຢູ່ໃນຕົວແປ NImms ຄວາມ​ຫມາຍ:

1111111111111111111111111111111111111111111111111111111111100000

ຢ່າງໃດກໍຕາມ, ໃນຄວາມເປັນຈິງ, ຜົນໄດ້ຮັບຈະເປັນ:

0000000000000000000000000000000011111111111111111111111111100000

ຄວາມຈິງແລ້ວແມ່ນວ່າການຄິດໄລ່ທັງຫມົດເກີດຂຶ້ນໂດຍໃຊ້ປະເພດ 32-bit unsigned. ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນ, ປະເພດ 32-bit unsigned ນີ້ຈະໄດ້ຮັບການຂະຫຍາຍ implicitly ກັບ uint64_t. ໃນກໍລະນີນີ້, bits ທີ່ສໍາຄັນທີ່ສຸດຈະເປັນສູນ.

ທ່ານສາມາດແກ້ໄຂສະຖານະການເຊັ່ນນີ້:

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

ສະຖານະການທີ່ຄ້າຍຄືກັນ: V629 [CWE-190] ພິຈາລະນາກວດສອບການສະແດງອອກ 'Immr << 6'. ການປ່ຽນບິດຂອງຄ່າ 32-bit ດ້ວຍການຂະຫຍາຍຕໍ່ໄປເປັນປະເພດ 64-bit. AArch64AddressingModes.h 269

Fragment 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] ພິຈາລະນາກວດສອບເຫດຜົນຂອງແອັບພລິເຄຊັນ. ມັນເປັນໄປໄດ້ວ່າຄໍາຫລັກ 'ອື່ນ' ຫາຍໄປ. AMDGPUAsmParser.cpp 5655

ບໍ່ມີຄວາມຜິດພາດຢູ່ທີ່ນີ້. ນັບຕັ້ງແຕ່ນັ້ນມາ, ຕັນຂອງຄັ້ງທໍາອິດ if ສິ້ນສຸດດ້ວຍ ດໍາເນີນການຕໍ່, ຫຼັງຈາກນັ້ນມັນບໍ່ສໍາຄັນ, ມີຄໍາສໍາຄັນ ອື່ນ ຫຼື​ບໍ່. ໃນກໍລະນີໃດກໍ່ຕາມ, ລະຫັດຈະເຮັດວຽກຄືກັນ. ຍັງພາດ ອື່ນ ເຮັດໃຫ້ລະຫັດບໍ່ຊັດເຈນແລະເປັນອັນຕະລາຍຫຼາຍ. ຖ້າໃນອະນາຄົດ ດໍາເນີນການຕໍ່ ຫາຍໄປ, ລະຫັດຈະເລີ່ມເຮັດວຽກແຕກຕ່າງກັນຫມົດ. ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍມັນດີກວ່າທີ່ຈະເພີ່ມ ອື່ນ.

Fragment N20: ສີ່ typos ຂອງປະເພດດຽວກັນ

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] ສາຍຖືກເຊື່ອມເຂົ້າກັນແຕ່ບໍ່ໄດ້ໃຊ້. ພິຈາລະນາກວດສອບການສະແດງອອກ 'Result + Name.str()'. Symbol.cpp 32
• V655 [CWE-480] ສາຍຖືກເຊື່ອມເຂົ້າກັນແຕ່ບໍ່ໄດ້ໃຊ້. ພິຈາລະນາກວດສອບການສະແດງອອກ 'Result + "(ObjC Class)" + Name.str()'. Symbol.cpp 35
• V655 [CWE-480] ສາຍຖືກເຊື່ອມເຂົ້າກັນແຕ່ບໍ່ໄດ້ໃຊ້. ພິຈາລະນາກວດສອບການສະແດງອອກ 'Result + "(ObjC Class EH)" + Name.str()'. Symbol.cpp 38
• V655 [CWE-480] ສາຍຖືກເຊື່ອມເຂົ້າກັນແຕ່ບໍ່ໄດ້ໃຊ້. ພິຈາລະນາກວດສອບການສະແດງອອກ 'Result + "(ObjC IVar)" + Name.str()'. Symbol.cpp 41

ໂດຍບັງເອີນ, ຕົວປະຕິບັດການ + ຖືກໃຊ້ແທນຕົວປະຕິບັດການ +=. ຜົນໄດ້ຮັບແມ່ນການອອກແບບທີ່ບໍ່ມີຄວາມຫມາຍ.

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' class. ນີ້ອາດຈະນໍາໄປສູ່ພຶດຕິກໍາທີ່ບໍ່ໄດ້ກໍານົດ. RISCVCompressInstEmitter.cpp 490

ເສັ້ນບັນຫາ:

FeaturesMap[Op] = FeaturesMap.size();

ຖ້າອົງປະກອບ Op ບໍ່ພົບ, ຫຼັງຈາກນັ້ນອົງປະກອບໃຫມ່ຖືກສ້າງຂື້ນໃນແຜນທີ່ແລະຈໍານວນຂອງອົງປະກອບໃນແຜນທີ່ນີ້ແມ່ນຂຽນຢູ່ທີ່ນັ້ນ. ມັນພຽງແຕ່ບໍ່ຮູ້ວ່າຈະເອີ້ນຟັງຊັນ ຂະຫນາດ ກ່ອນ ຫຼືຫຼັງຈາກເພີ່ມອົງປະກອບໃໝ່.

Fragment 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

Fragment 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] ຕົວແປ 'Alignment' ຖືກມອບຫມາຍຄ່າສອງຄັ້ງຕິດຕໍ່ກັນ. ບາງທີນີ້ແມ່ນຄວາມຜິດພາດ. ກວດສອບສາຍ: 1158, 1160. LoadStoreVectorizer.cpp 1160

ນີ້ແມ່ນລະຫັດທີ່ແປກປະຫຼາດຫຼາຍທີ່ປາກົດວ່າມີຄວາມຜິດພາດຢ່າງມີເຫດຜົນ. ໃນຕອນເລີ່ມຕົ້ນ, ມີການປ່ຽນແປງ ການຈັດຕໍາແຫນ່ງ ຄ່າຖືກມອບໝາຍຂຶ້ນກັບເງື່ອນໄຂ. ແລະຫຼັງຈາກນັ້ນການມອບຫມາຍເກີດຂຶ້ນອີກເທື່ອຫນຶ່ງ, ແຕ່ໃນປັດຈຸບັນໂດຍບໍ່ມີການກວດກາໃດໆ.

ສະຖານະການທີ່ຄ້າຍຄືກັນສາມາດເບິ່ງໄດ້ທີ່ນີ້:

• V519 [CWE-563] ຕົວແປ 'ຜົນກະທົບ' ຖືກມອບຫມາຍຄ່າສອງຄັ້ງຕໍ່ເນື່ອງ. ບາງທີນີ້ແມ່ນຄວາມຜິດພາດ. ກວດສອບເສັ້ນ: 152, 165. WebAssemblyRegStackify.cpp 165
• V519 [CWE-563] ຕົວແປ 'ExpectNoDerefChunk' ຖືກມອບໝາຍຄ່າສອງເທື່ອຕິດຕໍ່ກັນ. ບາງທີນີ້ແມ່ນຄວາມຜິດພາດ. ກວດສອບເສັ້ນ: 4970, 4973. SemaType.cpp 4973

Fragment 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

ການກວດສອບບໍ່ມີຄວາມຫມາຍ. ຕົວແປ NextByte ສະເຫມີບໍ່ເທົ່າກັບມູນຄ່າ 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 ບໍ່ມີຄວາມຫມາຍເພາະວ່າຖ້າ ເລກທະບຽນ > 13, ຫຼັງຈາກນັ້ນຟັງຊັນຈະສໍາເລັດການປະຕິບັດຂອງມັນ.

ມີການເຕືອນໄພອື່ນໆຈໍານວນຫຼາຍທີ່ມີ IDs 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 63

ນີ້ແມ່ນຄວາມຜິດພາດຫຼືເຕັກນິກສະເພາະທີ່ມີຈຸດປະສົງເພື່ອອະທິບາຍບາງສິ່ງບາງຢ່າງໃຫ້ນັກຂຽນໂປລແກລມອ່ານລະຫັດ. ການອອກແບບນີ້ບໍ່ໄດ້ອະທິບາຍຫຍັງໃຫ້ຂ້ອຍຮູ້ ແລະເບິ່ງຄືວ່າໜ້າສົງໄສຫຼາຍ. ມັນດີກວ່າທີ່ຈະບໍ່ຂຽນແບບນັ້ນ :).

ເມື່ອຍ? ຫຼັງຈາກນັ້ນ, ມັນເປັນເວລາທີ່ຈະເຮັດຊາຫຼືກາເຟ.

ຂໍ້ບົກພ່ອງທີ່ຖືກກໍານົດໂດຍການວິນິດໄສໃຫມ່

ຂ້າພະເຈົ້າຄິດວ່າການເປີດໃຊ້ 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 146

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ທັງສອງສາຂາຂອງຜູ້ປະຕິບັດງານ 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 ຂະຫນາດຂອງ bit mask ແມ່ນຫນ້ອຍກ່ວາຂະຫນາດຂອງ operand ທໍາອິດ. ນີ້ຈະເຮັດໃຫ້ການສູນເສຍ bits ທີ່ສູງຂຶ້ນ. RuntimeDyld.cpp 815

ກະລຸນາສັງເກດວ່າຫນ້າທີ່ getStubAlignment ປະເພດຜົນຕອບແທນ ລົງນາມ. ໃຫ້ຄິດໄລ່ຄ່າຂອງ expression ໂດຍສົມມຸດວ່າ function ໃຫ້ຄ່າ 8:

~(getStubAlignment() - 1)

~(8u-1)

0xFFFFFFFF8u

ໃນປັດຈຸບັນສັງເກດເຫັນວ່າຕົວແປ ຂະໜາດຂໍ້ມູນ ມີປະເພດ 64-bit unsigned. ມັນປະກົດວ່າເມື່ອປະຕິບັດການດໍາເນີນການ 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

ການໂຍນປະເພດທີ່ຊັດເຈນຖືກນໍາໃຊ້ເພື່ອຫຼີກເວັ້ນການ overflow ເມື່ອຄູນຕົວແປປະເພດ int. ຢ່າງໃດກໍ່ຕາມ, ການໂຍນປະເພດທີ່ຊັດເຈນຢູ່ທີ່ນີ້ບໍ່ໄດ້ປ້ອງກັນການລົ້ນ. ທໍາອິດ, ຕົວແປຈະຖືກຄູນ, ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນຜົນໄດ້ຮັບ 32-bit ຂອງການຄູນຈະຖືກຂະຫຍາຍໄປສູ່ປະເພດ. ຂະ ໜາດ.

Fragment 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] ສອງຊິ້ນລະຫັດທີ່ຄ້າຍຄືກັນໄດ້ຖືກພົບເຫັນ. ບາງທີ, ນີ້ແມ່ນ typo ແລະຕົວແປ 'Op1' ຄວນຖືກນໍາໃຊ້ແທນ 'Op0'. InstCombineCompares.cpp 5507

ການວິນິດໄສທີ່ຫນ້າສົນໃຈໃຫມ່ນີ້ກໍານົດສະຖານະການທີ່ຊິ້ນສ່ວນຂອງລະຫັດໄດ້ຖືກຄັດລອກແລະບາງຊື່ໃນມັນໄດ້ເລີ່ມມີການປ່ຽນແປງ, ແຕ່ຢູ່ໃນສະຖານທີ່ຫນຶ່ງພວກເຂົາບໍ່ໄດ້ແກ້ໄຂມັນ.

ກະລຸນາສັງເກດວ່າໃນບລັອກທີສອງພວກເຂົາໄດ້ປ່ຽນແປງ Op0 ສຸດ Op1. ແຕ່ຢູ່ໃນສະຖານທີ່ຫນຶ່ງພວກເຂົາບໍ່ໄດ້ແກ້ໄຂມັນ. ສ່ວນຫຼາຍອາດຈະຂຽນແບບນີ້:

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

Fragment 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 48

ມັນເປັນອັນຕະລາຍຫຼາຍທີ່ຈະໃຫ້ຂໍ້ໂຕ້ແຍ້ງຟັງຊັນຊື່ດຽວກັນກັບສະມາຊິກໃນຊັ້ນຮຽນ. ມັນງ່າຍຫຼາຍທີ່ຈະສັບສົນ. ພວກເຮົາມີພຽງແຕ່ກໍລະນີດັ່ງກ່າວກ່ອນພວກເຮົາ. ການສະແດງອອກນີ້ບໍ່ມີຄວາມຫມາຍ:

Mode &= Mask;

ອາກິວເມັນຟັງຊັນປ່ຽນແປງ. ຫມົດ​ເທົ່າ​ນີ້. ການໂຕ້ຖຽງນີ້ບໍ່ໄດ້ໃຊ້ອີກຕໍ່ໄປ. ສ່ວນຫຼາຍແລ້ວ ເຈົ້າຄວນຂຽນແບບນີ້:

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

Fragment 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 424

ສະຖານະການແມ່ນຄ້າຍຄືກັນກັບທີ່ຜ່ານມາ. ມັນຄວນຈະຂຽນວ່າ:

this->Size += this->EntrySize;

Fragment 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

ຕົວປ່ຽນແປງ Ptr ອາດຈະເທົ່າທຽມກັນ nullptrດັ່ງທີ່ພິສູດໄດ້ວ່າ:

if (Ptr != nullptr)

ຢ່າງໃດກໍຕາມ, ຂ້າງລຸ່ມນີ້ຕົວຊີ້ນີ້ແມ່ນ dereferenceed ໂດຍບໍ່ມີການກວດສອບເບື້ອງຕົ້ນ:

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 58

ເພື່ອເພີ່ມອົງປະກອບໃສ່ທ້າຍຂອງບັນຈຸເຊັ່ນ std:: vector > ທ່ານບໍ່ສາມາດພຽງແຕ່ຂຽນ xxx.push_back(X ໃໝ່), ເນື່ອງຈາກວ່າບໍ່ມີການປ່ຽນໃຈເຫລື້ອມໃສ implicit ຈາກ X* в std::unique_ptr.

ການແກ້ໄຂທົ່ວໄປແມ່ນການຂຽນ xxx.emplace_back(X ໃໝ່)ນັບຕັ້ງແຕ່ມັນລວບລວມ: ວິທີການ emplace_back ກໍ່ສ້າງອົງປະກອບໂດຍກົງຈາກການໂຕ້ຖຽງຂອງມັນແລະດັ່ງນັ້ນຈຶ່ງສາມາດນໍາໃຊ້ຕົວສ້າງທີ່ຊັດເຈນ.

ມັນບໍ່ປອດໄພ. ຖ້າ vector ແມ່ນເຕັມ, ຫຼັງຈາກນັ້ນ, ຫນ່ວຍຄວາມຈໍາໄດ້ຖືກຈັດສັນຄືນໃຫມ່. ການປະຕິບັດການຈັດສັນຫນ່ວຍຄວາມຈໍາອາດຈະລົ້ມເຫລວ, ສົ່ງຜົນໃຫ້ຂໍ້ຍົກເວັ້ນຖືກຖິ້ມ std::bad_alloc. ໃນກໍລະນີນີ້, ຕົວຊີ້ຈະສູນເສຍໄປແລະວັດຖຸທີ່ສ້າງຂຶ້ນຈະບໍ່ຖືກລຶບ.

ການແກ້ໄຂທີ່ປອດໄພແມ່ນການສ້າງ unique_ptrເຊິ່ງຈະເປັນເຈົ້າຂອງຕົວຊີ້ກ່ອນທີ່ vector ພະຍາຍາມຈັດສັນຫນ່ວຍຄວາມຈໍາ:

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

ຕັ້ງແຕ່ C++14, ທ່ານສາມາດໃຊ້ 'std::make_unique':

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

ປະເພດຂອງຂໍ້ບົກພ່ອງນີ້ບໍ່ສໍາຄັນສໍາລັບ LLVM. ຖ້າບໍ່ສາມາດຈັດສັນຫນ່ວຍຄວາມຈໍາໄດ້, compiler ຈະຢຸດພຽງແຕ່. ຢ່າງໃດກໍຕາມ, ສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ມີຄວາມຍາວ ເວລາຫວ່າງ, ເຊິ່ງບໍ່ສາມາດພຽງແຕ່ຢຸດເຊົາຖ້າການຈັດສັນຫນ່ວຍຄວາມຈໍາລົ້ມເຫລວ, ນີ້ສາມາດເປັນແມງໄມ້ທີ່ຫນ້າເສົ້າໃຈແທ້ໆ.

ດັ່ງນັ້ນ, ເຖິງແມ່ນວ່າລະຫັດນີ້ບໍ່ໄດ້ເຮັດໃຫ້ເກີດໄພຂົ່ມຂູ່ຕໍ່ການປະຕິບັດຕໍ່ LLVM, ຂ້ອຍພົບວ່າມັນເປັນປະໂຫຍດທີ່ຈະເວົ້າກ່ຽວກັບຮູບແບບຄວາມຜິດພາດນີ້ແລະຜູ້ວິເຄາະ PVS-Studio ໄດ້ຮຽນຮູ້ເພື່ອກໍານົດມັນ.

ການເຕືອນໄພອື່ນໆຂອງປະເພດນີ້:

• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'Passes' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. PassManager.h 546
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'AAs' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. AliasAnalysis.h 324
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'Entry' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. DWARFDebugFrame.cpp 519
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'AllEdges' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. CFGMST.h 268
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'VMaps' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. SimpleLoopUnswitch.cpp 2012
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'Records' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. FDRlogBuilder.h 30
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ກ່ອງບັນຈຸ 'PendingSubmodules' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. ModuleMap.cpp 810
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'Objects' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. DebugMap.cpp 88
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຍຸດທະສາດ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-isel-fuzzer.cpp 60
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຕົວແກ້ໄຂ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-stress.cpp 685
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຕົວແກ້ໄຂ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-stress.cpp 686
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຕົວແກ້ໄຂ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-stress.cpp 688
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຕົວແກ້ໄຂ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-stress.cpp 689
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຕົວແກ້ໄຂ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-stress.cpp 690
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຕົວແກ້ໄຂ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-stress.cpp 691
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຕົວແກ້ໄຂ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-stress.cpp 692
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຕົວແກ້ໄຂ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-stress.cpp 693
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ຖັງ 'ຕົວແກ້ໄຂ' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. llvm-stress.cpp 694
• V1023 [CWE-460] ຕົວຊີ້ທີ່ບໍ່ມີເຈົ້າຂອງຖືກເພີ່ມໃສ່ກ່ອງບັນຈຸ 'Operands' ໂດຍວິທີ 'emplace_back'. ການຮົ່ວໄຫຼຂອງຫນ່ວຍຄວາມຈໍາຈະເກີດຂຶ້ນໃນກໍລະນີຂອງການຍົກເວັ້ນ. GlobalISelEmitter.cpp 1911
• 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 ໄດ້​ທີ່​ ຫນ້ານີ້.

ສິ່ງທີ່ສໍາຄັນທີ່ສຸດ, ໃຊ້ການວິເຄາະສະຖິດເປັນປົກກະຕິ. ກວດຄັ້ງດຽວ, ດໍາເນີນການໂດຍພວກເຮົາເພື່ອນິຍົມວິທີການຂອງການວິເຄາະ static ແລະ PVS-Studio ບໍ່ແມ່ນສະຖານະການປົກກະຕິ.

ໂຊກດີໃນການປັບປຸງຄຸນນະພາບແລະຄວາມຫນ້າເຊື່ອຖືຂອງລະຫັດຂອງທ່ານ!

ຖ້າທ່ານຕ້ອງການແບ່ງປັນບົດຄວາມນີ້ກັບຜູ້ຊົມທີ່ເວົ້າພາສາອັງກິດ, ກະລຸນາໃຊ້ການເຊື່ອມຕໍ່ການແປພາສາ: Andrey Karpov. ຊອກຫາບັກໃນ LLVM 8 ດ້ວຍ PVS-Studio.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com