مقدمه

این سند شامل یادداشت‌های انتشار برای Extra Clang Tools، بخشی از انتشار 22.1.8 نرم‌افزار Clang است. در اینجا وضعیت ابزارهای اضافی Clang را با جزئیات شرح می‌دهیم، از جمله بهبودهای عمده نسبت به نسخه قبلی و کارهای صورت‌گرفته روی ویژگی‌های جدید. تمام انتشارهای LLVM ممکن است از وبگاه انتشارهای LLVM بارگیری شوند https://llvm.org/releases.

برای اطلاعات بیشتر درباره Clang یا LLVM، شامل اطلاعات درباره آخرین نسخه، لطفاً به وبگاه Clang https://clang.llvm.org یا وبگاه LLVM https://llvm.org مراجعه کنید.

توجه داشته باشید که اگر این فایل را از یک checkout در Git یا صفحه اصلی وبگاه Clang می‌خوانید، این سند برای نسخه بعدی صدق می‌کند، نه نسخه فعلی. برای مشاهده یادداشت‌های انتشار مربوط به یک نسخه خاص، لطفاً صفحه انتشارها را مشاهده کنید https://llvm.org/releases.

چه چیزهایی در Extra Clang Tools 22.1.8 جدید است؟

برخی از ویژگی‌های اصلی جدید و بهبودهای صورت‌گرفته در Extra Clang Tools در اینجا فهرست شده‌اند. بهبودهای عمومی در کل Extra Clang Tools یا در زیرساخت‌های بنیادین آن ابتدا توضیح داده شده و به دنبال آن بخش‌های اختصاصی هر ابزار آمده است.

ویژگی‌های عمده جدید

تغییرات بالقوه ناسازگار

بهبودهای clangd

فلگ‌های کامپایل

عیب‌یابی‌ها

قابلیت Hover

مراجع متقابل (Cross-references)

نکات درون‌خطی (Inlay hints)

سلسله‌مراتب فراخوانی (Call hierarchy)

نمادهای سند (Document symbols)

تا کردن کد (Code folding)

تکمیل خودکار کد (Code completion)

عملیات‌های کد (Code actions)

پشتیبانی از ماژول‌های C++20

متفرقه

بهبودهای clang-doc

بهبودهای clang-query

بهبودها در clang-tidy

بررسی‌های جدید

نام‌های مستعار جدید بررسی‌ها

تغییرات در بررسی‌های موجود

بررسی‌های حذف‌شده

متفرقه

بهبودهای include-fixer

بهبودها عبارتند از...

بهبودهای clang-include-fixer

بهبودها عبارتند از...

بهبودهای modularize

بهبودها عبارتند از...

بهبودهای pp-trace

پلاگین Clang-tidy برای Visual Studio

فهرست

همچنین ببینید:

بررسی‌های Clang-Tidy

abseil-cleanup-ctad

پیشنهاد می‌دهد در C++17 و بالاتر، الگوی مقداردهی اولیه‌ی نمونه‌های absl::Cleanup از تابع کارخانه‌ای (factory function) به استنتاج آرگومان الگوی کلاس (CTAD) تغییر یابد.

auto c1 = absl::MakeCleanup([] {});
const auto c2 = absl::MakeCleanup(std::function<void()>([] {}));

تبدیل می‌شود به

absl::Cleanup c1 = [] {};
const absl::Cleanup c2 = std::function<void()>([] {});

abseil-duration-addition

مواردی را بررسی می‌کند که در آن‌ها جمع مقادیر باید در دامنهٔ absl::Time انجام شود. هنگام جمع دو مقدار، در صورتی که مشخص باشد یکی از آن‌ها از نوع absl::Time است، می‌توان نتیجه گرفت که مقدار دیگر باید به‌صورت یک absl::Duration با مقیاس مشابه تفسیر شود، و این استنباط را صریح کرد.

مثال‌ها:

// Original - Addition in the integer domain
int x;
absl::Time t;
int result = absl::ToUnixSeconds(t) + x;
// Suggestion - Addition in the absl::Time domain
int result = absl::ToUnixSeconds(t + absl::Seconds(x));

abseil-duration-comparison

مقایسه‌هایی را بررسی می‌کند که باید به‌جای دامنه‌های ممیز شناور (floating point) یا عدد صحیح (integer)، در دامنهٔ absl::Duration انجام گیرند.

توجه: در مواردی که یک Duration ابتدا به عدد صحیح تبدیل شده و سپس با یک مقدار ممیز شناور مقایسه می‌شود، عمل قطع کردن اعشار (truncation) در حین تبدیل Duration ممکن است نتیجهٔ متفاوتی ایجاد کند. در عمل این حالت بسیار نادر است، و با این حال نشان‌دهندهٔ یک باگ است که باید برطرف شود.

مثال‌ها:

// Original - Comparison in the floating point domain
double x;
absl::Duration d;
if (x < absl::ToDoubleSeconds(d)) ...
// Suggested - Compare in the absl::Duration domain instead
if (absl::Seconds(x) < d) ...
// Original - Comparison in the integer domain
int x;
absl::Duration d;
if (x < absl::ToInt64Microseconds(d)) ...
// Suggested - Compare in the absl::Duration domain instead
if (absl::Microseconds(x) < d) ...

abseil-duration-conversion-cast

تبدیل‌های نوع (cast) توابع تبدیل absl::Duration را بررسی کرده و به‌جای آن‌ها تابع تبدیل مناسب را پیشنهاد می‌دهد.

مثال‌ها:

// Original - Cast from a double to an integer
absl::Duration d;
int i = static_cast<int>(absl::ToDoubleSeconds(d));
// Suggested - Use the integer conversion function directly.
int i = absl::ToInt64Seconds(d);
// Original - Cast from a double to an integer
absl::Duration d;
double x = static_cast<double>(absl::ToInt64Seconds(d));
// Suggested - Use the integer conversion function directly.
double x = absl::ToDoubleSeconds(d);

نکته: در مثال دوم، اصلاح پیشنهادی ممکن است نتیجهٔ متفاوتی در پی داشته باشد، زیرا تبدیل به عدد صحیح می‌تواند باعث قطع اعشار شود. در عمل، این حالت بسیار نادر است، و شما باید به‌جای آن از absl::Trunc برای انجام صریح این عملیات استفاده کنید.

abseil-duration-division

عملیات ریاضی در absl::Duration مانند اعداد صحیح عمل می‌کند. این بدان معناست که تقسیم دو شیء absl::Duration یک int64 برمی‌گرداند که هر بخش کسری آن به سمت ۰ قطع (truncate) می‌شود. برای اطلاعات بیشتر در مورد محاسبات ریاضی با absl::Duration این پیوند را ببینید: https://github.com/abseil/abseil-cpp/blob/29ff6d4860070bf8fcbd39c8805d0c32d56628a3/absl/time/time.h#L137

برای مثال:

absl::Duration d = absl::Seconds(3.5);
int64 sec1 = d / absl::Seconds(1);     // Truncates toward 0.
int64 sec2 = absl::ToInt64Seconds(d);  // Equivalent to division.
assert(sec1 == 3 && sec2 == 3);
double dsec = d / absl::Seconds(1);  // WRONG: Still truncates toward 0.
assert(dsec == 3.0);

اگر نیاز به تقسیم ممیز شناور دارید، باید یا از تابع absl::FDivDuration() استفاده کنید، یا یکی از توابع تبدیل واحد مانند absl::ToDoubleSeconds() را به کار ببرید. برای مثال:

absl::Duration d = absl::Seconds(3.5);
double dsec1 = absl::FDivDuration(d, absl::Seconds(1));  // GOOD: No truncation.
double dsec2 = absl::ToDoubleSeconds(d);                 // GOOD: No truncation.
assert(dsec1 == 3.5 && dsec2 == 3.5);

این بررسی به دنبال مواردی از تقسیم absl::Duration می‌گردد که در بستر ممیز شناور انجام می‌شوند، و استفاده از تابعی که مقدار ممیز شناور برمی‌گرداند را پیشنهاد می‌دهد.

abseil-duration-factory-float

مواردی را بررسی می‌کند که در آن‌ها نسخه‌های بارگذاری‌مجددشدهٔ (overloaded) ممیز شناور توابع مختلف سازندهٔ absl::Duration فراخوانی شده‌اند، در حالی که می‌شد به‌جای آن‌ها از نسخه‌های صحیح با کارایی بالاتر استفاده کرد.

این بررسی اصلاحاتی را برای مقادیر لیترال که شامل اجزای کسری اعشاری هستند یا عبارات غیرلیترال پیشنهاد نمی‌دهد. اما حذف تبدیل‌های نوع (cast) اضافی را پیشنهاد خواهد داد.

مثال‌ها:

// Original - Providing a floating-point literal.
absl::Duration d = absl::Seconds(10.0);
// Suggested - Use an integer instead.
absl::Duration d = absl::Seconds(10);
// Original - Explicitly casting to a floating-point type.
absl::Duration d = absl::Seconds(static_cast<double>(10));
// Suggested - Remove the explicit cast
absl::Duration d = absl::Seconds(10);

abseil-duration-factory-scale

مواردی را بررسی می‌کند که در آن‌ها آرگومان‌های توابع کارخانه‌ای absl::Duration در داخل مقیاس‌بندی شده‌اند و می‌توان آن‌ها را با تابع کارخانه‌ای متفاوتی جایگزین کرد. این بررسی همچنین به دنبال آرگومان‌هایی با مقدار صفر می‌گردد و استفاده از absl::ZeroDuration() را به جای آن‌ها پیشنهاد می‌کند.

مثال‌ها:

// Original - Internal multiplication.
int x;
absl::Duration d = absl::Seconds(60 * x);
// Suggested - Use absl::Minutes instead.
absl::Duration d = absl::Minutes(x);
// Original - Internal division.
int y;
absl::Duration d = absl::Milliseconds(y / 1000.);
// Suggested - Use absl:::Seconds instead.
absl::Duration d = absl::Seconds(y);
// Original - Zero-value argument.
absl::Duration d = absl::Hours(0);
// Suggested = Use absl::ZeroDuration instead
absl::Duration d = absl::ZeroDuration();

abseil-duration-subtraction

مواردی را بررسی می‌کند که در آن‌ها عمل تفریق باید در دامنهٔ absl::Duration انجام شود. هنگام تفریق دو مقدار، و زمانی که مشخص است مقدار اول حاصل یک تبدیل از absl::Duration است، می‌توان نتیجه گرفت که مقدار دوم نیز باید به عنوان یک absl::Duration تفسیر شود و این استنتاج را صریح کرد.

مثال‌ها:

// Original - Subtraction in the double domain
double x;
absl::Duration d;
double result = absl::ToDoubleSeconds(d) - x;
// Suggestion - Subtraction in the absl::Duration domain instead
double result = absl::ToDoubleSeconds(d - absl::Seconds(x));
// Original - Subtraction of two Durations in the double domain
absl::Duration d1, d2;
double result = absl::ToDoubleSeconds(d1) - absl::ToDoubleSeconds(d2);
// Suggestion - Subtraction in the absl::Duration domain instead
double result = absl::ToDoubleSeconds(d1 - d2);

نکته: همانند سایر بررسی‌های clang-tidy، این احتمال وجود دارد که چند اصلاح با یکدیگر تداخل داشته باشند (مانند حالت عبارت‌های تو در تو)، بنابراین ممکن است تمام موارد در یک بار اجرا تبدیل نشوند. به‌طور خاص، این حالت ممکن است برای عبارت‌های تفریق تو در تو رخ دهد. اجرای چندبارهٔ clang-tidy این تداخل‌ها را پیدا و برطرف خواهد کرد.

abseil-duration-unnecessary-conversion

مواردی را پیدا و اصلاح می‌کند که در آن‌ها مقادیر absl::Duration به انواع عددی و دوباره به حالت اولیه تبدیل می‌شوند.

مثال‌های ممیز شناور:

// Original - Conversion to double and back again
absl::Duration d1;
absl::Duration d2 = absl::Seconds(absl::ToDoubleSeconds(d1));
// Suggestion - Remove unnecessary conversions
absl::Duration d2 = d1;
// Original - Division to convert to double and back again
absl::Duration d2 = absl::Seconds(absl::FDivDuration(d1, absl::Seconds(1)));
// Suggestion - Remove division and conversion
absl::Duration d2 = d1;

مثال‌های عدد صحیح:

// Original - Conversion to integer and back again
absl::Duration d1;
absl::Duration d2 = absl::Hours(absl::ToInt64Hours(d1));
// Suggestion - Remove unnecessary conversions
absl::Duration d2 = d1;
// Original - Integer division followed by conversion
absl::Duration d2 = absl::Seconds(d1 / absl::Seconds(1));
// Suggestion - Remove division and conversion
absl::Duration d2 = d1;

خارج کردن عملیات اسکالر از بسته‌بندی:

// Original - Multiplication by a scalar
absl::Duration d1;
absl::Duration d2 = absl::Seconds(absl::ToInt64Seconds(d1) * 2);
// Suggestion - Remove unnecessary conversion
absl::Duration d2 = d1 * 2;

نکته: تبدیل به یک عدد صحیح و سپس بازگرداندن آن به absl::Duration، چنانچه مقدار با مقیاس تبدیل هم‌تراز نباشد ممکن است یک عملیات کوتاه کردن (حذف بخش کسری) باشد. در موارد نادری که این نتیجه مد نظر است، فراخوان‌ها باید از absl::Trunc برای کوتاه کردن صریح استفاده کنند.

abseil-faster-strsplit-delimiter

نمونه‌هایی از absl::StrSplit() یا absl::MaxSplits() را که در آن‌ها جداکننده یک لیترال رشته‌ای تک‌نویسه‌ای است پیدا کرده و با یک نویسه (کاراکتر) جایگزین می‌کند. این بررسی پیشنهادی برای تبدیل لیترال رشته‌ای به نویسه ارائه می‌دهد. همچنین کدهایی را که از absl::ByAnyChar() فقط برای یک نویسهٔ واحد استفاده می‌کنند شناسایی کرده و آن‌ها را نیز به یک نویسهٔ منفرد تبدیل می‌کند.

این تغییرات نتیجهٔ یکسانی خواهند داشت، اما استفاده از نویسه‌ها به جای لیترال‌های رشته‌ای تک‌نویسه‌ای بهینه‌تر و خواناتر است.

مثال‌ها:

// Original - the argument is a string literal.
for (auto piece : absl::StrSplit(str, "B")) {
// Suggested - the argument is a character, which causes the more efficient
// overload of absl::StrSplit() to be used.
for (auto piece : absl::StrSplit(str, 'B')) {
// Original - the argument is a string literal inside absl::ByAnyChar call.
for (auto piece : absl::StrSplit(str, absl::ByAnyChar("B"))) {
// Suggested - the argument is a character, which causes the more efficient
// overload of absl::StrSplit() to be used and we do not need absl::ByAnyChar
// anymore.
for (auto piece : absl::StrSplit(str, 'B')) {
// Original - the argument is a string literal inside absl::MaxSplits call.
for (auto piece : absl::StrSplit(str, absl::MaxSplits("B", 1))) {
// Suggested - the argument is a character, which causes the more efficient
// overload of absl::StrSplit() to be used.
for (auto piece : absl::StrSplit(str, absl::MaxSplits('B', 1))) {

abseil-no-internal-dependencies

اگر کدی که از Abseil استفاده می‌کند به جزئیات داخلی وابسته باشد، هشدار می‌دهد. اگر چیزی در یک فضای نام (namespace) قرار داشته باشد که شامل کلمه "internal" است، کد مجاز نیست به آن وابسته باشد زیرا از جزئیات پیاده‌سازی محسوب می‌شود. نمی‌توان آن را دوست (friend) کرد، include کرد، به آن اشاره کرد یا به هر شکلی به آن ارجاع داد. انجام این کار راهنماهای سازگاری Abseil را نقض می‌کند و ممکن است منجر به شکست و خرابی کد شود. برای اطلاعات بیشتر به https://abseil.io/about/compatibility مراجعه کنید.

موارد زیر منجر به صدور هشدار خواهند شد:

absl::strings_internal::foo();
// warning triggered on this line
class foo {
  friend struct absl::container_internal::faa;
  // warning triggered on this line
};
absl::memory_internal::MakeUniqueResult();
// warning triggered on this line

abseil-no-namespace

اطمینان حاصل می‌کند که کد اقدام به باز کردن namespace absl نکند، چرا که این کار راهنماهای سازگاری Abseil را نقض می‌کند. کد نباید namespace absl را باز کند، زیرا این عمل با راهنماهای سازگاری Abseil در تعارض است و ممکن است به خرابی منجر شود.

هر کدی که از موارد زیر استفاده کند:

namespace absl {
 ...
}

با یک هشدار مواجه خواهد شد.

برای اطلاعات بیشتر، راهنماهای کامل سازگاری Abseil را در https://abseil.io/about/compatibility ببینید.

abseil-redundant-strcat-calls

حذف فراخوانی‌های غیرضروری به absl::StrCat را هنگامی که نتیجه به یک فراخوانی دیگر به absl::StrCat یا absl::StrAppend فرستاده می‌شود، پیشنهاد می‌دهد.

فراخوانی‌های اضافه باعث ساخته‌شدن رشته‌های موقتِ غیرضروری می‌شوند. حذف آن‌ها کد را کوچک‌تر و سریع‌تر می‌کند.

مثال‌ها:

std::string s = absl::StrCat("A", absl::StrCat("B", absl::StrCat("C", "D")));
//before
std::string s = absl::StrCat("A", "B", "C", "D");
//after
absl::StrAppend(&s, absl::StrCat("E", "F", "G"));
//before
absl::StrAppend(&s, "E", "F", "G");
//after

abseil-str-cat-append

استفاده از absl::StrCat() را برای الحاق (append) به یک std::string نشانه‌گذاری می‌کند. پیشنهاد می‌کند که به جای آن باید از absl::StrAppend() استفاده شود.

فراخوانی‌های اضافی باعث ایجاد رشته‌های موقت غیرضروری می‌شوند. حذف آن‌ها کد را کوچک‌تر و سریع‌تر می‌کند.

a = absl::StrCat(a, b); // Use absl::StrAppend(&a, b) instead.

مواردی را که در آن‌ها absl::StrCat() به عنوان یک آرگومان قالب برای یک functor استفاده شده است، عیب‌یابی نمی‌کند.

abseil-string-find-startswith

بررسی می‌کند که آیا نتیجهٔ std::string::find() یا std::string::rfind() (و متدهای متناظر در std::string_view) با 0 مقایسه شده است یا خیر، و پیشنهاد می‌کند که با absl::StartsWith() جایگزین شود. این موضوع هم از نظر خوانایی و هم از نظر عملکرد حائز اهمیت است.

تابع starts_with به عنوان یک تابع توکار در C++20 به این نوع‌ها اضافه شد. در صورت در دسترس بودن، ترجیحاً فعال‌سازی modernize-use-starts-ends-with <> را به جای این بررسی مد نظر قرار دهید.

string s = "...";
if (s.find("Hello World") == 0) { /* do something */ }
if (s.rfind("Hello World", 0) == 0) { /* do something */ }

تبدیل می‌شود به

string s = "...";
if (absl::StartsWith(s, "Hello World")) { /* do something */ }
if (absl::StartsWith(s, "Hello World")) { /* do something */ }

گزینه‌ها

abseil-string-find-str-contains

مقایسه‌های s.find(...) == string::npos را (برای انواع مختلف شبه‌رشته) پیدا کرده و پیشنهاد می‌دهد با absl::StrContains() جایگزین شوند.

این کار خوانایی را بهبود می‌بخشد و احتمال ترکیب تصادفی find() و npos از انواع مختلف شبه‌رشته را کاهش می‌دهد.

به صورت پیش‌فرض، «انواع شبه‌رشته» شامل ::std::basic_string، ::std::basic_string_view، و ::absl::string_view می‌شود. برای تغییر این مورد، گزینهٔ StringLikeClasses را ببینید.

std::string s = "...";
if (s.find("Hello World") == std::string::npos) { /* do something */ }
absl::string_view a = "...";
if (absl::string_view::npos != a.find("Hello World")) { /* do something */ }

تبدیل می‌شود به

std::string s = "...";
if (!absl::StrContains(s, "Hello World")) { /* do something */ }
absl::string_view a = "...";
if (absl::StrContains(a, "Hello World")) { /* do something */ }

گزینه‌ها

abseil-time-comparison

مقایسه‌ها در دامنه absl::Time را به مقایسه در دامنه اعداد صحیح (integer) ترجیح می‌دهد.

توجه: در مواردی که یک absl::Time به عدد صحیح تبدیل می‌شود، ممکن است هم‌ترازی (alignment) رخ دهد. اگر مقایسه به این هم‌ترازی وابسته باشد، انجام مقایسه در دامنه absl::Time ممکن است نتیجه متفاوتی به همراه داشته باشد. در عمل این وضعیت بسیار نادر است و با این حال نشان‌دهنده یک باگ است که باید رفع شود.

مثال‌ها:

// Original - Comparison in the integer domain
int x;
absl::Time t;
if (x < absl::ToUnixSeconds(t)) ...
// Suggested - Compare in the absl::Time domain instead
if (absl::FromUnixSeconds(x) < t) ...

abseil-time-subtraction

عبارت‌های تفریق absl::Time را پیدا کرده و اصلاح می‌کند تا عمل تفریق به جای دامنه عددی، در دامنه زمان (Time) انجام شود.

دو حالت از تفریق زمانی وجود دارد که در آن‌ها اطلاعات نوع (type) اضافی استنتاج می‌شود:

در حالت اول، ما باید از نتیجه عملیات آگاه باشیم، چرا که بدون آن عملوند دوم می‌تواند یک absl::Time یا یک absl::Duration باشد. در حالت دوم، عملوند اول باید یک absl::Time باشد، زیرا تفریق یک absl::Time از یک absl::Duration تعریف نشده است.

مثال‌ها:

int x;
absl::Time t;
// Original - absl::Duration result and first operand is an absl::Time.
absl::Duration d = absl::Seconds(absl::ToUnixSeconds(t) - x);
// Suggestion - Perform subtraction in the Time domain instead.
absl::Duration d = t - absl::FromUnixSeconds(x);
// Original - Second operand is an absl::Time.
int i = x - absl::ToUnixSeconds(t);
// Suggestion - Perform subtraction in the Time domain instead.
int i = absl::ToInt64Seconds(absl::FromUnixSeconds(x) - t);

abseil-unchecked-statusor-access

این بررسی، دسترسی‌های ناامن به مقادیر موجود در اشیاء absl::StatusOr<T> را شناسایی می‌کند. در ادامه به این نوع با عنوان StatusOr<T> اشاره خواهیم کرد.

دسترسی به مقدار یک StatusOr<T> زمانی رخ می‌دهد که یکی از توابع عضو value، operator* یا operator-> آن فراخوانی شود. برای همسویی با باورهای نادرست رایج، این بررسی این توابع عضو را معادل هم در نظر می‌گیرد، اگرچه تفاوت‌های ظریفی در رابطه با استثناها (exceptions) در مقابل رفتار تعریف‌نشده (undefined behavior) وجود دارد.

دسترسی به مقدار یک StatusOr<T> تنها در صورتی ایمن در نظر گرفته می‌شود که کد در حوزه محلی (مانند بدنه تابع) تضمین کند وضعیت StatusOr<T> در تمام مسیرهای اجرایی ممکنی که می‌توانند به دسترسی برسند، ok است. این امر باید یا از طریق یک بررسی صریح، با استفاده از تابع عضو StatusOr<T>::ok، یا با ساخت StatusOr<T> به روشی که نشان دهد وضعیت آن بدون ابهام ok است (مثلاً با ارسال یک مقدار به سازنده آن) صورت گیرد.

در زیر چند نمونه از الگوهای دسترسی ایمن و ناامن به StatusOr<T> آورده شده است.

نکته: اگر این بررسی در یک قطعه کد آن‌طور که انتظار داشتید رفتار نمی‌کند، لطفاً آن را در http://github.com/llvm/llvm-project/issues/new گزارش دهید.

منفی‌های کاذب (False negatives)

این بررسی عموماً منفی کاذب ایجاد نمی‌کند. این بدان معناست که اگر یک دسترسی به عنوان ناامن علامت‌گذاری نشود، از نظر منطقی قابل اثبات است که ایمن است. اگر نتواند ایمن بودن یک دسترسی را اثبات کند، آن را ناامن فرض می‌کند. در برخی موارد، تحلیل ایستای کد به دلایل گوناگون (مانند پایاها/invariants مدل‌سازی نشده از توابع فراخوانی‌شده) نمی‌تواند ایمن بودن یک دسترسی را با وجود ایمن بودن آن اثبات کند. در این موارد، تحلیل گزارش‌های مثبت کاذب (false positive) تولید می‌کند.

با این حال، برخی روش‌های مکاشفه‌ای (heuristics) استفاده می‌شوند که در موارد بسیار نادر ممکن است نادرست باشند:

اگر فکر می‌کنید این بررسی یک منفی کاذب تولید کرده است، لطفاً آن را در http://github.com/llvm/llvm-project/issues/new گزارش دهید.

محدودیت‌های شناخته‌شده

این یک فهرست ناکامل از ساختارهایی است که در حال حاضر در این بررسی مدل‌سازی نشده‌اند و منجر به مثبت‌های کاذب (false positives) می‌شوند:

بررسی ok بودن وضعیت و سپس دسترسی به مقدار

این بررسی تمام روش‌های سرراست برای بررسی وضعیت و دسترسی به مقدار موجود در یک شیء StatusOr<T> را تشخیص می‌دهد. برای نمونه:

void f(absl::StatusOr<int> sor) {
  if (sor.ok()) {
    use(*sor);
  }
}

بررسی ok بودن وضعیت، سپس دسترسی به مقدار از یک کپی

معیاری که این بررسی به کار می‌برد معنایی (semantic) است، نه نحوی (syntactic). این ابزار متوجه می‌شود که چه زمانی یک رونوشت (کپی) از شیء StatusOr<T> مورد دسترسی، دارای وضعیت ok شناخته شده است. برای نمونه:

void f(absl::StatusOr<int> sor1) {
  if (sor1.ok()) {
    absl::optional<int> sor2 = sor1;
    use(*sor2);
  }
}

اطمینان از ok بودن وضعیت با استفاده از ماکروهای متداول

این بررسی از ماکروهای متداول مانند ABSL_CHECK و ASSERT_THAT آگاه است. از آن‌ها می‌توان برای اطمینان از ok بودن وضعیت شیء StatusOr<T> استفاده کرد. برای نمونه:

void f(absl::StatusOr<int> sor) {
  ABSL_DCHECK_OK(sor);
  use(*sor);
}

اطمینان از ok بودن وضعیت، سپس دسترسی به مقدار در یک شاخه مرتبط

این بررسی از شاخه‌های همبسته و مرتبط در کد آگاه است و می‌تواند تشخیص دهد چه زمانی تضمین شده که یک شیء StatusOr<T> در تمام مسیرهای اجرایی منتهی به دسترسی، دارای وضعیت ok است. برای نمونه:

void f(absl::StatusOr<int> sor) {
  bool safe = false;
  if (sor.ok() && SomeOtherCondition()) {
    safe = true;
  }
  // ... more code...
  if (safe) {
    use(*sor);
  }
}

دسترسی به مقدار بدون بررسی وضعیت

این بررسی دسترسی‌هایی به مقدار را که به صورت محلی توسط بررسی وضعیت محافظت نشده‌اند پرچم‌گذاری می‌کند:

void f1(absl::StatusOr<int> sor) {
  use(*sor); // unsafe: it is unclear whether the status of `sor` is ok.
}
void f2(absl::StatusOr<MyStruct> sor) {
  use(sor->member); // unsafe: it is unclear whether the status of `sor` is ok.
}
void f3(absl::StatusOr<int> sor) {
  use(sor.value()); // unsafe: it is unclear whether the status of `sor` is ok.
}

از ABSL_CHECK_OK استفاده کنید تا نشان دهید که آگاهانه می‌خواهید در مقادیر غیرِ OK برنامه دچار crash (فروپاشی) شود.

نکته: با این‌که استفاده از .value() روی یک StatusOr غیرِ ok() طوری تعریف شده که کرش کند، اما این کار اغلب غیرعمدی است. به همین دلیل بررسی‌کننده ما این موارد را نیز پرچم‌گذاری می‌کند.

دسترسی به مقدار در شاخه اشتباه

این بررسی از حالت شیء StatusOr<T> در شاخه‌های مختلف کد آگاه است. برای نمونه:

void f(absl::StatusOr<int> sor) {
  if (sor.ok()) {
  } else {
    use(*sor); // unsafe: it is clear that the status of `sor` is *not* ok.
  }
}

فرض بر پایدار بودن نتیجه تابع

این بررسی آگاه است که نتایج تابع ممکن است پایدار نباشند. یعنی فراخوانی‌های متوالی از یک تابع ممکن است مقادیر متفاوتی را بازگردانند. برای نمونه:

void f(Foo foo) {
  if (foo.sor().ok()) {
    use(*foo.sor()); // unsafe: it is unclear whether the status of `foo.sor()` is ok.
  }
}

در چنین مواردی بهتر است نتیجه فراخوانی تابع را در یک متغیر محلی ذخیره کرده و از آن برای دسترسی به مقدار استفاده کنید. برای نمونه:

void f(Foo foo) {
  if (const auto& foo_sor = foo.sor(); foo_sor.ok()) {
    use(*foo_sor);
  }
}

این بررسی فرض می‌کند که توابع دسترسی‌دهنده (accessor) با واجد شرایط const، در صورتی که هیچ تابع غیرِ const دیگری بین دو فراخوانی اجرا نشده باشد، مقدار پایداری بازمی‌گردانند:

class Foo {
  const absl::StatusOr<int>& get() const {
    [...];
  }
}
void f(Foo foo) {
  if (foo.get().ok()) {
    use(*foo.get());
  }
}

اگر فراخوانی به یک تابع بدون مشخصه const وجود داشته باشد، این بررسی فرض می‌کند که مقدار بازگشتی دسترسی‌دهنده تغییر یافته است.

class Foo {
  const absl::StatusOr<int>& get() const {
    [...];
  }
  void mutate();
}
void f(Foo foo) {
  if (foo.get().ok()) {
    foo.mutate();
    use(*foo.get()); // unsafe: mutate might have changed the state of the object
  }
}

تکیه بر ناورداهای APIهای غیرمعمول

این بررسی از ناورداهای APIهای غیرمعمول آگاه نیست. به عنوان مثال:

void f(Foo foo) {
  if (foo.HasProperty("bar")) {
    use(*foo.GetProperty("bar")); // unsafe: it is unclear whether the status of `foo.GetProperty("bar")` is ok.
  }
}

در چنین مواردی بهتر است به‌طور صریح بررسی شود که وضعیت شیء StatusOr<T> مناسب (ok) است. به عنوان مثال:

void f(Foo foo) {
  if (const auto& property = foo.GetProperty("bar"); property.ok()) {
    use(*property);
  }
}

بررسی مناسب بودن وضعیت و سپس ارسال StatusOr<T> به تابعی دیگر

این بررسی بر استدلال محلی متکی است. عمل بررسی و دسترسی به مقدار، هر دو باید در یک تابع رخ دهند. یک دسترسی حتی در صورتی که فراخوانندهٔ تابعِ دسترسی‌گیرنده اطمینان دهد وضعیت StatusOr<T> مناسب (ok) است، باز هم ناامن تلقی می‌شود. به عنوان مثال:

void g(absl::StatusOr<int> sor) {
  use(*sor); // unsafe: it is unclear whether the status of `sor` is ok.
}
void f(absl::StatusOr<int> sor) {
  if (sor.ok()) {
    g(sor);
  }
}

در چنین مواردی بهتر است هنگام فراخوانی تابع یا مقدار را مستقیماً ارسال کنید، یا این‌که مناسب بودن وضعیت StatusOr<T> را درون دامنهٔ محلی تابع فراخوانی‌شده بررسی نمایید. به عنوان مثال:

void g(int val) {
  use(val);
}
void f(absl::StatusOr<int> sor) {
  if (sor.ok()) {
    g(*sor);
  }
}

نام‌های مستعار ایجاد شده از طریق اعلان‌های using

این بررسی از نام‌های مستعار انواع StatusOr<T> که از طریق اعلان‌های using ایجاد می‌شوند آگاه است. به عنوان مثال:

using StatusOrInt = absl::StatusOr<int>;
void f(StatusOrInt sor) {
  use(*sor); // unsafe: it is unclear whether the status of `sor` is ok.
}

کانتینرها

این بررسی در مورد کانتینرهای مقادیر StatusOr<T> بیش از حد سخت‌گیر است. صرفاً بررسی مناسب بودن وضعیت یکی از عناصر کانتینر برای امن تلقی شدن دسترسی به آن کافی نیست. به عنوان مثال:

void f(std::vector<absl::StatusOr<int>> sors) {
  if (sors[0].ok()) {
    use(*sors[0]); // unsafe: it is unclear whether the status of `sors[0]` is ok.
  }
}

باید یک ارجاع به آن شیء خاص دریافت کرده و به جای آن استفاده کنید:

void f(std::vector<absl::StatusOr<int>> sors) {
  absl::StatusOr<int>& sor0 = sors[0];
  if (sor0.ok()) {
    use(*sor0);
  }
}

نسخه‌های بعدی می‌توانند درک الگوهای امن‌تر استفاده که شامل کانتینرها هستند را بهبود بخشند.

لانمبداها

این بررسی قادر به گزارش دسترسی‌های ناامن StatusOr<T> در لانمبداها هست، اما آن‌قدر هوشمند نیست که اطلاعات را از زمینهٔ بیرونی به درون لانمبدا منتقل کند. این بدان معناست که الگوی زیر به عنوان یک دسترسی ناامن گزارش خواهد شد:

void f(absl::StatusOr<int> sor) {
  if (sor.ok()) {
    [&sor]() {
      use(*sor); // unsafe: it is unclear whether the status of `sor` is ok.
    }
  }
}

برای جلوگیری از این مشکل، باید یک ارجاع به شیء موجود درون آن دریافت کنید و به جای آن، آن ارجاع را ضبط (capture) نمایید:

void f(absl::StatusOr<int> sor) {
  if (sor.ok()) {
    auto& s = *sor;
    [&s]() {
      use(s);
    }
  }
}

همچنین می‌توانید بررسی را درون لانمبدا، جایی که به مقدار دسترسی پیدا می‌شود، اضافه کنید:

void f(absl::StatusOr<int> sor) {
  [&sor]() {
    if (sor.ok()) {
      use(*sor);
    }
  }
}

abseil-upgrade-duration-conversions

فراخوانی‌های عملگرهای محاسباتی و توابع سازنده (factory) مربوط به absl::Duration را که آرگومان آن‌ها برای ادامه‌ی کامپایل پس از تغییرات آتی API نیاز به تبدیل صریح (explicit cast) دارد، پیدا می‌کند.

عملگرهای *=، /=، * و / برای absl::Duration در حال حاضر آرگومانی از نوع کلاس را که به یک نوع محاسباتی قابل تبدیل باشد می‌پذیرند. چنین فراخوانی در حال حاضر مقدار را به یک int64_t تبدیل می‌کند، حتی در مواردی مانند std::atomic<float> که منجر به تبدیل همراه با اتلاف داده (lossy conversion) می‌شود.

علاوه بر این، توابع سازنده absl::Duration (مانند absl::Hours، absl::Minutes و غیره) در حال حاضر یک int64_t یا یک نوع ممیز شناور را می‌پذیرند. مشابه عملگرهای محاسباتی، فراخوانی‌ها با آرگومانی از نوع کلاس که قابل تبدیل به یک نوع محاسباتی باشد از مسیر int64_t عبور می‌کنند.

این عملگرها و توابع سازنده برای جلوگیری از رفتارهای ناخواسته تغییر خواهند کرد تا فقط انواع محاسباتی را بپذیرند. پس از انتشار این تغییرات، ارسال آرگومانی از نوع کلاس دیگر کامپایل نخواهد شد، حتی اگر آن نوع به صورت ضمنی به یک نوع محاسباتی قابل تبدیل باشد.

در اینجا نمونه‌هایی از اصلاحات ایجاد شده توسط این بررسی آورده شده است:

std::atomic<int> a;
absl::Duration d = absl::Milliseconds(a);
d *= a;

تبدیل می‌شود به:

std::atomic<int> a;
absl::Duration d = absl::Milliseconds(static_cast<int64_t>(a));
d *= static_cast<int64_t>(a);

توجه داشته باشید که این بررسی برای حفظ رفتار فعلی کد کاربر، همیشه یک تبدیل نوع به int64_t اضافه می‌کند. این احتمال وجود دارد که این کار رفتارهای ناخواسته‌ای را به دلیل انواعِ به طور ضمنی قابل تبدیل به نوع ممیز شناور، آشکار کند.

altera-id-dependent-backward-branch

متغیرها و فیلدهای وابسته به شناسه (ID-dependent) را که درون حلقه‌ها استفاده می‌شوند، پیدا می‌کند. این امر باعث ایجاد انشعاب در داخل حلقه‌ها شده و در نتیجه منجر به افت کارایی می‌شود.

// The following code will produce a warning because this ID-dependent
// variable is used in a loop condition statement.
int ThreadID = get_local_id(0);
// The following loop will produce a warning because the loop condition
// statement depends on an ID-dependent variable.
for (int i = 0; i < ThreadID; ++i) {
  std::cout << i << std::endl;
}
// The following loop will not produce a warning, because the ID-dependent
// variable is not used in the loop condition statement.
for (int i = 0; i < 100; ++i) {
  std::cout << ThreadID << std::endl;
}

بر اساس Altera SDK for OpenCL: Best Practices Guide https://www.altera.com/en_US/pdfs/literature/hb/opencl-sdk/aocl_optimization_guide.pdf.

altera-kernel-name-restriction

فایل‌های کرنل و دستورات include را که نام فایل آن‌ها kernel.cl، Verilog.cl یا VHDL.cl است پیدا می‌کند. این بررسی به بزرگی و کوچکی حروف حساس نیست.

چنین نام‌هایی برای فایل‌های کرنل باعث می‌شوند کامپایلر آفلاین فایل‌های طراحی واسطی تولید کند که همنام برخی از فایل‌های داخلی هستند، که این امر منجر به خطای کامپایل می‌شود.

بر اساس بخش Guidelines for Naming the Kernel در Intel FPGA SDK for OpenCL Pro Edition: Programming Guide https://www.intel.com/content/www/us/en/programmable/documentation/mwh1391807965224.html#ewa1412973930963.

altera-single-work-item-barrier

توابع کرنل OpenCL را که یک تابع سد محافظ (barrier) را فراخوانی می‌کنند اما هیچ تابع شناسه‌ای (get_local_id، get_local_id، get_group_id یا get_local_linear_id) را فراخوانی نمی‌کنند، پیدا می‌کند.

این کرنل‌ها ممکن است کرنل‌های تک work-item قابل اجرایی باشند، اما در صورت استفاده از نسخه‌های جدیدتر Altera Offline Compiler (نسخه 17.01 یا بالاتر) مجبور به اجرا به صورت کرنل‌های NDRange خواهند شد.

در صورت استفاده از نسخه قدیمی‌تر Altera Offline Compiler، این توابع کرنل به عنوان کرنل‌های تک work-item در نظر گرفته می‌شوند، که اگر معناشناسی NDRange مد نظر بوده باشد، می‌تواند ناکارآمد بوده یا منجر به خطا شود.

بر اساس Altera SDK for OpenCL: Best Practices Guide https://www.altera.com/en_US/pdfs/literature/hb/opencl-sdk/aocl_optimization_guide.pdf.

مثال‌ها:

// error: function calls barrier but does not call an ID function.
void __kernel barrier_no_id(__global int * foo, int size) {
  for (int i = 0; i < 100; i++) {
    foo[i] += 5;
  }
  barrier(CLK_GLOBAL_MEM_FENCE);
}
// ok: function calls barrier and an ID function.
void __kernel barrier_with_id(__global int * foo, int size) {
  for (int i = 0; i < 100; i++) {
    int tid = get_global_id(0);
    foo[tid] += 5;
  }
  barrier(CLK_GLOBAL_MEM_FENCE);
}
// ok with AOC Version 17.01: the reqd_work_group_size turns this into
// an NDRange.
__attribute__((reqd_work_group_size(2,2,2)))
void __kernel barrier_with_id(__global int * foo, int size) {
  for (int i = 0; i < 100; i++) {
    foo[tid] += 5;
  }
  barrier(CLK_GLOBAL_MEM_FENCE);
}

گزینه‌ها

altera-struct-pack-align

ساختارهایی (structs) را که به شکلی ناکارآمد بسته‌بندی (pack) یا تراز (align) شده‌اند پیدا کرده و در صورت نیاز، بسته‌بندی و/یا تراز کردن آن‌ها را توصیه می‌کند.

ساختارهایی که بسته‌بندی نشده‌اند فضای بیشتری نسبت به آنچه نیاز دارند اشغال می‌کنند، و دسترسی به ساختارهایی که به خوبی تراز نشده‌اند ناکارآمد است.

راهکارهای اصلاحی (Fix-its) برای رفع هر دوی این مشکلات از طریق درج و/یا اصلاح ویژگی‌های (attributes) مرتبط در ساختار ارائه شده است.

بر اساس Altera SDK for OpenCL: Best Practices Guide https://www.altera.com/en_US/pdfs/literature/hb/opencl-sdk/aocl_optimization_guide.pdf.

// The following struct is originally aligned to 4 bytes, and thus takes up
// 12 bytes of memory instead of 10. Packing the struct will make it use
// only 10 bytes of memory, and aligning it to 16 bytes will make it
// efficient to access.
struct example {
  char a;    // 1 byte
  double b;  // 8 bytes
  char c;    // 1 byte
};
// The following struct is arranged in such a way that packing is not needed.
// However, it is aligned to 4 bytes instead of 8, and thus needs to be
// explicitly aligned.
struct implicitly_packed_example {
  char a;  // 1 byte
  char b;  // 1 byte
  char c;  // 1 byte
  char d;  // 1 byte
  int e;   // 4 bytes
};
// The following struct is explicitly aligned and packed.
struct good_example {
  char a;    // 1 byte
  double b;  // 8 bytes
  char c;    // 1 byte
} __attribute__((packed)) __attribute__((aligned(16));
// Explicitly aligning a struct to the wrong value will result in a warning.
// The following example should be aligned to 16 bytes, not 32.
struct badly_aligned_example {
  char a;    // 1 byte
  double b;  // 8 bytes
  char c;    // 1 byte
} __attribute__((packed)) __attribute__((aligned(32)));

altera-unroll-loops

حلقه‌های داخلی را که باز (unroll) نشده‌اند، و همچنین حلقه‌هایی که به طور کامل باز شده‌اند اما کران‌های نامشخص یا تعداد تکرار بالایی دارند را پیدا می‌کند.

باز کردن حلقه‌های داخلی می‌تواند کارایی هسته‌های (kernels) OpenCL را بهبود بخشد. با این حال، اگر آن‌ها دارای کران‌های حلقهٔ نامشخص یا تعداد تکرار بالایی باشند، نمی‌توان آن‌ها را به طور کامل باز کرد و باید به صورت جزئی باز شوند.

نکات:

بر اساس راهنمای Altera SDK for OpenCL: Best Practices Guide https://www.altera.com/en_US/pdfs/literature/hb/opencl-sdk/aocl_optimization_guide.pdf.

for (int i = 0; i < 10; i++) {  // ok: outer loops should not be unrolled
   int j = 0;
   do {  // warning: this inner do..while loop should be unrolled
      j++;
   } while (j < 15);
   int k = 0;
   #pragma unroll
   while (k < 20) {  // ok: this inner loop is already unrolled
      k++;
   }
}
int A[1000];
#pragma unroll
// warning: this loop is large and should be partially unrolled
for (int a : A) {
   printf("%d", a);
}
#pragma unroll 5
// ok: this loop is large, but is partially unrolled
for (int a : A) {
   printf("%d", a);
}
#pragma unroll
// warning: this loop is large and should be partially unrolled
for (int i = 0; i < 1000; ++i) {
   printf("%d", i);
}
#pragma unroll 5
// ok: this loop is large, but is partially unrolled
for (int i = 0; i < 1000; ++i) {
   printf("%d", i);
}
#pragma unroll
// warning: << operator not supported, recommend partial unrolling
for (int i = 0; i < 1000; i<<1) {
   printf("%d", i);
}
std::vector<int> someVector (100, 0);
int i = 0;
#pragma unroll
// note: loop may be large, recommend partial unrolling
while (i < someVector.size()) {
   someVector[i]++;
}
#pragma unroll
// note: loop may be large, recommend partial unrolling
while (true) {
   printf("In loop");
}
#pragma unroll 5
// ok: loop may be large, but is partially unrolled
while (i < someVector.size()) {
   someVector[i]++;
}

گزینه‌ها

android-cloexec-accept

استفاده از accept() توصیه نمی‌شود، بهتر است از accept4() استفاده شود. بدون این پرچم، یک توصیف‌کننده فایل (file descriptor) حساس باز شده در حین یک فراخوانی fork+exec به یک دامنه با دسترسی کمتر در SELinux، همچنان باز خواهد ماند.

مثال‌ها:

accept(sockfd, addr, addrlen);
// becomes
accept4(sockfd, addr, addrlen, SOCK_CLOEXEC);

android-cloexec-accept4

تابع accept4() باید SOCK_CLOEXEC را در آرگومان type خود بگنجاند تا از نشت توصیف‌کننده فایل جلوگیری شود. بدون این پرچم، یک فایل حساس باز شده در طول فراخوانی fork+exec به یک دامنه با دسترسی کمتر در SELinux باز خواهد ماند.

مثال‌ها:

accept4(sockfd, addr, addrlen, SOCK_NONBLOCK);
// becomes
accept4(sockfd, addr, addrlen, SOCK_NONBLOCK | SOCK_CLOEXEC);

android-cloexec-creat

استفاده از creat() توصیه نمی‌شود، بهتر است از open() استفاده شود.

مثال‌ها:

int fd = creat(path, mode);
// becomes
int fd = open(path, O_WRONLY | O_CREAT | O_TRUNC | O_CLOEXEC, mode);

android-cloexec-dup

استفاده از dup() توصیه نمی‌شود؛ بهتر است از fcntl() استفاده شود که می‌تواند فلگ close-on-exec را تنظیم کند. در غیر این صورت، یک فایل حساسِ بازشده در طول یک فراخوانی fork+exec به یک دامنهٔ SELinux با سطح دسترسی پایین‌تر، همچنان باز باقی خواهد ماند.

مثال‌ها:

int fd = dup(oldfd);
// becomes
int fd = fcntl(oldfd, F_DUPFD_CLOEXEC);

android-cloexec-epoll-create

استفاده از epoll_create() توصیه نمی‌شود؛ بهتر است از epoll_create1() استفاده شود که اجازهٔ close-on-exec را می‌دهد.

مثال‌ها:

epoll_create(size);
// becomes
epoll_create1(EPOLL_CLOEXEC);

android-cloexec-epoll-create1

تابع epoll_create1() باید شامل EPOLL_CLOEXEC در آرگومان type خود باشد تا از نشت توصیف‌گر فایل (file descriptor) جلوگیری شود. بدون این فلگ، یک فایل حساس بازشده در طول فراخوانی fork+exec به یک دامنهٔ SELinux با دسترسی کمتر باز باقی خواهد ماند.

مثال‌ها:

epoll_create1(0);
// becomes
epoll_create1(EPOLL_CLOEXEC);

android-cloexec-fopen

تابع fopen() باید شامل e در رشتهٔ mode خود باشد؛ بنابراین re معتبر خواهد بود. این کار معادل تنظیم فلگ FD_CLOEXEC روی آن توصیف‌گر است.

مثال‌ها:

fopen("fn", "r");
// becomes
fopen("fn", "re");

android-cloexec-inotify-init

استفاده از inotify_init() توصیه نمی‌شود؛ بهتر است از inotify_init1() استفاده شود.

مثال‌ها:

inotify_init();
// becomes
inotify_init1(IN_CLOEXEC);

android-cloexec-inotify-init1

تابع inotify_init1() باید شامل IN_CLOEXEC در آرگومان type خود باشد تا از نشت توصیف‌گر فایل جلوگیری شود. بدون این فلگ، یک فایل حساس بازشده در طول یک فراخوانی fork+exec به یک دامنهٔ SELinux با سطح دسترسی پایین‌تر، باز باقی می‌ماند.

مثال‌ها:

inotify_init1(IN_NONBLOCK);
// becomes
inotify_init1(IN_NONBLOCK | IN_CLOEXEC);

android-cloexec-memfd-create

تابع memfd_create() باید شامل MFD_CLOEXEC در آرگومان type خود باشد تا از نشت توصیف‌گر فایل جلوگیری شود. بدون این فلگ، یک فایل حساس بازشده در طول یک فراخوانی fork+exec به یک دامنهٔ SELinux با سطح دسترسی پایین‌تر باز خواهد ماند.

مثال‌ها:

memfd_create(name, MFD_ALLOW_SEALING);
// becomes
memfd_create(name, MFD_ALLOW_SEALING | MFD_CLOEXEC);

android-cloexec-open

یک منبع متداول از باگ‌های امنیتی، کدی است که فایلی را بدون استفاده از فلگ O_CLOEXEC باز می‌کند. بدون آن فلگ، یک فایل حساسِ بازشده در طول یک فراخوانی fork+exec به یک دامنهٔ SELinux با سطح دسترسی پایین‌تر همچنان باز مانده و آن داده‌های حساس را افشا می‌کند. توابع هم‌خانوادهٔ باز کردن فایل شامل open()، openat() و open64() باید شامل O_CLOEXEC در آرگومان flags خود باشند.

مثال‌ها:

open("filename", O_RDWR);
open64("filename", O_RDWR);
openat(0, "filename", O_RDWR);
// becomes
open("filename", O_RDWR | O_CLOEXEC);
open64("filename", O_RDWR | O_CLOEXEC);
openat(0, "filename", O_RDWR | O_CLOEXEC);

android-cloexec-pipe

این بررسی استفاده از pipe() را تشخیص می‌دهد. استفاده از pipe() توصیه نمی‌شود، جایگزین پیشنهادی pipe2() است. این بررسی همچنین فلگ O_CLOEXEC را اضافه می‌کند که توصیف‌کننده فایل (file descriptor) را برای بسته شدن در فرآیندهای فرزند علامت‌گذاری می‌کند. بدون این فلگ، یک توصیف‌کننده فایل حساس ممکن است به یک فرآیند فرزند نشت کند، به‌ویژه به یک دامنه SELinux با سطح دسترسی پایین‌تر.

مثال‌ها:

pipe(pipefd);

جایگزین پیشنهادی:

pipe2(pipefd, O_CLOEXEC);

android-cloexec-pipe2

این بررسی اطمینان حاصل می‌کند که pipe2() با فلگ O_CLOEXEC فراخوانی شود. این بررسی همچنین فلگ O_CLOEXEC را اضافه می‌کند که توصیف‌کننده فایل را برای بسته شدن در فرآیندهای فرزند علامت‌گذاری می‌نماید. بدون این فلگ، یک توصیف‌کننده فایل حساس ممکن است به یک فرآیند فرزند نشت کند، به‌ویژه به یک دامنه SELinux با سطح دسترسی پایین‌تر.

مثال‌ها:

pipe2(pipefd, O_NONBLOCK);

جایگزین پیشنهادی:

pipe2(pipefd, O_NONBLOCK | O_CLOEXEC);

android-cloexec-socket

تابع socket() باید شامل SOCK_CLOEXEC در آرگومان type خود باشد تا از نشت توصیف‌کننده فایل جلوگیری شود. بدون این فلگ، یک فایل حساس باز شده در حین fork+exec به یک دامنه SELinux با دسترسی کمتر، باز باقی می‌ماند.

مثال‌ها:

socket(domain, type, SOCK_STREAM);
// becomes
socket(domain, type, SOCK_STREAM | SOCK_CLOEXEC);

android-comparison-in-temp-failure-retry

مقایسه‌هایی را که به نظر می‌رسد به اشتباه در آرگومان ماکروی TEMP_FAILURE_RETRY قرار گرفته‌اند عیب‌یابی می‌کند. چنین استفاده‌ای در اکثریت قریب به اتفاق موارد نادرست است و اغلب بدون هیچ هشداری هدف ماکروی TEMP_FAILURE_RETRY را بی‌اثر می‌کند.

جهت اطلاع، ماکروی TEMP_FAILURE_RETRY یک ماکروی کمکی https://www.gnu.org/software/libc/manual/html_node/Interrupted-Primitives.html است که توسط هر دو کتابخانه glibc و Bionic ارائه می‌شود. هدف آن اجرای مکرر یک فراخوانی سیستمی (syscall) است تا زمانی که با موفقیت انجام شود، یا به دلایلی غیر از وقفه‌خوردن (interrupted) شکست بخورد.

نمونه استفاده دارای باگ بدین صورت است:

char cs[1];
while (TEMP_FAILURE_RETRY(read(STDIN_FILENO, cs, sizeof(cs)) != 0)) {
  // Do something with cs.
}

چرا که TEMP_FAILURE_RETRY بررسی خواهد کرد که آیا نتیجه حاصل از مقایسه برابر با -1 است یا خیر، و در این صورت مجدداً تلاش می‌کند.

اگر با این مورد مواجه شدید، رفع آن ساده است: مقایسه را از داخل آرگومان TEMP_FAILURE_RETRY بیرون بکشید، به این صورت:

char cs[1];
while (TEMP_FAILURE_RETRY(read(STDIN_FILENO, cs, sizeof(cs))) != 0) {
  // Do something with cs.
}

گزینه‌ها

boost-use-ranges

فراخوانی‌های الگوریتم‌های مبتنی بر تکرارکننده (iterator) کتابخانه استاندارد را که می‌توانند با نسخه دامنه‌های Boost (Boost ranges) جایگزین شوند، شناسایی می‌کند.

مثال

auto Iter1 = std::find(Items.begin(), Items.end(), 0);
auto AreSame = std::equal(Items1.cbegin(), Items1.cend(), std::begin(Items2),
                          std::end(Items2));

تبدیل می‌شود به:

auto Iter1 = boost::range::find(Items, 0);
auto AreSame = boost::range::equal(Items1, Items2);

الگوریتم‌های پشتیبانی‌شده

فراخوانی الگوریتم‌های زیر از کتابخانه std بررسی می‌شوند:

std::accumulate, std::adjacent_difference, std::adjacent_find, std::all_of, std::any_of, std::binary_search, std::copy_backward, std::copy_if, std::copy, std::count_if, std::count, std::equal_range, std::equal, std::fill, std::find_end, std::find_first_of, std::find_if_not, std::find_if, std::find, std::for_each, std::generate, std::includes, std::iota, std::is_partitioned, std::is_permutation, std::is_sorted_until, std::is_sorted, std::lexicographical_compare, std::lower_bound, std::make_heap, std::max_element, std::merge, std::min_element, std::mismatch, std::next_permutation, std::none_of, std::partial_sum, std::partial_sort_copy, std::partition_copy, std::partition_point, std::partition, std::pop_heap, std::prev_permutation, std::push_heap, std::random_shuffle, std::reduce, std::remove_copy_if, std::remove_copy, std::remove_if, std::remove, std::replace_copy_if, std::replace_copy, std::replace_if, std::replace, std::reverse_copy, std::reverse, std::search, std::set_difference, std::set_intersection, std::set_symmetric_difference, std::set_union, std::sort_heap, std::sort, std::stable_partition, std::stable_sort, std::transform, std::unique_copy, std::unique, std::upper_bound.

این بررسی همچنین توابع زیر را از فضای نام (namespace) boost::algorithm بررسی خواهد کرد:

all_of_equal, any_of_equal, any_of, apply_permutation, apply_reverse_permutation, clamp_range, copy_if_until, copy_if_while, copy_if, copy_until, copy_while, find_backward, find_if_backward, find_if_not_backward, find_if_not, find_not_backward, hex_lower, hex, iota, all_of, is_decreasing, is_increasing, is_palindrome, is_partitioned_until, is_partitioned, is_permutation, is_sorted_until, is_sorted, is_strictly_decreasing, is_strictly_increasing, none_of_equal, none_of, one_of_equal, one_of, partition_copy, partition_point, reduce, unhex.

پیمایش معکوس (Reverse Iteration)

اگر فراخوانی‌ها با استفاده از تکرارکننده‌های معکوس (reverse iterators) روی کانتینرها انجام شده باشند، کد با استفاده از تطبیق‌دهنده boost::adaptors::reverse اصلاح خواهد شد.

auto AreSame = std::equal(Items1.rbegin(), Items1.rend(),
                          std::crbegin(Items2), std::crend(Items2));

تبدیل می‌شود به:

auto AreSame = boost::range::equal(boost::adaptors::reverse(Items1),
                                   boost::adaptors::reverse(Items2));

گزینه‌ها

std::find(Items.rbegin(), Items.rend(), 0);

boost::range::find(Items | boost::adaptors::reversed, 0);

boost-use-to-string

این بررسی تبدیل از انواع عدد صحیح مانند int به std::string یا std::wstring با استفاده از boost::lexical_cast را پیدا کرده، و آن را با فراخوانی‌های std::to_string و std::to_wstring جایگزین می‌کند.

این بررسی با وجود سربارگذاری‌های to_string، تبدیل از اعداد ممیز شناور (floating points) را جایگزین نمی‌کند، چرا که رفتار برنامه را تغییر می‌دهد.

auto str = boost::lexical_cast<std::string>(42);
auto wstr = boost::lexical_cast<std::wstring>(2137LL);
// Will be changed to
auto str = std::to_string(42);
auto wstr = std::to_wstring(2137LL);

bugprone-argument-comment

بررسی می‌کند که کامنت‌های آرگومان‌ها با نام پارامترها مطابقت داشته باشند.

این بررسی کامنت‌های آرگومان را در قالب /*parameter_name=*/ که درست پیش از آرگومان قرار می‌گیرند، درک می‌کند.

void f(bool foo);
...
f(/*bar=*/true);
// warning: argument name 'bar' in comment does not match parameter name 'foo'

این بررسی تلاش می‌کند غلط‌های املایی را تشخیص داده و اصلاحات خودکار برای آن‌ها پیشنهاد دهد..SS گزینه‌ها

قبل:

void foo(bool TurnKey, bool PressButton);
foo(true, false);

بعد:

void foo(bool TurnKey, bool PressButton);
foo(/*TurnKey=*/true, /*PressButton=*/false);

قبل:

void foo(int MeaningOfLife);
foo(42);

بعد:

void foo(int MeaningOfLife);
foo(/*MeaningOfLife=*/42);

قبل:

void foo(float Pi);
foo(3.14159);

بعد:

void foo(float Pi);
foo(/*Pi=*/3.14159);

قبل:

void foo(const char *String);
void foo(const wchar_t *WideString);
foo("Hello World");
foo(L"Hello World");

بعد:

void foo(const char *String);
void foo(const wchar_t *WideString);
foo(/*String=*/"Hello World");
foo(/*WideString=*/L"Hello World");

قبل:

void foo(char *Character);
foo('A');

بعد:

void foo(char *Character);
foo(/*Character=*/'A');

قبل:

void foo(double Distance);
double operator"" _km(long double);
foo(402.0_km);

بعد:

void foo(double Distance);
double operator"" _km(long double);
foo(/*Distance=*/402.0_km);

قبل:

void foo(A* Value);
foo(nullptr);

بعد:

void foo(A* Value);
foo(/*Value=*/nullptr);

bugprone-assert-side-effect

موارد استفاده از assert() دارای اثر جانبی (side effect) را پیدا می‌کند.

شرط درون assert() تنها در ساخت‌های حالت اشکال‌زدایی (debug) ارزیابی می‌شود، بنابراین یک شرط دارای اثر جانبی می‌تواند باعث رفتارهای متفاوت در ساخت‌های debug و release شود.

گزینه‌ها

bugprone-assignment-in-if-condition

انتساب‌ها (assignments) را درون شرط‌های دستورات if پیدا می‌کند. چنین انتساب‌هایی مستعد باگ هستند زیرا ممکن است هدف از آن‌ها بررسی تساوی بوده باشد.

این بررسی تمام انتساب‌های درون شرط‌های if را پیدا می‌کند، از جمله مواردی که به‌دلیل وجود یک جفت پرانتز اضافه توسط -Wparentheses علامت‌گذاری نشده‌اند، و همچنین انتساب‌هایی که یک operator=() بارگذاری‌مجدد شده را فراخوانی می‌کنند. انتساب‌های شناسایی‌شده، قانون «Rule 8.2.c» از گروه BARR را نقض می‌کنند https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard/statement-rules/if-else-statements.

int f = 3;
if(f = 4) { // This is identified by both `Wparentheses` and this check - should it have been: `if (f == 4)` ?
  f = f + 1;
}
if((f == 5) || (f = 6)) { // the assignment here `(f = 6)` is identified by this check, but not by `-Wparentheses`. Should it have been `(f == 6)` ?
  f = f + 2;
}

bugprone-bad-signal-to-kill-thread

فراخوانی‌های تابع pthread_kill را در مواردی پیدا می‌کند که یک ترد با ارسال سیگنال SIGTERM خاتمه می‌یابد و این سیگنال کل فرآیند را از بین می‌برد، نه تنها همان ترد مجزا را. از هر سیگنالی به جز SIGTERM استفاده کنید.

pthread_kill(thread, SIGTERM);

این بررسی با قاعده استانداردهای کدنویسی CERT C تحت عنوان POS44-C. Do not use signals to terminate threads مطابقت دارد https://wiki.sei.cmu.edu/confluence/display/c/POS44-C.+Do+not+use+signals+to+terminate+threads.

بررسی cert-pos44-c به‌عنوان نام مستعاری از این بررسی به اینجا تغییر مسیر می‌دهد.

bugprone-bitwise-pointer-cast

در مورد کدهایی که سعی دارند با استفاده از std::bit_cast یا memcpy بین اشاره‌گرها تبدیل نوع (cast) انجام دهند، هشدار می‌دهد.

انگیزه این است که std::bit_cast به عنوان جایگزینی امن برای تبدیل نوع با استفاده از reinterpret_cast در مدرن C++ تبلیغ می‌شود. با این حال، نباید کورکورانه reinterpret_cast را با std::bit_cast به صورت زیر جایگزین کرد:

int x{};
-float y = *reinterpret_cast<float*>(&x);
+float y = *std::bit_cast<float*>(&x);

این جایگزینی مستقیم دقیقاً رفتاری مشابه با reinterpret_cast دارد، و همچنان رفتار تعریف‌نشده (Undefined Behavior) رخ می‌دهد. std::bit_cast بایت‌های اشاره‌گر ورودی را (و نه شیء اشاره‌شده را) درون یک اشاره‌گر خروجی از نوعی دیگر کپی می‌کند، که ممکن است قواعد strict aliasing را نقض کند. با این وجود، با نگاه کردن ساده به کد، به نظر «امن» می‌رسد، چرا که از std::bit_cast استفاده می‌کند که به عنوان امن معرفی شده است.

راهکار برای تبدیل نوع امن، اعمال std::bit_cast روی نوع‌های مقداری (value types) است، نه روی نوع‌های اشاره‌گر:

int x{};
float y = std::bit_cast<float>(x);

به این ترتیب، بایت‌های شیء ورودی در شیء خروجی کپی می‌شوند که بسیار امن‌تر است. توجه داشته باشید که اگر مقداری از نوع To متناظر با نمایش مقداری تولیدشده وجود نداشته باشد، رفتار تعریف‌نشده هنوز می‌تواند رخ دهد. کامپایلرها ممکن است بتوانند این کپی را بهینه‌سازی کرده و کدهای اسمبلی همسانی با نسخه اولیه reinterpret_cast تولید کنند.

کدهای قبل از C++20 ممکن است std::bit_cast را با استفاده از memcpy شبیه‌سازی کرده، یا صرفاً مستقیماً memcpy را فراخوانی کنند که به همان اندازه مشکل‌ساز است. این مورد نیز توسط این بررسی شناسایی می‌شود:

int* x{};
float* y{};
std::memcpy(&y, &x, sizeof(x));

همچنین، اگر واقعاً تبدیل نوع میان اشاره‌گرها مد نظر است، باید از reinterpret_cast استفاده شود تا هدف را به وضوح منتقل کرده و هشدارهای کامپایلرها و لینترها فعال شوند، که باید به درستی رفع گردند.

bugprone-bool-pointer-implicit-conversion

شرط‌های مبتنی بر تبدیل نوع ضمنی (implicit conversion) از یک اشاره‌گر bool به bool را بررسی می‌کند.

مثال:

bool *p;
if (p) {
  // Never used in a pointer-specific way.
}

bugprone-branch-clone

شاخه'های تکراری را در زنجیره'های if/else if/else، شاخه'های تکراری متوالی را در دستورهای switch و شاخه'های یکسان true و false را در عملگرهای شرطی بررسی می'کند.

if (test_value(x)) {
  y++;
  do_something(x, y);
} else {
  y++;
  do_something(x, y);
}

در این مثال ساده (که می'تواند مثلاً بر اثر خطای کپی-پیست رخ دهد)، شاخه'های then و else یکسان هستند و کد با کد کوتاه‌تر و تمیزتر زیر معادل است:

test_value(x); // can be omitted unless it has side effects
y++;
do_something(x, y);

اگر این رفتار مورد نظر باشد، دلیلی برای استفاده از یک عبارت شرطی وجود ندارد؛ در غیر این صورت، مشکل با اصلاح شاخه'ای که به نادرستی مدیریت شده است، برطرف می'شود.

این بررسی، شاخه'های تکراری را در زنجیره'های طولانی‌تر if/else if/else نیز تشخیص می'دهد؛ جاهایی که متوجه شدن مشکل در آن‌ها حتی دشوارتر است.

این بررسی همچنین دستورهای تکراری if درونی و بیرونی را که ممکن است نتیجه خطای کپی-پیست باشند، تشخیص می'دهد. این بررسی در حال حاضر نمی‌تواند دستورهای if درونی و بیرونی یکسان را در صورتی که کدی بین شروط if قرار گرفته باشد، شناسایی کند. نمونه‌ای از آن به شرح زیر است:

void test_warn_inner_if_1(int x) {
  if (x == 1) {    // warns, if with identical inner if
    if (x == 1)    // inner if is here
      ;
  if (x == 1) {    // does not warn, cannot detect
    int y = x;
    if (x == 1)
      ;
  }
}

در دستورهای switch، این بررسی تنها زمانی شاخه'های تکراری را گزارش می'کند که متوالی باشند؛ زیرا نسبتاً معمول است که برچسب‌های case: دارای یک ترتیب طبیعی باشند و مرتب‌سازی مجدد آن‌ها خوانایی کد را کاهش دهد. برای مثال:

switch (ch) {
case 'a':
  return 10;
case 'A':
  return 10;
case 'b':
  return 11;
case 'B':
  return 11;
default:
  return 10;
}

در اینجا، بررسی گزارش می'دهد که شاخه'های 'a' و 'A' یکسان هستند (و شاخه'های 'b' و 'B' نیز یکسان هستند)، اما گزارش نمی'کند که شاخه default: نیز با دو شاخه اول یکسان است. اگر این واقعاً رفتار درستی باشد، می'توان آن را به شکل زیر پیاده‌سازی کرد:

switch (ch) {
case 'a':
case 'A':
  return 10;
case 'b':
case 'B':
  return 11;
default:
  return 10;
}

در اینجا، بررسی برای return 10; تکراری هشدار نمی'دهد، که اگر بخواهیم حفظ کنیم که 'a' قبل از 'b' باشد و default: آخرین شاخه باشد، مناسب است.

موارد switch که با صفت [[fallthrough]] مشخص شده‌اند، نادیده گرفته می‌شوند.

در نهایت، این بررسی همچنین عملگرهای شرطی را بررسی کرده و کدهایی شبیه به مورد زیر را گزارش می'دهد:

return test_value(x) ? x : x;

برخلاف دستورهای if، این بررسی زنجیره‌هایی از عملگرهای شرطی را شناسایی نمی'کند.

نکته: این بررسی مواردی را نیز گزارش می'کند که شاخه‌ها تنها پس از پیش‌پردازش یکسان می'شوند.

bugprone-capturing-this-in-member-variable

گرفتن‌های لامبدا (lambda captures) که اشاره‌گر this را ضبط کرده و به عنوان اعضای کلاس ذخیره می‌کنند بدون اینکه سازنده‌های کپی و انتقال (copy/move constructors) و عملگرهای انتساب را مدیریت کنند، پیدا می‌کند.

گرفتن this در یک لامبدا و ذخیره آن به عنوان عضو کلاس خطرناک است زیرا طول عمر لامبدا می‌تواند بیشتر از شیئی باشد که آن را ضبط می‌کند. به ویژه هنگامی که شیء کپی یا جابه‌جا (move) می‌شود، اشاره‌گر ضبط‌شده this به‌طور ضمنی به شیء جدید منتقل خواهد شد. اغلب اوقات، افراد تصور می‌کنند که اشاره‌گر ضبط‌شده this به شیء جدید اشاره دارد که این موضوع منجر به باگ خواهد شد.

struct C {
  C() : Captured([this]() -> C const * { return this; }) {}
  std::function<C const *()> Captured;
};
void foo() {
  C v1{};
  C v2 = v1; // v2.Captured capture v1's 'this' pointer
  assert(v2.Captured() == v1.Captured()); // v2.Captured capture v1's 'this' pointer
  assert(v2.Captured() == &v2); // assertion failed.
}

گزینه‌ها

bugprone-casting-through-void

عملیات تبدیل نوع (cast) دو مرحله‌ای ناامن یا زائد که شامل void* می‌شوند را شناسایی می‌کند، که طبق استاندارد C++ در https://eel.is/c++draft/expr.reinterpret.cast#7 معادل reinterpret_cast است.

تبدیل‌های نوع دو مرحله‌ای از طریق void* به دلایل متعددی توصیه نمی‌شوند.

به طور خلاصه، اجتناب از تبدیل‌های نوع دو مرحله‌ای از طریق void* تضمین می‌کند که کد شفاف‌تر باقی بماند، هشدارهای ضروری کامپایلر حفظ شوند، و از ابهام و خطاهای احتمالی زمان اجرا، به‌ویژه در سناریوهای پیچیده وراثت، جلوگیری شود. اگر چنین تبدیلی مد نظر است، باید از طریق reinterpret_cast انجام شود تا هدف به صورت واضح‌تری بیان گردد.

توجه: انتظار می‌رود پس از اعمال اصلاح پیشنهادی و استفاده از reinterpret_cast، بررسی cppcoreguidelines-pro-type-reinterpret-cast <> هشداری صادر کند. این رفتار عمدی است: reinterpret_cast عملیاتی خطرناک است که می‌تواند به راحتی قوانین strict aliasing را هنگام درک ارجاع (dereferencing) اشاره‌گر تبدیل‌شده نقض کرده و موجب رفتار تعریف‌نشده (Undefined Behavior) شود. این هشدار برای این قرار داده شده است که به کاربران گوشزد کند با دقت بررسی کنند که آیا استفاده از reinterpret_cast ایمن است یا خیر، که در صورت ایمن بودن می‌توان این هشدار را نادیده گرفت (suppress کرد).

مثال‌ها:

using IntegerPointer = int *;
double *ptr;
static_cast<IntegerPointer>(static_cast<void *>(ptr)); // WRONG
reinterpret_cast<IntegerPointer>(reinterpret_cast<void *>(ptr)); // WRONG
(IntegerPointer)(void *)ptr; // WRONG
IntegerPointer(static_cast<void *>(ptr)); // WRONG
reinterpret_cast<IntegerPointer>(ptr); // OK, clearly expresses intent.
                                       // NOTE: dereferencing this pointer violates
                                       // the strict aliasing rules, invoking
                                       // Undefined Behavior.

bugprone-chained-comparison

این بررسی عملگرهای مقایسه‌ای زنجیره‌ای را که می‌توانند منجر به رفتارهای ناخواسته یا خطاهای منطقی شوند، شناسایی می‌کند.

مقایسه‌های زنجیره‌ای عباراتی هستند که از چندین عملگر مقایسه برای مقایسه سه مقدار یا بیشتر استفاده می‌کنند. به عنوان مثال، عبارت a < b < c مقادیر a، b و c را مقایسه می‌کند. با این حال، این عبارت به صورت (a < b) && (b < c) که احتمالاً مورد نظر توسعه‌دهنده بوده ارزیابی نمی‌شود. در عوض، به شکل (a < b) < c ارزیابی می‌شود که ممکن است نتایج ناخواسته‌ای به همراه داشته باشد، به ویژه زمانی که انواع داده a، b و c متفاوت باشند.

برای جلوگیری از چنین خطاهایی، هنگام شناسایی عملگر مقایسه زنجیره‌ای، این بررسی هشداری صادر کرده و پیشنهاد می‌کند که از پرانتز برای مشخص کردن اولویت ارزیابی یا از یک عملگر منطقی برای جداسازی عبارات مقایسه‌ای استفاده شود.

مثال‌های زیر را در نظر بگیرید:

int a = 2, b = 6, c = 4;
if (a < b < c) {
    // This block will be executed
}

در این مثال، قصد توسعه‌دهنده بررسی این بود که آیا a از b کوچک‌تر است و b از c کوچک‌تر است یا خیر. با این حال، عبارت a < b < c معادل (a < b) < c است. از آن‌جا که a < b برابر true است، عبارت (a < b) < c به عنوان 1 < c ارزیابی می‌شود که معادل true < c است و در این حالت نادرست است، زیرا b < c مقدار false دارد.

حتی با وجود این‌که مشکل بالا را می‌توان به عنوان مقایسه int با bool شناسایی کرد، مثال خطرناک‌تری نیز وجود دارد:

bool a = false, b = false, c = true;
if (a == b == c) {
    // This block will be executed
}

در این مثال، قصد توسعه‌دهنده این بوده است که بررسی کند آیا a، b و c همگی برابر هستند یا خیر. با این وجود، عبارت a == b == c به صورت (a == b) == c ارزیابی می‌شود. از آن‌جا که a == b درست (true) است، عبارت (a == b) == c به عنوان true == c ارزیابی می‌شود که معادل true == true است. این مقایسه نتیجه true می‌دهد، با وجود این‌که مقادیر a و b برابر false بوده و با c برابر نیستند.

برای جلوگیری از این مشکل، توسعه‌دهنده می‌تواند از یک عملگر منطقی برای جداسازی عبارات مقایسه استفاده کند، مانند زیر:

if (a == b && b == c) {
    // This block will not be executed
}

همچنین، استفاده از پرانتز در عبارات مقایسه‌ای می‌تواند قصد توسعه‌دهنده را واضح‌تر بیان کرده و به جلوگیری از سوءتفاهم کمک کند.

if ((a == b) == c) {
    // This block will be executed
}

گزینه‌ها

bugprone-command-processor

فراخوانی‌های تابع‌های system()، popen() و _popen() را که یک پردازشگر دستور (command processor) را اجرا می‌کنند، علامت‌گذاری می‌کند. این بررسی فراخوانی‌های system() با آرگومان اشاره‌گر null را علامت‌گذاری نمی‌کند، زیرا چنین فراخوانی صرفاً وجود یک پردازشگر دستور را بررسی می‌کند و در عمل تلاشی برای اجرای یک دستور انجام نمی‌دهد.

مراجع

این بررسی با قاعدهٔ استاندارد کدنویسی CERT C زیر مطابقت دارد: ENV33-C. Do not call system() <https://www.securecoding.cert.org/confluence/display/c/ENV33-C.+Do+not+call+system()>.

bugprone-compare-pointer-to-member-virtual-function

رفتارهای مشخص‌نشده (unspecified behavior) مربوط به مقایسهٔ برابری بین یک اشاره‌گر به تابع مجازی عضو و هر چیزی غیر از یک مقدار ثابت اشاره‌گر پوچ (null-pointer-constant) را شناسایی می‌کند.

struct A {
  void f1();
  void f2();
  virtual void f3();
  virtual void f4();
  void g1(int);
};
void fn() {
  bool r1 = (&A::f1 == &A::f2);  // ok
  bool r2 = (&A::f1 == &A::f3);  // bugprone
  bool r3 = (&A::f1 != &A::f3);  // bugprone
  bool r4 = (&A::f3 == nullptr); // ok
  bool r5 = (&A::f3 == &A::f4);  // bugprone
  void (A::*v1)() = &A::f3;
  bool r6 = (v1 == &A::f1); // bugprone
  bool r6 = (v1 == nullptr); // ok
  void (A::*v2)() = &A::f2;
  bool r7 = (v2 == &A::f1); // false positive, but potential risk if assigning other value to v2.
  void (A::*v3)(int) = &A::g1;
  bool r8 = (v3 == &A::g1); // ok, no virtual function match void(A::*)(int) signature.
}

هشدارهایی را دربارهٔ مقایسه‌های برابری شامل اشاره‌گرها به توابع مجازی عضو یا متغیرهایی که احتمالاً اشاره‌گری به یک تابع مجازی عضو هستند با هر موجودیتی غیر از یک مقدار ثابت اشاره‌گر null ارائه می‌دهد.

در برخی از کامپایلرها، آدرس‌های توابع مجازی اشاره‌گرهای معمولی نیستند بلکه از آفست‌ها و اندیس‌هایی در داخل جدول توابع مجازی (vtable) تشکیل شده‌اند. در نتیجه، این اشاره‌گرها ممکن است بین کلاس‌های پایه و مشتق‌شده متفاوت باشند که باعث بروز رفتارهای غیرقابل‌پیش‌بینی هنگام مقایسهٔ مستقیم آن‌ها می‌شود. این مسئله به‌ویژه هنگام کار با اشاره‌گرها به توابع مجازی محض (pure virtual) دشوارتر می‌شود، زیرا آن‌ها ممکن است حتی یک آدرس معتبر نیز نداشته باشند که این امر مقایسه‌ها را پیچیده‌تر می‌کند.

به جای آن، توصیه می‌شود از عملگر typeid یا سایر سازوکارهای مناسب برای مقایسهٔ اشیاء استفاده کنید تا از رفتار پایدار و قابل‌پیش‌بینی در کد خود اطمینان حاصل نمایید. با توجه به این هشدار و به‌کارگیری روش مقایسهٔ مطمئن‌تر، می‌توانید مشکلات بالقوهٔ مربوط به رفتارهای مشخص‌نشده را به‌ویژه هنگام کار با اشاره‌گر به توابع مجازی عضو یا توابع مجازی محض کاهش داده و در نتیجه پایداری و نگهداری‌پذیری کلی کد خود را بهبود بخشید. در سناریوهای مربوط به اشاره‌گر به توابع مجازی عضو، فقط استفاده از nullptr برای مقایسه توصیه می‌شود.

محدودیت‌ها

مقادیر ذخیره‌شده در یک متغیر را تحلیل نمی‌کند. برای متغیرها، تنها تمامی متدهای مجازی در همان class یا struct را بررسی می‌کند و زمانی که انتساب یک اشاره‌گر به تابع مجازی عضو به این متغیر امکان‌پذیر باشد، عیب‌یابی را انجام می‌دهد.

bugprone-copy-constructor-init

سازنده‌های رونوشتی (copy constructors) را پیدا می‌کند که در آن‌ها سازنده، سازندهٔ رونوشت کلاس پایه را فراخوانی نمی‌کند.

class Copyable {
public:
  Copyable() = default;
  Copyable(const Copyable &) = default;
  int memberToBeCopied = 0;
};
class X2 : public Copyable {
  X2(const X2 &other) {} // Copyable(other) is missing
};

همچنین سازنده‌های رونوشتی را پیدا می‌کند که در آن‌ها سازندهٔ کلاس پایه بدون پارامتر فراخوانی شده است.

class X3 : public Copyable {
  X3(const X3 &other) : Copyable() {} // other is missing
};

عدم مقداردهی اولیهٔ صحیح زیر‌اشیاء (sub-objects) کلاس پایه در حین ساخت رونوشت می‌تواند منجر به رفتار تعریف‌نشده (undefined behavior)، کرش کردن برنامه، خرابی داده‌ها یا سایر پیامدهای غیرمنتظره شود. این بررسی اطمینان حاصل می‌کند که سازندهٔ رونوشت یک کلاس مشتق‌شده، سازندهٔ رونوشت کلاس پایه را به‌درستی فراخوانی کند و بدین ترتیب از باگ‌ها جلوگیری کرده و کیفیت کد را بهبود می‌بخشد.

محدودیت‌ها

این بررسی همچنین در برخی موارد پیشنهادهایی برای اصلاح خودکار (fix-its) ارائه می‌دهد.

bugprone-copy-constructor-mutates-argument

انتساب‌ها به شیء کپی‌شده و اعضای مستقیم یا غیرمستقیم آن را در سازنده‌های رونوشت و عملگرهای انتساب رونوشت پیدا می‌کند.

این بررسی با قاعدهٔ استاندارد کدنویسی CERT C زیر مطابقت دارد: OOP58-CPP. Copy operations must not mutate the source object https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP58-CPP.+Copy+operations+must+not+mutate+the+source+object.

bugprone-crtp-constructor-accessibility

استفاده‌های مستعد خطای الگوی تکرارشوندهٔ عجیب قالب (Curiously Recurring Template Pattern یا CRTP) را در صورتی که نمونه‌سازی از CRTP در خارج از خود آن و کلاس مشتق‌شده امکان‌پذیر باشد، تشخیص می‌دهد.

الگوی CRTP اصطلاحی است که در آن یک کلاس از یک کلاس قالب مشتق می‌شود، در حالی که خودش آرگومان آن قالب است. باید اطمینان حاصل شود که اگر کلاسی قرار است به عنوان یک کلاس پایه در این الگو به کار رود، تنها در صورتی بتوان از آن نمونه‌سازی کرد که کلاس مشتق‌شده آرگومان قالب آن باشد.

مثال:

template <typename T> class CRTP {
private:
  CRTP() = default;
  friend T;
};
class Derived : CRTP<Derived> {};

در زیر برخی از اشتباهات رایج که امکان نقض این الگو را فراهم می‌کنند، مشاهده می‌شود.

اگر سازندهٔ کلاسی که قرار است در CRTP استفاده شود به صورت public باشد، به کاربران اجازه می‌دهد آن کلاس را به طور مستقل نمونه‌سازی کنند.

مثال:

template <typename T> class CRTP {
public:
  CRTP() = default;
};
class Good : CRTP<Good> {};
Good GoodInstance;
CRTP<int> BadInstance;

اگر سازنده به صورت protected باشد، از احتمال نمونه‌سازی تصادفی جلوگیری می‌شود، اما ممکن است خطایی را پنهان کند که در آن کلاسی متفاوت به جای کلاس مشتق‌شده به عنوان پارامتر قالب استفاده شود.

مثال:

template <typename T> class CRTP {
protected:
  CRTP() = default;
};
class Good : CRTP<Good> {};
Good GoodInstance;
class Bad : CRTP<Good> {};
Bad BadInstance;

برای اطمینان از عدم وقوع نمونه‌سازی تصادفی، بهترین روش این است که سازنده private تعریف شود و کلاس مشتق‌شده به عنوان friend اعلام گردد. توجه داشته باشید که به عنوان یک مصالحه، این کار به کلاس مشتق‌شده دسترسی به سایر اعضای خصوصی (private) کلاس CRTP را نیز اعطا می‌کند. با این حال، سازنده‌ها همچنان می‌توانند در صورت حذف شدن (deleted)، به صورت public یا protected باشند.

مثال:

template <typename T> class CRTP {
  CRTP() = default;
  friend T;
};
class Good : CRTP<Good> {};
Good GoodInstance;
class Bad : CRTP<Good> {};
Bad CompileTimeError;
CRTP<int> AlsoCompileTimeError;

محدودیت‌ها

این بررسی همچنین در برخی موارد اصلاحات خودکار (fix-its) پیشنهاد می‌دهد.

bugprone-dangling-handle

ارجاع‌های معلق (dangling references) را در هندل‌های مقداری مانند std::string_view شناسایی می‌کند. این ارجاع‌های معلق می‌توانند نتیجه ساختن هندل‌ها از مقادیر موقت باشند، جایی که مقدار موقت اندکی پس از ایجاد هندل از بین می‌رود.

مثال‌ها:

string_view View = string();  // View will dangle.
string A;
View = A + "A";  // still dangle.
vector<string_view> V;
V.push_back(string());  // V[0] is dangling.
V.resize(3, string());  // V[1] and V[2] will also dangle.
string_view f() {
  // All these return values will dangle.
  return string();
  string S;
  return S;
  char Array[10]{};
  return Array;
}
span<int> g() {
  array<int, 1> V;
  return {V};
  int Array[10]{};
  return {Array};
}

گزینه‌ها

bugprone-default-operator-new-on-overaligned-type

استفاده از operator new پیش‌فرض را در مواردی که نوع داده دارای تراز گسترش‌یافته (ترازی بزرگ‌تر از تراز بنیادی / fundamental alignment) است علامت‌گذاری می‌کند.

در صورتی که تراز درخواستی کمتر یا مساوی با تراز بنیادی باشد، عملکرد operator new پیش‌فرض تضمین‌کننده ارائه تراز صحیح است. تنها مواردی شناسایی می‌شوند (بر اساس طراحی) که در آن‌ها operator new توسط کاربر تعریف نشده و از نوع placement new نباشد (دلیل آن این است که در این موارد فرض بر این است که کاربر تخصیص حافظه صحیح را فراهم کرده است).

مراجع

این بررسی با قاعده MEM57-CPP از استاندارد کدنویسی CERT C++ مطابقت دارد: Avoid using default operator new for over-aligned types https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types.

bugprone-derived-method-shadowing-base-method

متدهای کلاس مشتق‌شده را که یک متد (غیر مجازی) از کلاس پایه را پنهان (shadow) می‌کنند، پیدا می‌کند.

برای اینکه متدها «پنهان‌کننده» (shadowing) در نظر گرفته شوند، باید امضای یکسانی داشته باشند (یعنی نام یکسان، تعداد پارامترهای یکسان، انواع پارامتر یکسان و غیره). فقط متدهای عمومی (public) و غیر قالبی (non-templated) بررسی می‌شوند.

مثال زیر مستعد باگ است زیرا استفاده‌کنندگان از کلاس Derived انتظار دارند متد reset علاوه بر کارهای اضافه مورد نیاز برای بازنشانی کلاس Derived، کار Base::reset() را نیز انجام دهد. اصلاحات رایج عبارتند از:

این موضوع همچنین نقض اصل جایگزینی لیسکوف (Liskov Substitution Principle) است.

struct Base {
  void reset() {/* reset the base class */};
};
struct Derived : public Base {
  void reset() {/* reset the derived class, but not the base class */};
};

bugprone-dynamic-static-initializers

نمونه‌هایی از متغیرهای ایستا (static) را که به صورت پویا در فایل‌های هدر مقداردهی اولیه می‌شوند، پیدا می‌کند.

این امر می‌تواند در برخی زمینه‌های چندنخی مشکلاتی ایجاد کند. به عنوان مثال، هنگام غیرفعال کردن دستورالعمل‌های همگام‌سازی تولید شده توسط کامپایلر برای متغیرهای ایستا که در زمان اجرا مقداردهی می‌شوند (مثلاً با -fno-threadsafe-statics)، حتی اگر یک پروژه خاص اقدامات احتیاطی لازم را برای جلوگیری از شرایط مسابقه (race conditions) در طول مقداردهی اولیه با ارائه همگام‌سازی اختصاصی خود انجام دهد، فایل‌های هدر گنجانده‌شده از پروژه‌های دیگر ممکن است این کار را نکنند. بنابراین، چنین بررسی‌ای برای اطمینان از اینکه غیرفعال کردن همگام‌سازی تولید شده توسط کامپایلر برای مقداردهی متغیرهای ایستا مشکلی ایجاد نمی‌کند، مفید است.

کد زیر را در نظر بگیرید:

int foo() {
  static int k = bar();
  return k;
}

هنگامی که همگام‌سازی مقداردهی اولیه متغیرهای ایستا غیرفعال باشد، اگر دو نخ هر دو تابع foo را برای اولین بار فراخوانی کنند، این احتمال وجود دارد که k دو بار مقداردهی اولیه شود و یک شرایط مسابقه ایجاد گردد.

bugprone-easily-swappable-parameters

تعاریف توابعی را پیدا می‌کند که در آن‌ها پارامترهایی از انواع قابل تبدیل مستقیماً پشت سر هم قرار گرفته‌اند، که این امر فراخوانی‌ها را مستعد ارسال آرگومان‌ها با ترتیب جابه‌جا شده (یا نادرست) می‌کند.

void drawPoint(int X, int Y) { /* ... */ }
FILE *open(const char *Dir, const char *Name, Flags Mode) { /* ... */ }

یک فراخوانی احتمالی مانند drawPoint(-2, 5) یا openPath("a.txt", "tmp", Read) از نظر زبان کاملاً معتبر است، اما ممکن است مد نظر توسعه‌دهنده تابع نبوده باشد.

برای جلوگیری از ترتیب اشتباه آرگومان‌ها، باید از ساختارهای دقیق‌تر و نوع‌امن‌تر (type-safe)، مانند opaque typedefها یا انواع قوی (strong types) استفاده شود.

struct Coord2D { int X; int Y; };
void drawPoint(const Coord2D Pos) { /* ... */ }
FILE *open(const Path &Dir, const Filename &Name, Flags Mode) { /* ... */ }

به دلیل بازسازی کد (refactoring) بالقوه پیچیده و شکستن احتمالی API که برای تقویت ایمنی انواع در یک پروژه ضروری است، هیچ اصلاح خودکاری (fix-its) ارائه نمی‌شود.

گزینه‌ها

گزینه‌های گسترش/تسهیل

گزینه‌های تسهیل (یا گسترش) می‌توانند برای وسیع‌تر کردن دامنهٔ تحلیل و تنظیم دقیق فعال‌سازی ترکیب‌های بیشتر میان انواع داده به کار روند. برخی از ترکیب‌ها ممکن است به شیوهٔ کدنویسی یا ترجیحات خاص یک پروژه وابسته باشند، با این حال باید توجه داشت که فعال کردن تمام این تسهیل‌ها بیشترین انطباق را با شیوهٔ جابه‌جایی در فراخوانی‌ها مدل‌سازی می‌کند. انتظار می‌رود این گزینه‌ها موجب شوند بررسی برای توابع بیشتری گزارش دهد و دامنه‌های قابل جابه‌جایی طولانی‌تری را پوشش دهد.

void *memcpy(const void *Destination, void *Source, std::size_t N) { /* ... */ }

void fun(int Int, double Double) { /* ... */ }
void compare(const char *CharBuf, std::string String) { /* ... */ }

void fun2(int Int, const double Double) { /* ... */ }

گزینه‌های فیلترسازی

گزینه‌های فیلترسازی می‌توانند برای کاهش حجم گزارش‌های عیب‌یابی ارائه‌شده توسط بررسی‌کننده به کار روند؛ خواه هدف نادیده گرفتن ساختارهای خاص باشد یا کاستن از هشدارهای ناخواسته (نویز).

محدودیت‌ها

این بررسی برای بررسی امضای توابع (function signatures) طراحی شده است!

این بررسی توابعی را که توسط کامپایلر در زمینه‌ای تولید می‌شوند که فقط از محل فراخوانی مشخص است، مورد بررسی قرار نمی‌دهد. این موارد شامل توابع چندآرگومانی (variadic)، توابع در کد C که فاقد فهرست آرگومان هستند، و نمونه‌سازی‌های قالب C++ می‌شوند. بیشتر این موارد، که در غیر این صورت از دید فراخواننده قابل جابجایی هستند، هیچ راهی برای "اصلاح شدن" در نقطه تعریف ندارند. در مورد قالب‌های C++، فقط تعاریف اصلی قالب و تخصیص‌های صریح (explicit specializations) مطابقت داده شده و تحلیل می‌شوند.

هیچ‌یک از موارد زیر هشداری (diagnostic) ایجاد نمی‌کنند:

int printf(const char *Format, ...) { /* ... */ }
int someOldCFunction() { /* ... */ }
template <typename T, typename U>
int add(T X, U Y) { return X + Y };
void theseAreNotWarnedAbout() {
    printf("%d %d\n", 1, 2);   // Two ints passed, they could be swapped.
    someOldCFunction(1, 2, 3); // Similarly, multiple ints passed.
    add(1, 2); // Instantiates 'add<int, int>', but that's not a user-defined function.
}

با توجه به محدودیت بالا، پارامترهایی که نوع آن‌ها برای اثبات اختلاط با نوع پارامتر دیگر همچنان به نمونه‌سازی‌های قالب وابسته است، بررسی نمی‌شوند.

template <typename T>
struct Vector {
  typedef T element_type;
};
// Diagnosed: Explicit instantiation was done by the user, we can prove it
// is the same type.
void instantiated(int A, Vector<int>::element_type B) { /* ... */ }
// Diagnosed: The two parameter types are exactly the same.
template <typename T>
void exact(typename Vector<T>::element_type A,
           typename Vector<T>::element_type B) { /* ... */ }
// Skipped: The two parameters are both 'T' but we cannot prove this
// without actually instantiating.
template <typename T>
void falseNegative(T A, typename Vector<T>::element_type B) { /* ... */ }

در زمینه تبدیل‌های ضمنی (هنگامی که ModelImplicitConversions فعال است)، مدل‌سازی انجام‌شده توسط این بررسی در صورتی هشدار می‌دهد که پارامترها قابل جابجایی باشند و ترتیب جابجاشده با تبدیل‌های ضمنی مطابقت داشته باشد. این بررسی مدل‌سازی نمی‌کند که آیا نوع سوم نامرتبطی وجود دارد که بتوان هر دو پارامتر را در یک فراخوانی تابع از آن نوع ارائه داد یا خیر. این بدان معناست که در مثال زیر، حتی با اینکه strs() به وضوح امکان فراخوانی با آرگومان‌های جابجاشده را دارد (تا زمانی که آرگومان‌ها رشته‌های تحت‌اللفظی باشند)، هشداری درباره آن داده نخواهد شد.

struct String {
    String(const char *Buf);
};
struct StringView {
    StringView(const char *Buf);
    operator const char *() const;
};
// Skipped: Directly swapping expressions of the two type cannot mix.
// (Note: StringView -> const char * -> String would be **two**
// user-defined conversions, which is disallowed by the language.)
void strs(String Str, StringView SV) { /* ... */ }
// Diagnosed: StringView implicitly converts to and from a buffer.
void cStr(StringView SV, const char *Buf() { /* ... */ }

bugprone-empty-catch

مشکلات مربوط به دستورات catch خالی را شناسایی کرده و راهکارهایی برای رفع آن‌ها پیشنهاد می‌دهد.

try {
  // Some code that can throw an exception
} catch(const std::exception&) {
}

وجود دستورات catch خالی در پایگاه کد می‌تواند مشکل جدی باشد که توسعه‌دهندگان باید از آن آگاه باشند. دستورات catch برای مدیریت استثناهایی استفاده می‌شوند که در طول اجرای برنامه پرتاب می‌شوند. هنگامی که استثنایی رخ می‌دهد، برنامه به نزدیک‌ترین دستور catch که با نوع استثنا مطابقت دارد پرش می‌کند.

دستورات catch خالی، که با عنوان "بلعیدن" (swallowing) استثناها نیز شناخته می‌شوند، استثنا را دریافت می‌کنند اما کاری با آن انجام نمی‌دهند. این امر به این معنی است که استثنا به‌درستی مدیریت نشده و برنامه طوری به اجرای خود ادامه می‌دهد که گویی هیچ اتفاقی نیفتاده است. این وضعیت می‌تواند به چندین مشکل منجر شود، از جمله:

برای جلوگیری از این مشکلات، توسعه‌دهندگان باید همیشه استثناها را به‌درستی مدیریت کنند. این کار یا از طریق رفع مشکل اساسیِ ایجادکننده استثنا انجام می‌گیرد یا با انتشار (propagating) استثنا در پشته فراخوانی به یک مدیریت‌کننده سطح بالاتر. اگر استثنایی اهمیت چندانی ندارد، همچنان باید ثبت (log) شده یا به نوعی گزارش داده شود تا بتوان بعداً آن را پیگیری و برطرف نمود.

اگر استثنا چیزی است که می‌توان آن را به صورت محلی مدیریت کرد، باید درون همان بلوک catch مدیریت شود. این اقدام می‌تواند شامل لاگ کردن استثنا یا انجام عملیات مناسب دیگر باشد تا اطمینان حاصل شود که استثنا نادیده گرفته نشده است.

در اینجا یک مثال آورده شده است:

try {
  // Some code that can throw an exception
} catch (const std::exception& ex) {
  // Properly handle the exception, e.g.:
  std::cerr << "Exception caught: " << ex.what() << std::endl;
}

اگر استثنا نمی‌تواند به صورت محلی مدیریت شود و باید در پشته فراخوانی به بالا منتشر شود، باید مجدداً پرتاب (re-thrown) شود یا استثنای جدیدی پرتاب گردد.

در اینجا یک مثال آورده شده است:

try {
  // Some code that can throw an exception
} catch (const std::exception& ex) {
  // Re-throw the exception
  throw;
}

در برخی موارد، دریافت استثنا در این سطح ممکن است ضروری نباشد و مناسب‌تر باشد که اجازه داده شود استثنا در پشته فراخوانی به بالا منتشر شود. این کار به سادگی با استفاده نکردن از بلوک try/catch قابل انجام است.

در اینجا یک مثال آورده شده است:

void function() {
  // Some code that can throw an exception
}
void callerFunction() {
  try {
    function();
  } catch (const std::exception& ex) {
    // Handling exception on higher level
    std::cerr << "Exception caught: " << ex.what() << std::endl;
  }
}

راهکار بالقوه دیگر برای جلوگیری از دستورات catch خالی، تغییر کد برای پیشگیری از پرتاب استثنا از همان ابتدا است. این هدف را می‌توان با استفاده از یک API متفاوت، بررسی شرایط خطا از پیش، یا مدیریت خطاها به روشی دیگر که شامل استثناها نباشد محقق کرد. با حذف نیاز به بلوک‌های try-catch، کد ساده‌تر شده و کمتر مستعد خطا خواهد بود.

در اینجا یک مثال آورده شده است:

// Old code:
try {
  mapContainer["Key"].callFunction();
} catch(const std::out_of_range&) {
}
// New code
if (auto it = mapContainer.find("Key"); it != mapContainer.end()) {
  it->second.callFunction();
}

در نتیجه، دستورات catch خالی رویه‌ای نادرست هستند که می‌توانند به باگ‌های پنهان، مشکلات امنیتی، کیفیت پایین کد و کدهای غیرقابل اعتماد منجر شوند. توسعه‌دهندگان با مدیریت صحیح استثناها می‌توانند مطمئن شوند که کد آن‌ها پایدار، امن و قابل نگهداری است.

گزینه‌ها

bugprone-exception-copy-constructor-throws

بررسی می‌کند که آیا سازنده رونوشت (copy constructor) یک شیء پرتاب‌شده می‌تواند استثنا پرتاب کند یا خیر.

اشیاء استثنا در C++ ملزم هستند که قابل ساخت با رونوشت (copy constructible) باشند. با این حال، سازنده رونوشت یک استثنا برای جلوگیری از مشکلات احتمالی هنگام بازپیچی پشته (stack unwinding) نباید استثنا پرتاب کند. اگر در حین بازپیچی پشته استثنایی پرتاب شود (مانند سازنده رونوشت یک شیء استثنا)، برنامه از طریق std::terminate خاتمه می‌یابد.

class SomeException {
public:
  SomeException() = default;
  SomeException(const SomeException&) { /* may throw */ }
};
void f() {
  throw SomeException();  // warning: thrown exception type's copy constructor can throw
}

مراجع

این بررسی مطابق با قاعده استاندارد کدنویسی CERT C++ به شماره ERR60-CPP است: Exception objects must be nothrow copy constructible https://wiki.sei.cmu.edu/confluence/display/cplusplus/ERR60-CPP.+Exception+objects+must+be+nothrow+copy+constructible.

bugprone-exception-escape

توابعی را پیدا می‌کند که ممکن است به‌طور مستقیم یا غیرمستقیم استثنا پرتاب کنند، در حالی که نباید این کار را انجام دهند. توابعی که نباید استثنا پرتاب کنند به شرح زیر هستند:

پرتاب استثنا توسط یک مخرب ممکن است منجر به رفتار تعریف‌نشده (undefined behavior)، نشت منابع یا خاتمه غیرمنتظره برنامه شود. سازنده انتقال یا انتساب انتقال پرتاب‌کننده استثنا نیز ممکن است منجر به رفتار تعریف‌نشده یا نشت منابع شود. عملیات‌های swap() در اکثر موارد انتظار می‌رود که بدون پرتاب استثنا باشند و همیشه پیاده‌سازی آن‌ها به صورت بدون پرتاب استثنا امکان‌پذیر است. از عملیات‌های swap() بدون پرتاب استثنا برای ساخت عملیات‌های انتقال نیز استفاده می‌شود. یک تابع main() پرتاب‌کننده استثنا نیز منجر به خاتمه غیرمنتظره می‌شود.

توابعی که صراحتاً با noexcept(false) یا throw(exception) تعریف شده‌اند، از تحلیل کنار گذاشته می‌شوند، زیرا اگرچه برای توابعی مانند swap()، main()، سازنده‌های انتقال، عملگرهای انتساب انتقال و مخرب‌ها توصیه نمی‌شود، اما نشان‌دهنده قصد صریح توسعه‌دهنده است و باید مورد احترام قرار گیرد.

هشدار! این بررسی ممکن است روی فایل‌های منبع بزرگ پرهزینه باشد.

گزینه‌ها

bugprone-float-loop-counter

حلقه‌های for که عبارت استقرای (induction expression) آن‌ها از نوع ممیز شناور (floating-point) است را نشانه‌گذاری می‌کند.

مراجع

این بررسی مطابق با قاعده استاندارد کدنویسی CERT C به شماره FLP30-C است: Do not use floating-point variables as loop counters https://www.securecoding.cert.org/confluence/display/c/FLP30-C.+Do+not+use+floating-point+variables+as+loop+counters.

bugprone-fold-init-type

این بررسی عدم تطابق نوع را در عملیات‌های فولد <https://en.wikipedia.org/wiki/Fold_(higher-order_function)> مانند std::accumulate که ممکن است منجر به از دست رفتن دقت شود، نشانه‌گذاری می‌کند. تابع std::accumulate یک محدوده ورودی را با استفاده از نوع مقدار اولیه به یک مقدار با کمک operator+ به‌طور پیش‌فرض تبدیل (fold) می‌کند. این کار می‌تواند منجر به از دست رفتن دقت از راه‌های زیر شود:

auto a = {0.5f, 0.5f, 0.5f, 0.5f};
return std::accumulate(std::begin(a), std::end(a), 0);

auto a = {65536LL * 65536 * 65536};
return std::accumulate(std::begin(a), std::end(a), 0);

bugprone-forward-declaration-namespace

بررسی می‌کند که آیا یک اعلان پیشاپیش (forward declaration) استفاده‌نشده در یک فضای نام (namespace) اشتباه قرار دارد یا خیر.

این بررسی تمام اعلان‌های پیشاپیش استفاده‌نشده را بازرسی کرده و وجود هرگونه اعلان/تعریف هم‌نام دیگر را بررسی می‌کند؛ موضوعی که می‌تواند نشان‌دهنده آن باشد که اعلان پیشاپیش در یک فضای نام بالقوه اشتباه قرار گرفته است.

namespace na { struct A; }
namespace nb { struct A {}; }
nb::A a;
// warning : no definition found for 'A', but a definition with the same name
// 'A' found in another namespace 'nb::'

این بررسی تنها می‌تواند هشدار تولید کند، اما در حال حاضر نمی‌تواند اصلاح خودکاری پیشنهاد دهد.

bugprone-forwarding-reference-overload

این بررسی به دنبال سازنده‌های ارجاع بازپخش کامل (perfect forwarding) می‌گردد که می‌توانند سازنده‌های رونوشت (copy) یا انتقال (move) را پنهان (hide) کنند. اگر یک ارجاع lvalue غیر const به سازنده ارسال شود، پارامتر ارجاع بازپخش تطابق بهتری نسبت به پارامتر ارجاع const سازنده رونوشت خواهد داشت؛ بنابراین سازنده perfect forwarding فراخوانی می‌شود که می‌تواند سردرگم‌کننده باشد. برای توضیحات دقیق درباره این موضوع، به این منبع مراجعه کنید: Scott Meyers, Effective Modern C++, بخش ۲۶.

مثال زیر را در نظر بگیرید:

class Person {
public:
  // C1: perfect forwarding ctor
  template<typename T>
  explicit Person(T&& n) {}
  // C2: perfect forwarding ctor with parameter default value
  template<typename T>
  explicit Person(T&& n, int x = 1) {}
  // C3: perfect forwarding ctor guarded with enable_if
  template<typename T, typename X = enable_if_t<is_special<T>, void>>
  explicit Person(T&& n) {}
  // C4: variadic perfect forwarding ctor guarded with enable_if
  template<typename... A,
    enable_if_t<is_constructible_v<tuple<string, int>, A&&...>, int> = 0>
  explicit Person(A&&... a) {}
  // C5: perfect forwarding ctor guarded with requires expression
  template<typename T>
  requires requires { is_special<T>; }
  explicit Person(T&& n) {}
  // C6: perfect forwarding ctor guarded with concept requirement
  template<Special T>
  explicit Person(T&& n) {}
  // (possibly compiler generated) copy ctor
  Person(const Person& rhs);
};

این بررسی برای سازنده‌های C1 و C2 هشدار صادر می‌کند، زیرا این موارد می‌توانند سازنده‌های رونوشت و انتقال را پنهان کنند. در صورتی که هر دو سازنده رونوشت و انتقال غیرفعال باشند (حذف‌شده یا private)، هشدارها متوقف می‌شوند، زیرا در این حالت چیزی وجود ندارد که سازنده perfect forwarding بتواند آن را پنهان کند. همچنین هشدارها برای سازنده‌هایی مانند C3-C6 که توسط enable_if یا یک concept محافظت شده‌اند متوقف می‌شوند، با این فرض که برنامه‌نویس از پنهان‌سازی احتمالی آگاه بوده است.

Background

برای تصمیم‌گیری در مورد اینکه آیا یک سازنده با enable_if محافظت شده است یا خیر، انواع پارامترهای سازنده، مقادیر پیش‌فرض پارامترهای نوع قالب و انواع پارامترهای غیرنوعی قالب با یک مقدار لفظی (literal) پیش‌فرض در نظر گرفته می‌شوند. اگر هر بخشی از این انواع std::enable_if یا std::enable_if_t باشد، فرض می‌کنیم که سازنده محافظت شده است.

bugprone-implicit-widening-of-multiplication-result

این بررسی مواردی را عیب‌یابی می‌کند که در آن‌ها نتیجه یک ضرب به‌صورت ضمنی عریض‌تر (widen) می‌شود، و (همراه با fix-it) پیشنهاد می‌دهد که یا با صریح کردن تبدیل عریض‌تر، هشدار کد بی‌اثر شود، یا عمل ضرب در یک نوع داده عریض‌تر انجام گیرد تا از عریض‌سازی پس از آن جلوگیری شود.

این بررسی عمدتاً هنگام کار با بافرهای بسیار بزرگ مفید است. به عنوان مثال، قطعه کد زیر را در نظر بگیرید:

void zeroinit(char* base, unsigned width, unsigned height) {
  for(unsigned row = 0; row != height; ++row) {
    for(unsigned col = 0; col != width; ++col) {
      char* ptr = base + row * width + col;
      *ptr = 0;
    }
  }
}

این کد به‌طور کلی مشکلی ندارد، اما اگر حاصل width * height سرریز (overflow) کند، به جای پردازش کل بافر درخواستی، اشاره‌گر مجدداً به ابتدای base برمی‌گردد (wrap back رخ می‌دهد).

در واقع، این موضوع تنها برای بافرهای بسیار بزرگ (۴ گیگابایت به بالا) اهمیت دارد، اما این حالت می‌تواند به‌راحتی مثلاً در پردازش تصویر رخ دهد؛ جایی که برای وقوع آن «تنها» به یک تصویر حدوداً ۲۶۹ مگاپیکسلی نیاز است.

گزینه‌ها

مثال‌ها:

long mul(int a, int b) {
  return a * b; // warning: performing an implicit widening conversion to type 'long' of a multiplication performed in type 'int'
}
char* ptr_add(char *base, int a, int b) {
  return base + a * b; // warning: result of multiplication in type 'int' is used as a pointer offset after an implicit widening conversion to type 'ssize_t'
}
char ptr_subscript(char *base, int a, int b) {
  return base[a * b]; // warning: result of multiplication in type 'int' is used as a pointer offset after an implicit widening conversion to type 'ssize_t'
}

bugprone-inaccurate-erase

استفاده‌های نادرست از متد erase() را بررسی می‌کند.

الگوریتم‌هایی مانند remove() در عمل هیچ عنصری را از نگه‌دارنده (container) حذف نمی‌کنند، بلکه یک تکرارکننده (iterator) به اولین عنصر مازاد در انتهای نگه‌دارنده برمی‌گردانند. این عناصر مازاد باید با استفاده از متد erase() حذف شوند. این بررسی زمانی هشدار می‌دهد که به دلیل استفاده از یک سربارگذاری (overload) نامناسب، تمام عناصر حذف نشوند.

برای مثال، کد زیر فقط یک عنصر را حذف می‌کند:

std::vector<int> xs;
...
xs.erase(std::remove(xs.begin(), xs.end(), 10));

برای حذف این زیربازه، سربارگذاریِ دوآرگومانیِ erase() را فراخوانی کنید:

std::vector<int> xs;
...
xs.erase(std::remove(xs.begin(), xs.end(), 10), xs.end());

bugprone-inc-dec-in-conditions

مواردی را شناسایی می‌کند که یک متغیر درون یک شرط پیچیده هم افزایش/کاهش یافته و هم به آن ارجاع داده شده است، و پیشنهاد می‌دهد برای جلوگیری از ابهام در مقدار متغیر، این عملیات به بیرون منتقل شود.

هنگامی که یک متغیر تغییر داده شده و هم‌زمان در یک شرط پیچیده استفاده می‌شود، می‌تواند رفتارهای غیرمنتظره‌ای به همراه داشته باشد. اثر جانبی تغییر مقدار متغیر درون شرط می‌تواند تحلیل و درک کد را دشوار سازد. علاوه بر این، زمان‌بندی مد نظر توسعه‌دهنده برای اصلاح متغیر ممکن است نامشخص باشد و منجر به سوءتفاهم و خطا شود. این موضوع به‌ویژه زمانی که شرط شامل عملگرهای منطقی مانند && و || باشد مشکل‌سازتر می‌شود، جایی که ترتیب ارزیابی شرایط را پیچیده‌تر می‌کند.

مثال زیر را در نظر بگیرید:

int i = 0;
// ...
if (i++ < 5 && i > 0) {
  // do something
}

در این مثال، ممکن است نتیجه عبارت آن چیزی نباشد که توسعه‌دهنده قصد داشته است. قصد اولیه توسعه‌دهنده ممکن است افزایش i پس از ارزیابی کل شرط بوده باشد، اما در واقعیت، i پیش از اجرای i > 0 افزایش خواهد یافت. این موضوع می‌تواند به رفتار غیرمنتظره و باگ‌ها در کد منجر شود. برای رفع این مشکل، توسعه‌دهنده باید عملیات افزایش را از شرط جدا کرده و به‌طور مستقل انجام دهد. به‌عنوان مثال، می‌تواند i را در یک دستور جداگانه قبل یا بعد از ارزیابی شرط افزایش دهد. این کار تضمین می‌کند که مقدار i در سراسر کد قابل پیش‌بینی و پایدار باشد.

int i = 0;
// ...
i++;
if (i <= 5 && i > 0) {
  // do something
}

یک مشکل رایج دیگر زمانی رخ می‌دهد که چندین عمل افزایش یا کاهش روی همان متغیر درون یک شرط پیچیده انجام شود. به عنوان مثال:

int i = 4;
// ...
if (i++ < 5 || --i > 2) {
  // do something
}

به دلیل ترتیب ارزیابی در C++ یک مشکل بالقوه در این کد وجود دارد. عملگر || استفاده‌شده در عبارت شرط تضمین می‌کند که اگر عملوند اول برابر با true ارزیابی شود، عملوند دوم ارزیابی نخواهد شد. این بدان معناست که اگر i در ابتدا 4 باشد، عملوند اول یعنی i < 5 مقدار true خواهد داشت و عملوند دوم یعنی i > 2 ارزیابی نخواهد شد. در نتیجه، عملیات کاهش --i اجرا نخواهد شد و i مقدار 5 را نگه می‌دارد، که ممکن است رفتار مورد نظر توسعه‌دهنده نباشد.

برای جلوگیری از این مشکل بالقوه، هر دو عملیات افزایش و کاهش روی i باید به خارج از عبارت شرط منتقل شوند.

bugprone-incorrect-enable-if

استفاده‌های نادرست از std::enable_if را که نوع تودرتوی type را نام نمی‌برند، تشخیص می‌دهد.

در C++11 ویژگی std::enable_if به عنوان روشی مناسب برای بهره‌گیری از SFINAE معرفی شد. یکی از روش‌های استفاده از std::enable_if، تعریف یک پارامتر نوع قالب بی‌نام با نوع پیش‌فرض برابر با typename std::enable_if<condition>::type است. اگر نویسنده نام بردن نوع تودرتوی type را فراموش کند، کد همیشه قالب کاندید را مد نظر قرار می‌دهد، حتی اگر شرط برقرار نباشد.

در زیر نمونه‌هایی از کدهایی که به درستی از std::enable_if استفاده می‌کنند و نمونه‌های نادرستی که توسط این بررسی پرچم‌گذاری می‌شوند، آمده است.

template <typename T, typename = typename std::enable_if<T::some_trait>::type>
void valid_usage() { ... }
template <typename T, typename = std::enable_if_t<T::some_trait>>
void valid_usage_with_trait_helpers() { ... }
// The below code is not a correct application of SFINAE. Even if
// T::some_trait is not true, the function will still be considered in the
// set of function candidates. It can either incorrectly select the function
// when it should not be a candidates, and/or lead to hard compile errors
// if the body of the template does not compile if the condition is not
// satisfied.
template <typename T, typename = std::enable_if<T::some_trait>>
void invalid_usage() { ... }
// The tool suggests the following replacement for 'invalid_usage':
template <typename T, typename = typename std::enable_if<T::some_trait>::type>
void fixed_invalid_usage() { ... }

در C++14 ویژگی کمکی std::enable_if_t معرفی شد که احتمال بروز این خطا را کاهش می‌دهد. C++20 قیود (constraints) را معرفی می‌کند که به‌طور کلی جایگزین استفاده از std::enable_if می‌شوند. برای ابزار دیگری که std::enable_if را با std::enable_if_t جایگزین می‌کند به modernize-type-traits <> مراجعه کنید، و برای ابزاری که std::enable_if را با قیود C++20 جایگزین می‌سازد به modernize-use-constraints <> رجوع کنید. در صورت امکان استفاده از این سازوکارهای جدیدتر را مد نظر قرار دهید.

bugprone-incorrect-enable-shared-from-this

کلاس‌ها یا ساختارهایی را که به‌صورت عمومی (public) از std::enable_shared_from_this ارث‌بری نمی‌کنند شناسایی می‌کند، چرا که در غیر این صورت هنگام فراخوانی shared_from_this رفتارهای ناخواسته‌ای رخ خواهد داد.

کد زیر را در نظر بگیرید:

#include <memory>
// private inheritance
class BadExample : std::enable_shared_from_this<BadExample> {
// ``shared_from_this``` unintended behaviour
// `libstdc++` implementation returns uninitialized ``weak_ptr``
    public:
    BadExample* foo() { return shared_from_this().get(); }
    void bar() { return; }
};
void using_not_public() {
    auto bad_example = std::make_shared<BadExample>();
    auto* b_ex = bad_example->foo();
    b_ex->bar();
}

با استفاده از پیاده‌سازی libstdc++، فراخوانی shared_from_this استثنای std::bad_weak_ptr را صادر می‌کند. هنگام فراخوانی using_not_public()، این کد در صورت عدم مدیریت استثنا، کرش خواهد کرد.

bugprone-incorrect-roundings

استفاده از الگوهایی را بررسی می‌کند که به ایجاد گرد کردن‌های نادرست شناخته شده‌اند. برنامه‌نویسان اغلب از الگوی زیر استفاده می‌کنند:

(int)(double_expression + 0.5)

تا عبارت ممیز شناور مضاعف (double) را به یک عدد صحیح گرد کنند. مشکل این روش عبارت است از:

bugprone-infinite-loop

حلقه‌های بی‌نهایت آشکار را پیدا می‌کند (حلقه‌هایی که در آن‌ها متغیر شرط حلقه اصلاً تغییر نمی‌کند).

مشخص است که یافتن کلی حلقه‌های بی‌نهایت از نظر تئوری غیرممکن است (مسئله توقف یا Halting Problem). با این حال، می‌توان برخی از حلقه‌های بی‌نهایت واضح را شناسایی کرد، برای نمونه زمانی که شرط حلقه تغییر نمی‌کند. این بررسی چنین حلقه‌هایی را شناسایی می‌کند. یک حلقه در صورتی بی‌نهایت در نظر گرفته می‌شود که فاقد هرگونه دستور خروج از حلقه (break، continue، goto، return، throw یا فراخوانی تابعی با ویژگی [[noreturn]]) باشد و تمامی شرایط زیر برای تک‌تک متغیرهای موجود در شرط برقرار باشد:

علاوه بر این، برای اینکه حلقه بی‌نهایت تلقی شود، شرط نباید حاوی فراخوانی تابع باشد چرا که توابع ممکن است در فراخوانی‌های مختلف مقادیر متفاوتی برگردانند.

به عنوان مثال، در حلقه زیر متغیر i در بدنه حلقه تغییری نمی‌کند و بی‌نهایت تلقی می‌شود:

int i = 0, j = 0;
while (i < 10) {
  ++j;
}

bugprone-integer-division

مواردی را پیدا می‌کند که در آن‌ها تقسیم عدد صحیح در یک زمینه ممیز شناور (floating point) به احتمال زیاد باعث از دست رفتن ناخواسته دقت محاسبات می‌شود.

در صورتی که تقسیم‌ها بخشی از عبارات زیر باشند، هیچ هشداری گزارش نمی‌شود:

زیرا این موارد به عنوان نشانه‌هایی از عمدی بودن عمل برنامه‌نویس تفسیر می‌شوند.

مثال‌ها:

float floatFunc(float);
int intFunc(int);
double d;
int i = 42;
// Warn, floating-point values expected.
d = 32 * 8 / (2 + i);
d = 8 * floatFunc(1 + 7 / 2);
d = i / (1 << 4);
// OK, no integer division.
d = 32 * 8.0 / (2 + i);
d = 8 * floatFunc(1 + 7.0 / 2);
d = (double)i / (1 << 4);
// OK, there are signs of deliberateness.
d = 1 << (i / 2);
d = 9 + intFunc(6 * i / 32);
d = (int)(i / 32) - 8;

bugprone-invalid-enum-default-initialization

مقداردهی اولیه پیش‌فرض (به مقدار 0) متغیرهایی از نوع enum را شناسایی می‌کند که در آن‌ها شمارشگر فاقد مقداری با ارزش 0 است.

در زبان ++C، اگر متغیری با فهرست مقداردهی (initializer list) یا روش‌های ضمنی دیگر مقداردهی شود و هیچ مقداری در زمان مقداردهی تعیین نگردد، مقداردهی اولیه پیش‌فرض انجام می‌شود. در چنین مواردی از مقدار 0 برای مقداردهی اولیه استفاده می‌شود. این موضوع حتی اگر شمارشگر مقداری با ارزش 0 نداشته باشد نیز برای شمارش‌ها اعمال می‌گردد. در نتیجه، یک متغیر از نوع enum ممکن است در ابتدا حاوی مقداری نامعتبر باشد (اگر برنامه انتظار داشته باشد که تنها شامل مقادیر شمارشگر فهرست‌شده باشد).

این بررسی تنها در صورتی هشدار صادر می‌کند که یک متغیر enum به‌صورت پیش‌فرض مقداردهی اولیه شده باشد (نه اینکه بدون مقداردهی رها شده باشد) و آن enum فاقد شمارشگری با مقدار 0 باشد. این نوع می‌تواند یک enum دامنه‌دار (scoped) یا بدون دامنه (non-scoped) باشد. اجتماع‌ها (unions) توسط این بررسی مدیریت نمی‌شوند (در صورتی که عضوی از نوع شمارشی داشته باشند).

توجه داشته باشید که enum مربوط به std::errc همیشه نادیده گرفته می‌شود زیرا انتظار می‌رود به‌صورت پیش‌فرض مقداردهی اولیه شود، با وجود اینکه هیچ شمارشگری با مقدار 0 تعریف نمی‌کند.

enum class Enum1: int {
  A = 1,
  B
};
enum class Enum0: int {
  A = 0,
  B
};
void f() {
  Enum1 X1{}; // warn: 'X1' is initialized to 0
  Enum1 X2 = Enum1(); // warn: 'X2' is initialized to 0
  Enum1 X3; // no warning: 'X3' is not initialized
  Enum0 X4{}; // no warning: type has an enumerator with value of 0
}
struct S1 {
  Enum1 A;
  S(): A() {} // warn: 'A' is initialized to 0
};
struct S2 {
  int A;
  Enum1 B;
};
S2 VarS2{}; // warn: member 'B' is initialized to 0

این بررسی برای مقداردهی اولیه آرایه‌ها یا ساختارها با فهرست‌های مقداردهی در کد C نیز اعمال می‌شود. در این موارد، عناصری که در فهرست مشخص نشده‌اند (و از نوع enum هستند) بر روی 0 تنظیم می‌شوند.

enum Enum1 {
  Enum1_A = 1,
  Enum1_B
};
struct Struct1 {
  int a;
  enum Enum1 b;
};
enum Enum1 Array1[2] = {Enum1_A}; // warn: omitted elements are initialized to 0
enum Enum1 Array2[2][2] = {{Enum1_A}, {Enum1_A}}; // warn: last element of both nested arrays is initialized to 0
enum Enum1 Array3[2][2] = {{Enum1_A, Enum1_A}}; // warn: elements of second array are initialized to 0
struct Struct1 S1 = {1}; // warn: element 'b' is initialized to 0

گزینه‌ها

bugprone-lambda-function-name

تلاش‌ها برای دریافت نام یک تابع از درون یک عبارت لامبدا (lambda) را بررسی می‌کند. نام یک لامبدا همیشه چیزی شبیه به operator() است که تقریباً هیچ‌گاه مقصود اصلی برنامه‌نویس نبوده است.

مثال:

void FancyFunction() {
  [] { printf("Called from %s\n", __func__); }();
  [] { printf("Now called from %s\n", __FUNCTION__); }();
}

خروجی:

Called from operator()
Now called from operator()

خروجی احتمالاً مورد نظر:

Called from FancyFunction
Now called from FancyFunction

گزینه‌ها

bugprone-macro-parentheses

ماکروهایی را می‌یابد که به دلیل نبود پرانتز ممکن است رفتارهای غیرمنتظره داشته باشند.

ماکروها توسط پیش‌پردازنده دقیقاً همان‌طور که هستند بسط می‌یابند. در نتیجه، ممکن است رفتارهای غیرمنتظره‌ای رخ دهد؛ عملگرها ممکن است با ترتیبی غیرمنتظره ارزیابی شوند و عملگرهای یگانی ممکن است به عملگرهای دوتایی تبدیل شوند، و غیره.

هنگامی که فهرست جایگزینی شامل یک عبارت باشد، توصیه می‌شود آن را در پرانتز قرار دهید. این کار تضمین می‌کند که نتیجه ماکرو قبل از استفاده کاملاً ارزیابی شود.

همچنین توصیه می‌شود آرگومان‌های ماکرو در فهرست جایگزینی در پرانتز قرار گیرند. این کار اطمینان می‌دهد که مقدار آرگومان به درستی محاسبه می‌شود.

این بررسی با قاعده PRE02-C از استاندارد کدنویسی CERT C مطابقت دارد. فهرست‌های جایگزینی ماکرو باید پرانتزگذاری شوند: https://wiki.sei.cmu.edu/confluence/display/c/PRE02-C.+Macro+replacement+lists+should+be+parenthesized

bugprone-macro-repeated-side-effects

آرگومان‌های تکراری دارای اثرات جانبی (side effects) را در ماکروها بررسی می‌کند.

bugprone-misleading-setter-of-reference

توابع عضو شبیه به setter را می‌یابد که یک پارامتر اشاره‌گر دریافت کرده و یک عضو مرجع (reference) از همان کلاس را با مقدار اشاره‌شده تنظیم می‌کنند.

این بررسی توابع عضوی را تشخیص می‌دهد که یک پارامتر اشاره‌گر تکی می‌گیرند و شامل یک دستور عبارت منفرد هستند که پارامتر را dereference کرده و نتیجه را به یک عضو داده‌ای با نوع مرجع اختصاص می‌دهد.

این واقعیت که یک تابع setter اشاره‌گر می‌گیرد ممکن است این باور اشتباه را ایجاد کند که یک مرجع داخلی (در صورتی که اشاره‌گر می‌بود) تغییر می‌کند، به جای مقداری که به آن اشاره شده (یا ارجاع داده شده) است.

مثال:

class MyClass {
  int &InternalRef;  // non-const reference member
public:
  MyClass(int &Value) : InternalRef(Value) {}
  // Warning: This setter could lead to unintended behaviour.
  void setRef(int *Value) {
    InternalRef = *Value;  // This assigns to the referenced value, not changing what InternalRef references.
  }
};
int main() {
  int Value1 = 42;
  int Value2 = 100;
  MyClass X(Value1);
  // This might look like it changes what InternalRef references to,
  // but it actually modifies Value1 to be 100.
  X.setRef(&Value2);
}

bugprone-misplaced-operator-in-strlen-in-alloc

مواردی را می‌یابد که در آن‌ها مقدار 1 به جای نتیجه، به رشته موجود در آرگومان strlen()، strnlen()، strnlen_s()، wcslen()، wcsnlen() و wcsnlen_s() اضافه شده است و این مقدار به عنوان آرگومان یک تابع تخصیص حافظه (malloc()، calloc()، realloc()، alloca()) یا عملگر new[] در C++ استفاده شده است. این بررسی موارد خطا را حتی در صورتی که یکی از این توابع (به جز عملگر new[]) توسط یک اشاره‌گر تابع ثابت فراخوانی شده باشد، شناسایی می‌کند. مواردی که در آن‌ها 1 هم به پارامتر و هم به نتیجه تابع شبه-strlen() اضافه شده است نادیده گرفته می‌شوند، و همچنین مواردی که کل عمل جمع درون پرانتزهای اضافی قرار گرفته باشد.

کد نمونه C:

void bad_malloc(char *str) {
  char *c = (char*) malloc(strlen(str + 1));
}

اصلاح پیشنهادی این است که مقدار 1 به مقدار بازگشتی strlen() اضافه شود نه به آرگومان آن. در مثال بالا اصلاح به شکل زیر خواهد بود

char *c = (char*) malloc(strlen(str) + 1);

کد نمونه C++:

void bad_new(char *str) {
  char *c = new char[strlen(str + 1)];
}

مشابه کد C با تابع malloc()، اصلاح پیشنهادی افزودن 1 به مقدار بازگشتی strlen() است و نه به آرگومان آن. در مثال بالا اصلاح به صورت زیر خواهد بود

char *c = new char[strlen(str) + 1];

مثال برای فرونشاندن (silence) این عیب‌یابی:

void bad_malloc(char *str) {
  char *c = (char*) malloc(strlen((str + 1)));
}

bugprone-misplaced-pointer-arithmetic-in-alloc

مواردی را می‌یابد که در آن‌ها یک عبارت عددی صحیح به‌جای آرگومان توابع تخصیص حافظه (malloc()، calloc()، realloc()، alloca())، به نتیجهٔ خروجی آن‌ها اضافه یا از آن کم شده است. این بررسی خطاهای مربوطه را حتی در صورتی که یکی از این توابع توسط یک اشاره‌گر تابع ثابت فراخوانی شود، تشخیص می‌دهد.

کد نمونه:

void bad_malloc(int n) {
  char *p = (char*) malloc(n) + 10;
}

اصلاح پیشنهادی این است که عبارت عددی صحیح به آرگومان malloc اضافه شود و نه به نتیجهٔ آن. در مثال بالا اصلاح به شکل زیر خواهد بود:

char *p = (char*) malloc(n + 10);

bugprone-misplaced-widening-cast

این بررسی زمانی هشدار می‌دهد که تبدیل نوع (cast) حاصل یک محاسبه به یک نوع بزرگ‌تر انجام شده باشد. اگر هدف از این تبدیل نوع جلوگیری از افت دقت باشد، در این صورت تبدیل در محل نادرستی قرار گرفته و ممکن است افت دقت رخ دهد. در غیر این صورت، تبدیل نوع بی‌اثر و بی‌فایده است.

کد نمونه:

long f(int x) {
    return (long)(x * 1000);
}

نتیجهٔ x * 1000 ابتدا با دقت int محاسبه می‌شود. اگر نتیجه فراتر از دقت نوع int برود، افت دقت رخ می‌دهد. سپس نتیجه به نوع long تبدیل می‌شود.

اگر هیچ افت دقتی وجود ندارد، می‌توان تبدیل نوع را حذف کرد یا به‌طور صریح به نوع int تبدیل نمود.

اگر می‌خواهید از افت دقت جلوگیری کنید، تبدیل نوع را در جای مناسب قرار دهید؛ برای نمونه:

long f(int x) {
    return (long)x * 1000;
}

Implicit casts

فراموش کردن قرار دادن تبدیل نوع به همان اندازهٔ قرار دادن آن در جای نادرست خطرناک بوده و حداقل به همان میزان نیز شایع است. اگر CheckImplicitCasts فعال باشد، این بررسی چنین مواردی را نیز شناسایی می‌کند؛ برای نمونه:

long f(int x) {
    return x * 1000;
}

Floating point

در حال حاضر این هشدارها فقط برای تبدیل اعداد صحیح ثبت می‌شوند. هیچ هشداری برای این کد ثبت نخواهد شد:

double f(float x) {
    return (double)(x * 10.0f);
}

Options

bugprone-move-forwarding-reference

اگر تابع std::move روی یک مرجع ارجاعی (forwarding reference) فراخوانی شود، هشدار می‌دهد؛ برای نمونه:

template <typename T>
void foo(T&& t) {
  bar(std::move(t));
}

مراجع ارجاعی (forwarding references) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4164.pdf معمولاً باید به‌جای std::move به تابع std::forward ارسال شوند، و این همان اصلاحی است که پیشنهاد خواهد شد.

(یک مرجع ارجاعی، ارجاع rvalue از نوعی است که یک آرگومان قالب تابع استنباط‌شده می‌باشد.)

در این مثال، اصلاح پیشنهادی به این صورت خواهد بود:

bar(std::forward<T>(t));

Background

کدهایی مانند مثال بالا گاهی با این انتظار نوشته می‌شوند که T&& صرف‌نظر از نوعی که برای T استنباط می‌شود همواره یک مرجع rvalue باقی خواهد ماند، و بنابراین امکان ارسال یک lvalue به foo() وجود ندارد. با این حال، این موضوع درست نیست. این مثال را در نظر بگیرید:

std::string s = "Hello, world";
foo(s);

این کد کامپایل می‌شود و پس از فراخوانی تابع foo()، متغیر s در یک وضعیت نامشخص (indeterminate state) باقی می‌ماند زیرا داده‌های آن منتقل شده‌اند (moved from). این موضوع ممکن است برای فراخوانندهٔ foo() غافلگیرکننده باشد زیرا هنگام فراخوانی foo() از هیچ std::move استفاده نشده است.

دلیل این رفتار در قاعدهٔ خاص استنباط آرگومان قالب روی قالب‌های تابعی مانند foo() نهفته است -- یعنی روی قالب‌های تابعی که یک آرگومان با ارجاع rvalue از نوعی که آرگومان قالب تابع استنباط‌شده است، دریافت می‌کنند. (بخش [temp.deduct.call]/3 را در استاندارد C++11 ببینید.)

اگر foo() روی یک lvalue فراخوانی شود (مانند مثال بالا)، آنگاه نوع T به عنوان یک مرجع lvalue استنباط می‌شود. در این مثال، T به صورت std::string & استنباط می‌شود. در نتیجه نوع آرگومان t به std::string& && تبدیل می‌شود؛ طبق قوانین انحلال ارجاع (reference collapsing)، این ساختار به std::string& فروپاشی می‌شود.

این بدان معناست که فراخوانی foo(s) متغیر s را به عنوان یک مرجع lvalue ارسال می‌کند، و foo() در نهایت عملیات move را روی s انجام داده و در نتیجه آن را در وضعیتی نامشخص قرار می‌دهد.

bugprone-multi-level-implicit-pointer-conversion

تبدیل‌های ضمنی میان اشاره‌گرهایی با سطوح غیرمستقیم (indirection) متفاوت را تشخیص می‌دهد.

تبدیل بین انواع اشاره‌گر با سطوح ارجاع غیرمستقیم متفاوت می‌تواند خطرناک باشد و ممکن است به رفتار تعریف‌نشده (undefined behavior) منجر شود، به‌ویژه اگر اشاره‌گر تبدیل‌شده بعداً به نوعی با سطح ارجاع غیرمستقیم متفاوتی تبدیل نوع (cast) شود. برای مثال، تبدیل اشاره‌گر به اشاره‌گری از نوع int (int**) به یک void* می‌تواند منجر به از دست رفتن اطلاعات درباره سطح اصلی ارجاع غیرمستقیم شود، که این موضوع هنگام تلاش برای استفاده از اشاره‌گر تبدیل‌شده مشکل‌ساز خواهد بود. اگر اشاره‌گر تبدیل‌شده بعداً به نوعی با سطح متفاوتی از ارجاع غیرمستقیم cast شده و عمل dereference روی آن انجام شود، ممکن است باعث خطاهای دسترسی به حافظه (access violation)، خرابی حافظه (memory corruption) یا سایر رفتارهای تعریف‌نشده شود.

مثال زیر را در نظر بگیرید:

void foo(void* ptr);
int main() {
  int x = 42;
  int* ptr = &x;
  int** ptr_ptr = &ptr;
  foo(ptr_ptr); // warning will trigger here
  return 0;
}

در این مثال، foo() با آرگومان ptr_ptr فراخوانی شده است. با این حال، ptr_ptr یک اشاره‌گر از نوع int** است، در حالی که foo() یک اشاره‌گر void* را انتظار دارد. این امر موجب یک تبدیل ضمنی در سطح اشاره‌گر می‌شود که چنانچه foo() با فرض اینکه اشاره‌گر از نوع int* است آن را dereference کند، می‌تواند مشکلاتی به بار آورد.

استفاده از تبدیل صریح (explicit cast) راه‌حلی توصیه‌شده برای جلوگیری از مشکلات ناشی از تبدیل ضمنی سطح اشاره‌گر است، چرا که به توسعه‌دهنده امکان می‌دهد قصد و استدلال خود را برای تبدیل نوع صراحتاً بیان کند. علاوه بر این، توصیه می‌شود که توسعه‌دهندگان پیش از استفاده از تبدیل نوع صریح، ایمنی تبدیل را به‌دقت بررسی و تایید کنند. این سطح احتیاط بیشتر می‌تواند به شناسایی زودهنگام مشکلات احتمالی در فرآیند توسعه کمک کند و پایداری و نگه‌داری‌پذیری کلی کد را بهبود بخشد.

گزینه‌ها

bugprone-multiple-new-in-one-expression

فراخوانی‌های متعدد عملگر new را در یک عبارت واحد پیدا می‌کند، جایی که اگر تخصیص دوم با شکست مواجه شده و یک استثنا (exception) پرتاب کند، حافظه تخصیص‌یافته توسط new اول ممکن است دچار نشت (leak) شود.

زبان C++ اغلب ترتیب دقیق ارزیابی عملوندهای یک عملگر یا آرگومان‌های یک تابع را مشخص نمی‌کند. بنابراین اگر اولین تخصیص با موفقیت انجام شود و دومی شکست بخورد، در یک مدیریت‌کننده استثنا (exception handler) نمی‌توان تشخیص داد که کدام تخصیص با شکست مواجه شده تا حافظه آن آزاد شود. حتی اگر ترتیب مشخص باشد، ممکن است نتیجه اولین new در یک مکان موقت ذخیره شود که در زمان شکست تخصیص دوم قابل دسترسی نباشد. بهتر است در صورتی که برای بررسی خطاهای تخصیص از مدیریت استثنا استفاده می‌شود، از هرگونه عبارتی که شامل بیش از یک فراخوانی operator new است اجتناب شود.

قوانین متفاوتی برای عملگرهای اتصال کوتاه (short-circuit) مانند || و && و عملگر , اعمال می‌شود، که در آن‌ها ارزیابی یک سمت باید پیش از شروع ارزیابی سمت دیگر کامل شود. عبارات یک راه‌اندازی لیستی (list-initialization یا مقداردهی اولیه یا ساخت شیء با استفاده از نویسه‌های { و }) با ترتیب ثابت ارزیابی می‌شوند. به همین ترتیب، شرط عملگر سه‌تایی ? پیش از ارزیابی شاخه‌ها ارزیابی می‌شود.

این بررسی در صورتی هشدار می‌دهد که دو فراخوانی new در دو سمت مختلف یک عملگر در یک عبارت ظاهر شوند، یا اگر فراخوانی‌های new در آرگومان‌های متفاوتی از یک فراخوانی تابع (که می‌تواند ساخت شیء با نحو () باشد) ظاهر شوند. این فراخوانی‌های new می‌توانند در هر سطحی تودرتو باشند. برای صدور هشدار، فراخوانی‌های new باید در یک بلوک کد باشند که در آن از مدیریت استثنا همراه با catch برای std::bad_alloc یا std::exception استفاده شده باشد. برای عملگرهای ||، &&، , و ? (شرط و یک شاخه) هشداری صادر نمی‌شود. همچنین در صورتی که هر دو تخصیص حافظه به یک متغیر انتساب نیافته یا مستقیماً به یک تابع ارسال نشده باشند، هشداری صادر نخواهد شد. دلیل این امر آن است که در این حالت ممکن است حافظه عمداً آزاد نشده باشد یا اشیاء تخصیص‌یافته ممکن است اشیائی خودتخریب‌گر (self-destructing) باشند.

مثال‌ها:

struct A {
  int Var;
};
struct B {
  B();
  B(A *);
  int Var;
};
struct C {
  int *X1;
  int *X2;
};
void f(A *, B *);
int f1(A *);
int f1(B *);
bool f2(A *);
void foo() {
  A *PtrA;
  B *PtrB;
  try {
    // Allocation of 'B'/'A' may fail after memory for 'A'/'B' was allocated.
    f(new A, new B); // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception; order of these allocations is undefined
    // List (aggregate) initialization is used.
    C C1{new int, new int}; // no warning
    // Allocation of 'B'/'A' may fail after memory for 'A'/'B' was allocated but not yet passed to function 'f1'.
    int X = f1(new A) + f1(new B); // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception; order of these allocations is undefined
    // Allocation of 'B' may fail after memory for 'A' was allocated.
    // From C++17 on memory for 'B' is allocated first but still may leak if allocation of 'A' fails.
    PtrB = new B(new A); // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception
    // 'new A' and 'new B' may be performed in any order.
    // 'new B'/'new A' may fail after memory for 'A'/'B' was allocated but not assigned to 'PtrA'/'PtrB'.
    (PtrA = new A)->Var = (PtrB = new B)->Var; // warning: memory allocation may leak if an other allocation is sequenced after it and throws an exception; order of these allocations is undefined
    // Evaluation of 'f2(new A)' must be finished before 'f1(new B)' starts.
    // If 'new B' fails the allocated memory for 'A' is supposedly handled correctly because function 'f2' could take the ownership.
    bool Z = f2(new A) || f1(new B); // no warning
    X = (f2(new A) ? f1(new A) : f1(new B)); // no warning
    // No warning if the result of both allocations is not passed to a function
    // or stored in a variable.
    (new A)->Var = (new B)->Var; // no warning
    // No warning if at least one non-throwing allocation is used.
    f(new(std::nothrow) A, new B); // no warning
  } catch(std::bad_alloc) {
  }
  // No warning if the allocation is outside a try block (or no catch handler exists for std::bad_alloc).
  // (The fact if exceptions can escape from 'foo' is not taken into account.)
  f(new A, new B); // no warning
}

bugprone-multiple-statement-macro

ماکروهای چنددستوری که در عبارات شرطی بدون آکولاد استفاده می‌شوند را شناسایی می‌کند. تنها اولین دستور ماکرو درون شرط قرار می‌گیرد و سایر دستورها بدون قید و شرط اجرا خواهند شد.

مثال:

#define INCREMENT_TWO(x, y) (x)++; (y)++
if (do_increment)
  INCREMENT_TWO(a, b);  // (b)++ will be executed unconditionally.

// The following function definition demonstrates usage of arithmetic with
// integer types smaller than `int` and how the narrowing conversion happens
// implicitly.
void computation(short argument1, short argument2) {
  // Arithmetic written by humans:
  short result = argument1 + argument2;
  // Arithmetic actually performed by C++:
  short result = static_cast<short>(static_cast<int>(argument1) + static_cast<int>(argument2));
}
void recommended_resolution(short argument1, short argument2) {
  short result = argument1 + argument2;
  //           ^ warning: narrowing conversion from 'int' to signed type 'short' is implementation-defined
  // The cppcoreguidelines recommend to resolve this issue by using the GSL
  // in one of two ways. Either by a cast that throws if a loss of precision
  // would occur.
  short result = gsl::narrow<short>(argument1 + argument2);
  // Or it can be resolved without checking the result risking invalid results.
  short result = gsl::narrow_cast<short>(argument1 + argument2);
  // A classical `static_cast` will silence the warning as well if the GSL
  // is not available.
  short result = static_cast<short>(argument1 + argument2);
}

گزینه‌ها (Options)

پرسش‌های متداول (FAQ)

یک عدد ممیز شناور با استاندارد IEEE754 می‌تواند تمامی مقادیر صحیح در محدوده [-2^PrecisionBits, 2^PrecisionBits] را نمایش دهد، که در آن PrecisionBits تعداد بیت‌های مانتیس است.

برای نوع float این محدوده [-2^23, 2^23] خواهد بود، در حالی که int می‌تواند مقادیر را در محدوده [-2^31, 2^31-1] نمایش دهد.

ممکن است با پیام‌هایی مانند "narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined" مواجه شده باشید. استاندارد C/C++ قالب متمم دو (two's complement) را برای اعداد صحیح علامت‌دار اجباری نمی‌کند، بنابراین کامپایلر آزاد است معناشناسی و رفتار تبدیل یک عدد صحیح بدون علامت به عدد صحیح علامت‌دار را تعیین کند. پیاده‌سازی Clang از فرمت متمم دو استفاده می‌کند.

bugprone-no-escape

اشاره‌گرهایی با مشخصهٔ noescape را پیدا می‌کند که توسط یک بلوک با اجرای ناهمگام (asynchronously-executed) تسخیر (capture) شده‌اند. آرگومان‌های بلوک در dispatch_async() و dispatch_after() تضمین شده است که فرار (escape) می‌کنند، بنابراین اگر اشاره‌گری با صفت noescape توسط یکی از این بلوک‌ها تسخیر شود، یک خطا محسوب می‌شود.

در ادامه نمونه‌ای از استفادهٔ نامعتبر از مشخصهٔ noescape آورده شده است.

void foo(__attribute__((noescape)) int *p) {
  dispatch_async(queue, ^{
    *p = 123;
  });
});

bugprone-non-zero-enum-to-bool-conversion

تبدیل‌های نوع (cast) ضمنی و صریح از نوع enum به bool را در جایی که نوع enum دارای شمارنده‌ای با مقدار صفر نباشد، شناسایی می‌کند. اگر enum تنها برای نگهداری مقادیر برابر با شمارنده‌های خود استفاده شود، در این صورت تبدیل به bool همیشه منجر به مقدار true خواهد شد. این موضوع می‌تواند منجر به کدهای غیرضروری شود که خوانایی و نگه‌داری‌پذیری را کاهش داده و باعث ایجاد باگ شوند.

اگر از enum برای ذخیرهٔ مقادیر دیگر استفاده شود (استفاده به عنوان ماسک بیتی یا مقداردهی اولیهٔ عمدی با صفر)، ممکن است موارد مثبت کاذب (false positive) ایجاد کند. برای مقابله با آن‌ها، می‌توان از // NOLINT یا تبدیل نوع ابتدا به نوع زیربنایی پیش از تبدیل به bool استفاده کرد.

توجه به این نکته مهم است که اگر تعریف نوع شمارشی در دسترس نباشد، این بررسی هیچ هشداری تولید نخواهد کرد. علاوه بر این، کلاس‌های شمارشی C++11 نیز توسط این بررسی پشتیبانی می‌شوند.

به طور کلی، این بررسی با شناسایی و علامت‌گذاری مواردی که در آن‌ها تبدیل نوع‌های ضمنی یا صریح از انواع شمارشی به بولی می‌تواند مشکلات احتمالی ایجاد کند، به بهبود کیفیت و خوانایی کد کمک می‌کند.

مثال

enum EStatus {
  OK = 1,
  NOT_OK,
  UNKNOWN
};
void process(EStatus status) {
  if (!status) {
    // this true-branch won't be executed
    return;
  }
  // proceed with "valid data"
}

گزینه‌ها

bugprone-nondeterministic-pointer-iteration-order

استفاده‌های غیرقطعی (nondeterministic) از اشاره‌گرها در کانتینرهای بدون ترتیب (unordered containers) را پیدا می‌کند.

یک نمونهٔ بارز، پیمایش روی کانتینری از اشاره‌گرها است.

{
  int a = 1, b = 2;
  std::unordered_set<int *> UnorderedPtrSet = {&a, &b};
  for (auto i : UnorderedPtrSet)
    f(i);
}

نمونهٔ دیگر، مرتب‌سازی کانتینری از اشاره‌گرها است.

{
  int a = 1, b = 2;
  std::vector<int *> VectorOfPtr = {&a, &b};
  std::sort(VectorOfPtr.begin(), VectorOfPtr.end());
}

پیمایش کانتینری از اشاره‌گرها ممکن است ترتیب اشاره‌گرهای مختلف را در اجراهای گوناگون یک برنامه به شکل متفاوتی ارائه دهد. در برخی موارد ممکن است این رفتاری قابل قبول باشد، و در موارد دیگر می‌تواند رفتاری غیرمنتظره به بار آورد. این بررسی به همین دلیل جنبهٔ مشورتی دارد.

این بررسی فقط حلقه‌های for مبتنی بر بازه (range-based for loops) را روی setها و mapهای unordered تشخیص می‌دهد. همچنین فراخوانی الگوریتم‌های شبیه به مرتب‌سازی را روی کانتینرهای حاوی اشاره‌گر شناسایی می‌کند. سایر استفاده‌های مشابه پیدا نخواهند شد و به عنوان منفی کاذب (false negative) در نظر گرفته می‌شوند.

محدودیت‌ها

bugprone-not-null-terminated-result

فراخوانی‌های تابعی را پیدا می‌کند که در آن‌ها امکان ایجاد نتیجه‌ای بدون پایان‌دهندهٔ تهی (not null-terminated) وجود دارد. معمولاً طول مناسب یک رشته strlen(src) + 1 یا طولی برابر با این عبارت است، زیرا پایان‌دهندهٔ تهی به فضای اضافی نیاز دارد. بدون پایان‌دهندهٔ تهی، خواندن رشته ممکن است منجر به رفتار تعریف‌نشده (undefined behavior) شود.

توابع زیر و توابع معادل مبتنی بر wchar_t آن‌ها بررسی می‌شوند:

memcpy, memcpy_s, memchr, memmove, memmove_s, strerror_s, strncmp, strxfrm

در ادامه یک مثال واقعی آورده شده است که در آن برنامه‌نویس فراموش کرده آرگومان سوم ارسالی را، یعنی size_t length، افزایش دهد. به همین دلیل طول حافظهٔ تخصیص‌یافته برای نگهداری پایان‌دهندهٔ تهی کافی نیست.

static char *stringCpy(const std::string &str) {
  char *result = reinterpret_cast<char *>(malloc(str.size()));
  memcpy(result, str.data(), str.size());
  return result;
}

علاوه بر صدور هشدارها، قابلیت اصلاح خودکار (fix-it) تمام کدهای لازم را بازنویسی می‌کند. همچنین تلاش می‌کند ظرفیت آرایهٔ مقصد را تنظیم نماید:

static char *stringCpy(const std::string &str) {
  char *result = reinterpret_cast<char *>(malloc(str.size() + 1));
  strcpy(result, str.data());
  return result;
}

نکته: هیچ تضمینی وجود ندارد که تمامی تخصیص‌های حافظهٔ حساس به مسیر (path-sensitive) بازنویسی شوند.

قواعد تبدیل 'memcpy()'

امکان بازنویسی فراخوانی‌های memcpy() و memcpy_s() به چهار تابع زیر وجود دارد: strcpy()، strncpy()، strcpy_s() و strncpy_s()، که دو مورد آخر نسخه‌های امن‌تر دو مورد اول هستند. این بررسی توابع مدیریت حافظه مبتنی بر wchar_t را نیز به همین ترتیب بازنویسی می‌کند.

بازنویسی بر اساس آرایه مقصد

بازنویسی بر اساس طول رشته مبدا

تبدیل‌ها با 'strlen()' یا طول معادل این عبارت

این بررسی توابع مدیریت حافظه و رشته مبتنی بر wchar_t را به همین ترتیب تبدیل می‌کند (که در این میان فقط strerror_s نام مستعار مبتنی بر wchar_t ندارد).

توابع مدیریت حافظه

memcpy لطفاً بخش قواعد تبدیل 'memcpy()' را بررسی کنید.

memchr معمولاً یک C-style cast وجود دارد که باید حذف شود، زیرا نوع بازگشتی تابع جدید strchr صحیح است. طول داده‌شده حذف خواهد شد.

memmove اگر توابع امن در دسترس باشند، تابع جدید memmove_s خواهد بود که آرگومان دوم جدیدی شامل طول آرایه مقصد دارد؛ این آرگومان تنظیم شده و طول رشته مبدا یک واحد افزایش می‌یابد. اگر توابع امن در دسترس نباشند، طول داده‌شده یک واحد افزایش می‌یابد.

memmove_s طول داده‌شده یک واحد افزایش می‌یابد.

توابع مدیریت رشته

strerror_s طول داده‌شده یک واحد افزایش می‌یابد.

strncmp اگر آرگومان سوم برابر با length + 1 آرگومان اول یا دوم باشد، باید بدون عملیات + 1 کوتاه شود.

strxfrm طول داده‌شده یک واحد افزایش می‌یابد.

گزینه‌ها

bugprone-optional-value-conversion

تبدیل‌های بالقوه ناخواسته و زائدی را شناسایی می‌کند که در آن‌ها مقداری از یک نوع اختیاری‌مانند (optional-like) استخراج شده و سپس برای ایجاد نمونه جدیدی از همان نوع اختیاری‌مانند استفاده می‌شود.

این تبدیل‌ها ممکن است ناشی از سهل‌انگاری توسعه‌دهنده، بقایای بازنویسی و بازآفرینی کد (refactoring)، یا شرایط دیگری باشند که می‌توانند منجر به استثناهای ناخواسته شوند یا مواردی ایجاد کنند که اختیاری حاصل همواره مقداردهی اولیه شده باشد، که ممکن است رفتاری غیرمنتظره باشد.

برای تشریح این موضوع، قطعه کد مشکل‌دار زیر را در نظر بگیرید:

#include <optional>
void print(std::optional<int>);
int main()
{
  std::optional<int> opt;
  // ...
  // Unintentional conversion from std::optional<int> to int and back to
  // std::optional<int>:
  print(opt.value());
  // ...
}

رویکرد بهتر این است که بدون استخراج مقدار، opt را مستقیماً به تابع print پاس دهید:

#include <optional>
void print(std::optional<int>);
int main()
{
  std::optional<int> opt;
  // ...
  // Proposed code: Directly pass the std::optional<int> to the print
  // function.
  print(opt);
  // ...
}

با پاس دادن مستقیم opt به تابع print، از تبدیل‌های غیرضروری جلوگیری شده و رفتارها یا استثناهای بالقوه ناخواسته به حداقل می‌رسند.

استخراج مقدار با استفاده از operator * به‌صورت پیش‌فرض تطبیق داده می‌شود. پشتیبانی از انواع غیراستاندارد اختیاری مانند boost::optional یا absl::optional ممکن است محدود باشد.

گزینه‌ها:

bugprone-parent-virtual-call

فراخوانی متدهای مجازی کلاس‌های نیا-...-والد را به‌جای فراخوانی متدهای مجازی بازنویسی‌شدهٔ (overridden) والد شناسایی و تصحیح می‌کند.

struct A {
  int virtual foo() {...}
};
struct B: public A {
  int foo() override {...}
};
struct C: public B {
  int foo() override { A::foo(); }
//                     ^^^^^^^^
// warning: qualified name A::foo refers to a member overridden in subclass; did you mean 'B'?  [bugprone-parent-virtual-call]
};

bugprone-pointer-arithmetic-on-polymorphic-object

محاسبات اشاره‌گر (pointer arithmetic) انجام‌شده روی کلاس‌هایی که حاوی تابع مجازی هستند را پیدا می‌کند.

محاسبات اشاره‌گر روی اشیاء چندریختی (polymorphic) هنگامی که نوع ایستا (static type) اشاره‌گر با نوع پویا (dynamic type) آن متفاوت باشد، رفتار تعریف‌نشده (undefined behavior) است؛ زیرا این دو نوع ممکن است اندازه‌های متفاوتی داشته باشند و در نتیجه اشاره‌گر جدول متدهای مجازی (vtable) ممکن است به یک آدرس نامعتبر اشاره کند.

یافتن اشاره‌گرهایی که نوع ایستای آن‌ها شامل یک تابع عضو مجازی است، یک روش مکاشفه‌ای (heuristic) مناسب است، زیرا این احتمال وجود دارد که اشاره‌گر به یک شیء مشتق‌شدهٔ متفاوت اشاره کند.

مثال:

struct Base {
  virtual ~Base();
  int i;
};
struct Derived : public Base {};
void foo(Base* b) {
  b += 1;
  // warning: pointer arithmetic on class that declares a virtual function can
  // result in undefined behavior if the dynamic type differs from the
  // pointer type
}
int bar(const Derived d[]) {
  return d[1].i; // warning due to pointer arithmetic on polymorphic object
}
// Making Derived final suppresses the warning
struct FinalDerived final : public Base {};
int baz(const FinalDerived d[]) {
  return d[1].i; // no warning as FinalDerived is final
}

گزینه‌ها

void bar(Base b[], Derived d[]) {
  b += 1; // warning, as Base declares a virtual destructor
  d += 1; // warning only if IgnoreVirtualDeclarationsOnly is set to false
}

مراجع

این بررسی با قاعدهٔ SEI Cert به شمارهٔ CTR56-CPP مطابقت دارد: Do not use pointer arithmetic on polymorphic objects https://wiki.sei.cmu.edu/confluence/display/cplusplus/CTR56-CPP.+Do+not+use+pointer+arithmetic+on+polymorphic+objects.

bugprone-posix-return

بررسی می‌کند که آیا فراخوانی توابع pthread_* یا posix_* (به‌جز posix_openpt) انتظار مقادیر بازگشتی منفی را دارد یا خیر. این توابع در صورت موفقیت مقدار 0 و در صورت شکست یک errno را برمی‌گردانند که تنها مقداری مثبت است.

نمونه‌ای از کاربرد باگ‌دار بدین شکل است:

if (posix_fadvise(...) < 0) {

این حالت هرگز رخ نخواهد داد زیرا مقدار بازگشتی همواره غیرمنفی است. یک اصلاح ساده می‌تواند به‌صورت زیر باشد:

if (posix_fadvise(...) > 0) {

bugprone-random-generator-seed

تمامی موتورهای تولید اعداد شبه‌تصادفی، نمونه‌سازی‌های مبدل موتور (engine adaptor) و تابع srand() را در صورتی که با آرگومان پیش‌فرض، عبارت ثابت (constant expression) یا هر نوع قابل‌پیکربندی توسط کاربر مقداردهی اولیه یا دانه‌گذاری (seed) شوند نشانه‌گذاری می‌کند. موتورهای اعداد شبه‌تصادفی که با مقداری قابل‌پیش‌بینی دانه‌گذاری شوند ممکن است منجر به آسیب‌پذیری‌هایی، برای مثال در پروتکل‌های امنیتی، گردند.

مثال‌ها:

void foo() {
  std::mt19937 engine1; // Diagnose, always generate the same sequence
  std::mt19937 engine2(1); // Diagnose
  engine1.seed(); // Diagnose
  engine2.seed(1); // Diagnose
  std::time_t t;
  engine1.seed(std::time(&t)); // Diagnose, system time might be controlled by user
  int x = atoi(argv[1]);
  std::mt19937 engine3(x);  // Will not warn
}

گزینه‌ها

مراجع

این بررسی با قوانین استاندارد کدنویسی CERT C++ مطابقت دارد: MSC51-CPP. Ensure your random number generator is properly seeded https://wiki.sei.cmu.edu/confluence/display/cplusplus/MSC51-CPP.+Ensure+your+random+number+generator+is+properly+seeded و MSC32-C. Properly seed pseudorandom number generators https://wiki.sei.cmu.edu/confluence/display/c/MSC32-C.+Properly+seed+pseudorandom+number+generators.

bugprone-raw-memory-call-on-non-trivial-type

استفاده از توابع کتابخانه استاندارد C شامل memset، memcpy و memcmp و مشتقات مشابه آن‌ها را روی انواع غیر‌بدیهی (non-trivial types) نشانه‌گذاری می‌کند.

این بررسی توابع زیر را تشخیص خواهد داد: memset، std::memset، std::memcpy، memcpy، std::memmove، memmove، std::strcpy، strcpy، memccpy، stpncpy، strncpy، std::memcmp، memcmp، std::strcmp، strcmp، strncmp.

گزینه‌ها

این بررسی با قاعده استانداردهای کدنویسی CERT C++ مطابقت دارد: OOP57-CPP. Prefer special member functions and overloaded operators to C Standard Library functions https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP57-CPP.+Prefer+special+member+functions+and+overloaded+operators+to+C+Standard+Library+functions.

bugprone-redundant-branch-condition

متغیرهای شرطی را در دستورهای if تودرتو پیدا می‌کند که در دستور if بیرونی نیز بررسی شده‌اند و مقداری در آن‌ها تغییر نکرده است.

مثال ساده:

bool onFire = isBurning();
if (onFire) {
  if (onFire)
    scream();
}

در اینجا onFire هم در دستور if بیرونی و هم در دستور if درونی بدون امکان تغییر میان دو بررسی، چک شده است. این بررسی برای این کد هشدار داده و حذف بررسی دوم متغیر onFire را پیشنهاد می‌کند.

بررسی‌کننده همچنین بررسی‌های شرطی زائد را در صورتی که متغیر شرط عملوند یک عملگر منطقی «و» (&&) یا «یا»ی منطقی (||) باشد تشخیص می‌دهد:

bool onFire = isBurning();
if (onFire) {
  if (onFire && peopleInTheBuilding > 0)
    scream();
}

bool onFire = isBurning();
if (onFire) {
  if (onFire || isCollapsing())
    scream();
}

در حالت اول («و»ی منطقی) اصلاح پیشنهادی حذف متغیر شرط زائد و نگه‌داشتن طرف دیگر && است. در حالت دوم («یا»ی منطقی) کل if مشابه مثال ساده بالا حذف می‌شود.

شرط دستور if بیرونی نیز می‌تواند یک عبارت «و»ی منطقی (&&) باشد:

bool onFire = isBurning();
if (onFire && fireFighters < 10) {
  if (someOtherCondition()) {
    if (onFire)
      scream();
  }
}

همچنین اگر هر دو دستور بیرونی و درونی به صورت عبارات منطقی باشند خطا تشخیص داده می‌شود (دستور بیرونی یک «و»ی منطقی (&&) و دستور درونی یک «و»ی منطقی (&&) یا «یا»ی منطقی (||)). دستور if درونی لزومی ندارد فرزند مستقیم دستور بیرونی باشد.

در صورتی که متغیر شرط احتمالاً بین دو بررسی تغییر کرده باشد، هیچ خطایی تشخیص داده نمی‌شود:

bool onFire = isBurning();
if (onFire) {
  tryToExtinguish(onFire);
  if (onFire && peopleInTheBuilding > 0)
    scream();
}

هرگونه تغییر احتمالی مد نظر قرار می‌گیرد، بنابراین اگر متغیر شرط یک متغیر محلی تابع نباشد، volatile باشد یا دارای یک نام مستعار (اشاره‌گر یا ارجاع) باشد، هیچ هشداری صادر نمی‌شود.

محدودیت‌ها

شاخه else در حال حاضر برای متغیر شرط منفی‌شده بررسی نمی‌شود:

bool onFire = isBurning();
if (onFire) {
  scream();
} else {
  if (!onFire) {
    continueWork();
  }
}

بررسی‌کننده در حال حاضر تنها بررسی زائد متغیرهای شرطی منفرد را تشخیص می‌دهد. عبارت‌های پیچیده‌تر بررسی نمی‌شوند:

if (peopleInTheBuilding == 1) {
  if (peopleInTheBuilding == 1) {
    doSomething();
  }
}

bugprone-reserved-identifier

نام‌های cert-dcl37-c و cert-dcl51-cpp به عنوان نام مستعار به این بررسی هدایت می‌شوند.

استفاده از شناسه‌های رزروشده برای استفاده توسط پیاده‌سازی (implementation) را بررسی می‌کند.

استانداردهای C و C++ هر دو نام‌های زیر را برای چنین استفاده‌ای رزرو کرده‌اند:

استاندارد C علاوه‌بر این، نام‌هایی که با دو خط زیر متوالی آغاز می‌شوند را رزرو می‌کند، در حالی که استاندارد C++ این محدودیت را تشدید کرده و نام‌هایی که در هر کجای آن‌ها دو خط زیر متوالی وجود داشته باشد را رزرو می‌کند.

نقض قواعد نام‌گذاری بالا به رفتار تعریف‌نشده (undefined behavior) منجر می‌شود.

namespace NS {
  void __f(); // name is not allowed in user code
  using _Int = int; // same with this
  #define cool__macro // also this
}
int _g(); // disallowed in global namespace only

این بررسی همچنین می‌تواند معکوس شود، یعنی طوری پیکربندی شود که هر شناسه که یک شناسه رزروشده نیست را علامت‌گذاری کند. این حالت برای مثال توسط توسعه‌دهندگان کتابخانه استاندارد استفاده می‌شود تا اطمینان حاصل کنند به فضای‌نام کاربر تعدی نکنند.

این بررسی (هنوز) سایر نام‌های رزروشده، مانند نام‌های ماکرو که با کلمات کلیدی زبان یکسان هستند، و نام‌هایی که به‌طور خاص توسط استانداردهای زبان رزرو شده‌اند، مانند 'zombie names' در C++ و جهت‌گیری‌های آینده کتابخانه C را بررسی نمی‌کند.

این بررسی مطابق با قانون DCL37-C از استاندارد کدنویسی CERT C تحت عنوان Do not declare or define a reserved identifier https://wiki.sei.cmu.edu/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier و همچنین معادل C++ آن، یعنی DCL51-CPP تحت عنوان Do not declare or define a reserved identifier https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier است.

گزینه‌ها

bugprone-return-const-ref-from-parameter

دستورهای return را که یک پارامتر ارجاع ثابت (constant reference) را به عنوان ارجاع ثابت بازمی‌گردانند، شناسایی می‌کند. این امر در صورتی که فراخواننده از xvalueها به عنوان آرگومان استفاده کند، ممکن است موجب خطاهای استفاده پس از آزادسازی (use-after-free) شود.

در C++، پارامترهای ارجاع ثابت می‌توانند xvalueها را بپذیرند که پس از فراخوانی تخریب خواهند شد. هنگامی که تابع چنین پارامتری را نیز به عنوان ارجاع ثابت بازمی‌گرداند، ارجاع بازگردانده‌شده ممکن است پس از نابود شدن شیئی که به آن اشاره دارد، مورد استفاده قرار گیرد.

مثال

struct S {
  int v;
  S(int);
  ~S();
};
const S &fn(const S &a) {
  return a;
}
const S& s = fn(S{1});
s.v; // use after free

این مشکل را می‌توان با اعلان یک سربارگذاری (overload) از تابع مشکل‌ساز برطرف کرد که در آن پارامتر const & به صورت && اعلان شده باشد. توسعه‌دهنده باید اطمینان حاصل کند که پیاده‌سازی آن تابع باعث ایجاد use-after-free نمی‌شود؛ همان خطایی که این بررسی نسبت به آن هشدار می‌دهد. همچنین نشانه‌گذاری چنین سربارگذاری && به صورت deleted نیز هشدار را برطرف می‌کند. در صورتی که بسته به جریان کنترل تابع، پارامترهای مختلف const & بازگردانده شوند، یک سربارگذاری که در آن تمام پارامترهای مشکل‌ساز const & به صورت && اعلان شده باشند، مشکل را حل خواهد کرد.

این مشکل همچنین می‌تواند با افزودن ویژگی [[clang::lifetimebound]] حل شود. Clang به صورت پیش‌فرض هشدار -Wdangling را فعال می‌کند که می‌تواند سوءاستفاده از تابع حاشیه‌نویسی‌شده را شناسایی کند. برای جزئیات به ویژگی lifetimebound در https://clang.llvm.org/docs/AttributeReference.html#lifetimebound مراجعه کنید.

const int &f(const int &a [[clang::lifetimebound]]) { return a; } // no warning
const int &v = f(1); // warning: temporary bound to local reference 'v' will be destroyed at the end of the full-expression [-Wdangling]

bugprone-shared-ptr-array-mismatch

مقداردهی‌های اولیه اشاره‌گرهای هوشمند اشتراکی C++ (از نوع shared pointer) از نوع غیرآرایه‌ای را که با یک آرایه مقداردهی اولیه شده‌اند، پیدا می‌کند.

اگر یک اشاره‌گر اشتراکی std::shared_ptr<T> با عبارت جدید new T[] مقداردهی شود، حافظه به طور صحیح آزادسازی نمی‌شود. در این حالت اشاره‌گر برای آزادسازی حافظه هدف از delete معمولی استفاده می‌کند، در حالی که به فراخوانی delete[] نیاز است. عبارت std::shared_ptr<T[]> عملگر delete صحیح را فراخوانی می‌کند.

این بررسی در صورتی که در یک اعلان متغیر تکی استفاده شده باشد (یک متغیر در یک دستور)، پیشنهاد جایگزینی shared_ptr<T> با shared_ptr<T[]> را ارائه می‌دهد.

مثال:

std::shared_ptr<Foo> x(new Foo[10]); // -> std::shared_ptr<Foo[]> x(new Foo[10]);
//                     ^ warning: shared pointer to non-array is initialized with array [bugprone-shared-ptr-array-mismatch]
std::shared_ptr<Foo> x1(new Foo), x2(new Foo[10]); // no replacement
//                                   ^ warning: shared pointer to non-array is initialized with array [bugprone-shared-ptr-array-mismatch]
std::shared_ptr<Foo> x3(new Foo[10], [](const Foo *ptr) { delete[] ptr; }); // no warning
struct S {
  std::shared_ptr<Foo> x(new Foo[10]); // no replacement in this case
  //                     ^ warning: shared pointer to non-array is initialized with array [bugprone-shared-ptr-array-mismatch]
};

این بررسی به طور جزئی قانون MEM51-CPP از استاندارد کدنویسی CERT C++ تحت عنوان Properly deallocate dynamically allocated resources https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM51-CPP.+Properly+deallocate+dynamically+allocated+resources را پوشش می‌دهد. با این حال، فقط حالت std::shared_ptr توسط این بررسی شناسایی می‌شود.

bugprone-signal-handler

ساختارهای خاصی را در توابع مدیر سیگنال (signal handler) که می‌توانند باعث رفتار تعریف‌نشده شوند، پیدا می‌کند. قوانین مربوط به آنچه مجاز است بین نسخه‌های مختلف زبان C++ تفاوت دارد.

قوانین بررسی‌شده مدیر سیگنال برای C:

قوانین بررسی‌شده مدیر سیگنال تا و شامل C++14:

این بررسی در C++17 و نسخه‌های بعدی غیرفعال است.

ایمن بودن از نظر ناهمگام (Asynchronous-safety) از طریق مقایسه نام تابع با مجموعه‌ای از توابع شناخته‌شده تعیین می‌شود. علاوه بر این، تابع باید از فایل سرآیند سیستم (system header) گنجانده شده و در فضای‌نام سراسری باشد. آرگومان‌های (احتمالی) ارسال‌شده به تابع بررسی نمی‌شوند. هر تابعی که نتوان ایمن بودن ناهمگام آن را مشخص کرد، توسط این بررسی ناامن فرض می‌شود، از جمله توابع کاربر که فقط اعلان آن‌ها قابل مشاهده است. فراخوانی توابع تعریف‌شده توسط کاربر با تعاریف قابل مشاهده، به صورت بازگشتی بررسی می‌شوند.

این بررسی قانون SIG30-C از استاندارد کدنویسی CERT C تحت عنوان Call only asynchronous-safe functions within signal handlers https://www.securecoding.cert.org/confluence/display/c/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers و همچنین قانون MSC54-CPP تحت عنوان A signal handler must be a plain old function https://wiki.sei.cmu.edu/confluence/display/cplusplus/MSC54-CPP.+A+signal+handler+must+be+a+plain+old+function را پیاده‌سازی می‌کند. این بررسی دارای نام‌های مستعار cert-sig30-c و cert-msc54-cpp است.

گزینه‌ها

bugprone-signed-char-misuse

بررسی cert-str34-c به عنوان یک نام مستعار (alias) برای این بررسی به اینجا هدایت می‌شود. برای نام مستعار CERT، گزینه DiagnoseSignedUnsignedCharComparisons روی false تنظیم شده است.

تبدیل‌های نوع signed char -> integer را که ممکن است نشان‌دهنده خطای برنامه‌نویسی باشند، پیدا می‌کند. مشکل اساسی با نوع داده signed char این است که ممکن است نویسه‌های غیر ASCII را به عنوان مقادیر منفی ذخیره کند. این رفتار می‌تواند چه در هنگام تبدیل صریح (explicit) و چه در هنگام تبدیل ضمنی (implicit)، منجر به برداشت نادرست از کد نوشته‌شده شود.

هنگامی که کد حاوی یک تبدیل صریح signed char -> integer است، برنامه‌نویس احتمالاً انتظار دارد که مقدار تبدیل‌شده با کد نویسه (مقداری در بازه [0..255]) مطابقت داشته باشد، اما مقدار واقعی در بازه [-128..127] خواهد بود. برای جلوگیری از این نوع سوءبرداشت، روش مطلوب تبدیل از signed char به یک مقدار عدد صحیح این است که ابتدا به unsigned char تبدیل شود، که تمام نویسه‌ها را در بازه مثبت [0..255] مطابق با کدهای نویسه شناخته‌شده ذخیره می‌کند.

در صورت تبدیل ضمنی، برنامه‌نویس ممکن است اصلاً متوجه رخ دادن تبدیل و استفاده از مقدار char به عنوان یک عدد صحیح نباشد. مواردی وجود دارد که این ناآگاهی ممکن است منجر به کدی با نقص عملکردی شود. به عنوان مثال، بررسی برابری متغیرهای signed char و unsigned char کاری است که باید در کد C++ از آن اجتناب کرد. در حین این مقایسه، هر دو متغیر به اعداد صحیحی تبدیل می‌شوند که دامنه‌های مقادیر متفاوتی دارند. برای signed char، نویسه‌های غیر ASCII به عنوان مقداری در بازه [-128..-1] ذخیره می‌شوند، در حالی که همان نویسه‌ها برای یک unsigned char در بازه [128..255] ذخیره می‌شوند.

اینکه نوع داده ساده char به صورت پیش‌فرض به عنوان signed char در نظر گرفته شود و در نتیجه توسط این بررسی شناسایی شود یا خیر، به پلتفرم واقعی بستگی دارد. برای تغییر رفتار پیش‌فرض می‌توانید از گزینه‌های کامپایل -funsigned-char و -fsigned-char استفاده کنید.

در حال حاضر، این بررسی در موارد زیر هشدار می‌دهد:

همچنین ببینید: STR34-C. Cast characters to unsigned char before converting to larger integer sizes https://wiki.sei.cmu.edu/confluence/display/c/STR34-C.+Cast+characters+to+unsigned+char+before+converting+to+larger+integer+sizes

یک مثال خوب از توضیحات CERT زمانی است که از متغیر char برای خواندن از فایلی استفاده می‌شود که ممکن است حاوی نویسه‌های غیر ASCII باشد. مشکل زمانی بروز می‌کند که کد از مقدار صحیح -1 به عنوان EOF استفاده می‌کند، در حالی که کد نویسه 255 نیز در نمایش متمم دو (two's complement) از نوع داده char به صورت -1 ذخیره می‌شود. نمونه ساده‌ای از این مورد را در زیر مشاهده کنید. این کد نه تنها با رسیدن به انتهای فایل، بلکه هنگام دریافت نویسه‌ای با کد 255 نیز متوقف می‌شود.

#define EOF (-1)
int read(void) {
  char CChar;
  int IChar = EOF;
  if (readChar(CChar)) {
    IChar = CChar;
  }
  return IChar;
}

یک روش مناسب برای اصلاح کد بالا، تبدیل متغیر char به یک مقدار unsigned char در ابتدا است.

#define EOF (-1)
int read(void) {
  char CChar;
  int IChar = EOF;
  if (readChar(CChar)) {
    IChar = static_cast<unsigned char>(CChar);
  }
  return IChar;
}

مورد استفاده دیگر، بررسی برابری دو متغیر char با علامت‌داری (signedness) متفاوت است. در محدوده مقادیر غیر ASCII، این مقایسه بین یک signed char و یک unsigned char همواره مقدار false را برمی‌گرداند.

bool compare(signed char SChar, unsigned char USChar) {
  if (SChar == USChar)
    return true;
  return false;
}

ساده‌ترین راه برای تصحیح این نوع مقایسه، تبدیل نوع (cast) یکی از آرگومان‌ها است تا هر دو آرگومان نوع یکسانی داشته باشند.

bool compare(signed char SChar, unsigned char USChar) {
  if (static_cast<unsigned char>(SChar) == USChar)
    return true;
  return false;
}

گزینه‌ها

bugprone-sizeof-container

این بررسی کاربردهای sizeof بر روی عبارت‌هایی از نوع کانتینرهای STL را پیدا می‌کند. به احتمال زیاد کاربر قصد داشته به جای آن از .size() استفاده کند.

تمامی انواع class/struct اعلان‌شده در فضای نام std:: که دارای متد const size() هستند، به عنوان کانتینر در نظر گرفته می‌شوند، به استثنای std::bitset و std::array.

مثال‌ها:

std::string s;
int a = 47 + sizeof(s); // warning: sizeof() doesn't return the size of the container. Did you mean .size()?
int b = sizeof(std::string); // no warning, probably intended.
std::string array_of_strings[10];
int c = sizeof(array_of_strings) / sizeof(array_of_strings[0]); // no warning, definitely intended.
std::array<int, 3> std_array;
int d = sizeof(std_array); // no warning, probably intended.

bugprone-sizeof-expression

این بررسی کاربردهایی از عبارت‌های sizeof را پیدا می‌کند که به احتمال زیاد خطا هستند.

عملگر sizeof اندازه (بر حسب بایت) عملوند خود را برمی‌گرداند، که ممکن است یک عبارت یا نام پرانتزگذاری‌شدهٔ یک نوع داده باشد. استفادهٔ نادرست از این عملگر ممکن است منجر به خطاها و آسیب‌پذیری‌های احتمالی نرم‌افزاری شود.

استفادهٔ مشکوک از 'sizeof(K)'

یک اشتباه رایج، پرس‌وجوی sizeof برای یک لیترال عدد صحیح است. این کار معادل استعلام اندازهٔ نوع دادهٔ آن (احتمالاً int) است. هدف برنامه‌نویس احتمالاً صرفاً به‌دست آوردن خود عدد صحیح بوده است، نه اندازهٔ آن.

#define BUFLEN 42
char buf[BUFLEN];
memset(buf, 0, sizeof(BUFLEN));  // sizeof(42) ==> sizeof(int)

استفادهٔ مشکوک از 'sizeof(expr)'

در مواردی که یک enum یا عدد صحیح برای نمایش یک نوع استفاده می‌شود، یک اشتباه رایج اجرای sizeof روی عدد صحیح یا enum نمایانگر آن نوع است که باید توسط sizeof استفاده می‌شد. این امر منجر به دریافت اندازهٔ عدد صحیح می‌شود و نه نوعی که آن عدد صحیح نمایش می‌دهد:

enum data_type {
  FLOAT_TYPE,
  DOUBLE_TYPE
};
struct data {
  data_type type;
  void* buffer;
  data_type get_type() {
    return type;
  }
};
void f(data d, int numElements) {
  // should be sizeof(float) or sizeof(double), depending on d.get_type()
  int numBytes = numElements * sizeof(d.get_type());
  ...
}

استفادهٔ مشکوک از 'sizeof(this)'

کلمهٔ کلیدی this به اشاره‌گری به یک شیء از نوع مشخص ارزیابی می‌شود. عبارت sizeof(this) اندازهٔ یک اشاره‌گر را برمی‌گرداند. برنامه‌نویس به احتمال زیاد اندازهٔ خود شیء را می‌خواسته است و نه اندازهٔ اشاره‌گر را.

class Point {
  [...]
  size_t size() { return sizeof(this); }  // should probably be sizeof(*this)
  [...]
};

استفادهٔ مشکوک از 'sizeof(char*)'

تفاوت ظریفی میان اعلان یک رشتهٔ متنی با char* A = "" و char A[] = "" وجود دارد. حالت اول به جای نوع تجمعی char[]، دارای نوع char* است. استفاده از sizeof روی شیئی که با نوع char* اعلان شده است، به جای تعداد نویسه‌ها (بایت‌های) موجود در لیترال رشته، اندازهٔ یک اشاره‌گر را برمی‌گرداند.

const char* kMessage = "Hello World!";      // const char kMessage[] = "...";
void getMessage(char* buf) {
  memcpy(buf, kMessage, sizeof(kMessage));  // sizeof(char*)
}

استفادهٔ مشکوک از 'sizeof(A*)'

یک اشتباه رایج، محاسبهٔ اندازهٔ یک اشاره‌گر به جای اشاره‌شوندهٔ آن است. این حالت‌ها ممکن است به دلیل تبدیل صریح (explicit cast) یا تبدیل ضمنی (implicit conversion) رخ دهند.

int A[10];
memset(A, 0, sizeof(A + 0));
struct Point point;
memset(point, 0, sizeof(&point));

استفادهٔ مشکوک از 'sizeof(...)/sizeof(...)'

تقسیم عبارت‌های sizeof معمولاً برای بازیابی تعداد عناصر یک نوع تجمعی استفاده می‌شود. این بررسی در موارد ناسازگار یا مشکوک هشدار می‌دهد.

در مثال زیر، موجودیت ۱۰ بایتی است و با نوع int که ۴ بایتی است ناسازگار می‌باشد.

char buf[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };  // sizeof(buf) => 10
void getMessage(char* dst) {
  memcpy(dst, buf, sizeof(buf) / sizeof(int));  // sizeof(int) => 4  [incompatible sizes]
}

در مثال زیر، عبارت sizeof(Values) اندازهٔ char* را برمی‌گرداند. اعلان آن ممکن است به‌راحتی گمراه‌کننده باشد، اما در اعلان پارامتر، اندازهٔ '10' نادیده گرفته شده و تابع یک char* دریافت می‌کند.

char OrderedValues[10] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
return CompareArray(char Values[10]) {
  return memcmp(OrderedValues, Values, sizeof(Values)) == 0;  // sizeof(Values) ==> sizeof(char*) [implicit cast to char*]
}

عبارت مشکوک 'sizeof' در 'sizeof'

ضرب عبارت‌های sizeof معمولاً بی‌معنی است و احتمالاً یک خطای منطقی محسوب می‌شود. در مثال زیر، برنامه‌نویس به جای / از * استفاده کرده است.

const char kMessage[] = "Hello World!";
void getMessage(char* buf) {
  memcpy(buf, kMessage, sizeof(kMessage) * sizeof(char));  //  sizeof(kMessage) / sizeof(char)
}

این بررسی ممکن است روی کدهایی که از ماکروی arraysize استفاده می‌کنند فعال شود. کد زیر به درستی کار می‌کند، اما باید با استفاده صرف از عملگر sizeof ساده‌سازی شود.

extern Object objects[100];
void InitializeObjects() {
  memset(objects, 0, arraysize(objects) * sizeof(Object));  // sizeof(objects)
}

استفاده مشکوک از 'sizeof(sizeof(...))'

گرفتن sizeof از یک sizeof دیگر بی‌معنی است و معمولاً خطایی است که پشت ماکروها پنهان شده است.

#define INT_SZ sizeof(int)
int buf[] = { 42 };
void getInt(int* dst) {
  memcpy(dst, buf, sizeof(INT_SZ));  // sizeof(sizeof(int)) is suspicious.
}

استفاده‌های مشکوک از 'sizeof(...)' در محاسبات اشاره‌گر

عملگرهای محاسباتی روی اشاره‌گرها به طور خودکار نتیجه را بر اساس اندازه نوع داده مورد اشاره مقیاس‌بندی می‌کنند. استفاده بیشتر از sizeof در محاسبات اشاره‌گر معمولاً به نتیجه‌ای ناخواسته منجر می‌شود.

مقیاس‌بندی نتیجه تفاضل اشاره‌گرها

تفریق دو اشاره‌گر منجر به یک عبارت عدد صحیح (از نوع ptrdiff_t) می‌شود که فاصله بین دو شیء مورد اشاره را بر حسب "تعداد اشیاء بین آن‌ها" بیان می‌کند. یک اشتباه رایج این است که تصور شود نتیجه "تعداد بایت‌های بین آن‌ها" است و تفاضل با sizeof مقیاس‌بندی شود؛ مانند P1 - P2 == N * sizeof(T) (به جای P1 - P2 == N) یا (P1 - P2) / sizeof(T) به جای P1 - P2.

void splitFour(const Obj* Objs, size_t N, Obj Delimiter) {
  const Obj *P = Objs;
  while (P < Objs + N) {
    if (*P == Delimiter) {
      break;
    }
  }
  if (P - Objs != 4 * sizeof(Obj)) { // Expecting a distance multiplied by sizeof is suspicious.
    error();
  }
}

void iterateIfEvenLength(int *Begin, int *End) {
  auto N = (Begin - End) / sizeof(int); // Dividing by sizeof() is suspicious.
  if (N % 2)
    return;
  // ...
}

گام برداشتن اشاره‌گر با یک عدد صحیح مقیاس‌بندی‌شده

برعکس، هنگام انجام محاسبات اشاره‌گر برای جمع یا تفریق از یک اشاره‌گر، عملگر محاسباتی به طور ضمنی مقداری را که در واقع به اشاره‌گر اضافه می‌شود با اندازه شیء اشاره‌شده مقیاس‌بندی می‌کند؛ چرا که در Ptr + N انتظار می‌رود N به معنای "تعداد اشیاء برای گام برداشتن" باشد، نه "تعداد بایت‌ها برای گام برداشتن".

دیدن محاسبه یک اشاره‌گر که در آن sizeof وجود دارد مشکوک است و نتیجه آن معمولاً ناخواسته و اغلب خارج از محدوده (out of bounds) است. عبارت Ptr + sizeof(T) اشاره‌گر را به اندازه sizeof(T) عنصر جابه‌جا می‌کند که عملاً فاکتور مقیاس‌بندی را به توان ۲ می‌رساند.

به طور مشابه، ضرب یا تقسیم یک مقدار عددی با sizeof یک عنصر یا کل بافر مشکوک است، زیرا رابطه ابعادی بین مقدار عددی و نتیجه واقعی sizeof همیشه قابل استنتاج نیست. در حالی که افزایش مقیاس یک عدد صحیح (ضرب) با sizeof احتمالاً همیشه یک مشکل است، کاهش مقیاس (تقسیم) در صورتی که توسعه‌دهنده آگاه باشد که تقسیم بین تعداد مناسبی از _بایت‌ها_ و یک مقدار sizeof انجام می‌شود، ذاتاً خطرناک نیست. غیرفعال کردن WarnOnOffsetDividedBySizeOf هشدارها را فقط به حالت ضرب محدود می‌کند.

این بررسی همچنین موارد مشکوک استفاده از alignof و offsetof در محاسبات اشاره‌گر را بررسی می‌کند، زیرا هر دو "اندازه" را بر حسب بایت برمی‌گردانند و نه عنصر، که بالقوه منجر به آفست‌های با مقیاس‌بندی مضاعف می‌شود.

struct Message { /* ... */; char Flags[8]; };
void clearFlags(Message *Array, size_t N) {
  const Message *End = Array + N;
  while (Array < End) {
    memset(Array + offsetof(Message, Flags), // Suspicious pointer arithmetic using offsetof()!
           0, sizeof(Message::Flags));
    ++Array;
  }
}

برای این الگوی نادرست بررسی‌شده، cert-arr39-c به عنوان یک نام مستعار از این بررسی به اینجا هدایت می‌شود.

این بررسی با قاعده استانداردهای کدنویسی CERT C مطابقت دارد: ARR39-C. Do not add or subtract a scaled integer to a pointer http://wiki.sei.cmu.edu/confluence/display/c/ARR39-C.+Do+not+add+or+subtract+a+scaled+integer+to+a+pointer.

محدودیت‌ها

مواردی که نوعِ اشاره‌شونده (pointee) اندازه‌ای برابر با 1 بایت دارد (مانند، و مهم‌تر از همه، char) مستثنی هستند.

گزینه‌ها

bugprone-spuriously-wake-up-functions

فراخوانی‌های توابع cnd_wait، cnd_timedwait، wait، wait_for یا wait_until را زمانی پیدا می‌کند که تابع از داخل حلقه‌ای که برقراری یک گزاره شرطی را بررسی می‌کند فراخوانی نشده باشد، یا تابع فاقد پارامتر شرطی باشد.

if (condition_predicate) {
    condition.wait(lk);
}

if (condition_predicate) {
    if (thrd_success != cnd_wait(&condition, &lock)) {
    }
}

این بررسی مطابق با استاندارد کدنویسی CERT C++ قاعده CON54-CPP. Wrap functions that can spuriously wake up in a loop https://wiki.sei.cmu.edu/confluence/display/cplusplus/CON54-CPP.+Wrap+functions+that+can+spuriously+wake+up+in+a+loop و استاندارد کدنویسی CERT C قاعده CON36-C. Wrap functions that can spuriously wake up in a loop https://wiki.sei.cmu.edu/confluence/display/c/CON36-C.+Wrap+functions+that+can+spuriously+wake+up+in+a+loop است.

bugprone-standalone-empty

زمانی که empty() روی یک بازه (range) استفاده شده و نتیجه آن نادیده گرفته شود، هشدار می‌دهد. در صورت وجود تابع عضو clear()، استفاده از آن را پیشنهاد می‌کند.

متد empty() در بسیاری از بازه‌های رایج، یک مقدار بولی برمی‌گرداند که نشان می‌دهد آیا بازه خالی است یا خیر، اما اغلب به اشتباه به عنوان راهی برای پاک کردن محتویات یک بازه تعبیر می‌شود. برخی از بازه‌ها برای این منظور یک متد clear() ارائه می‌دهند. این بررسی زمانی هشدار می‌دهد که یک فراخوانی empty نتیجه‌ای را برگرداند که نادیده گرفته شده است، و پیشنهاد می‌کند که در صورت در دسترس بودن به عنوان یک تابع عضو در بازه، با فراخوانی clear() جایگزین شود.

به عنوان مثال، کد زیر می‌تواند برای مشخص کردن خالی بودن یا نبودن یک بازه استفاده شود، اما نتیجه آن نادیده گرفته شده است:

std::vector<int> v;
...
v.empty();

یک فراخوانی به clear() به درستی محتویات بازه را پاک می‌کند:

std::vector<int> v;
...
v.clear();

محدودیت‌ها

bugprone-std-namespace-modification

در مورد تغییرات در فضاهای نام std یا posix که می‌تواند منجر به رفتار تعریف‌نشده (undefined behavior) شود، هشدار می‌دهد.

فضای نام std (یا posix) مجاز است با تخصیص‌های الگو (کلاس یا تابع) که وابسته به یک نوع تعریف‌شده توسط کاربر هستند (نوعی که در هدرهای استاندارد سیستم تعریف نشده است) گسترش یابد.

این بررسی اعلانات زیر (ارائه‌شده توسط کاربر) را در فضای نام std یا posix شناسایی می‌کند:

مثال‌ها:

namespace std {
  int x; // warning: modification of 'std' namespace can result in undefined behavior [bugprone-dont-modify-std-namespace]
}
namespace posix::a { // warning: modification of 'posix' namespace can result in undefined behavior
}
template <>
struct ::std::hash<long> { // warning: modification of 'std' namespace can result in undefined behavior
  unsigned long operator()(const long &K) const {
    return K;
  }
};
struct MyData { long data; };
template <>
struct ::std::hash<MyData> { // no warning: specialization with user-defined type
  unsigned long operator()(const MyData &K) const {
    return K.data;
  }
};
namespace std {
  template <>
  void swap<bool>(bool &a, bool &b); // warning: modification of 'std' namespace can result in undefined behavior
  template <>
  bool less<void>::operator()<MyData &&, MyData &&>(MyData &&, MyData &&) const { // warning: modification of 'std' namespace can result in undefined behavior
    return true;
  }
}

مراجع

این بررسی مطابق با استاندارد کدنویسی CERT C++ تحت قانون DCL58-CPP. Do not modify the standard namespaces است https://www.securecoding.cert.org/confluence/display/cplusplus/DCL58-CPP.+Do+not+modify+the+standard+namespaces.

bugprone-string-constructor

سازنده‌های (constructors) رشته‌ای مشکوک و احتمالا نادرست را پیدا می‌کند.

یک اشتباه رایج، جابجا کردن پارامترهای سازنده رشته پرکننده ('fill') است.

مثال‌ها:

std::string str('x', 50); // should be str(50, 'x')

فراخوانی سازنده رشته لیترال با طولی بزرگتر از خود لیترال مشکوک بوده و نویسه‌های تصادفی اضافه‌ای را به رشته می‌افزاید.

مثال‌ها:

std::string("test", 200);   // Will include random characters after "test".
std::string("test", 2, 5);  // Will include random characters after "st".
std::string_view("test", 200);

ایجاد یک رشته خالی از طریق سازنده‌های دارای پارامتر، مشکوک در نظر گرفته می‌شود. برنامه‌نویس باید در عوض از سازنده خالی استفاده کند.

مثال‌ها:

std::string("test", 0);   // Creation of an empty string.
std::string("test", 1, 0);
std::string_view("test", 0);

ارسال یک پارامتر موقعیت نویسه اولِ نامعتبر به سازنده موجب پرتاب استثنای std::out_of_range در زمان اجرا خواهد شد.

مثال‌ها:

std::string("test", -1, 10); // Negative first character position.
std::string("test", 10, 10); // First character position is bigger than string literal character range".

گزینه‌ها

bugprone-string-integer-assignment

این بررسی، انتساب یک عدد صحیح به std::basic_string<CharT> (std::string، std::wstring و غیره) را شناسایی می‌کند. منشا مشکل عملگر انتساب زیر در std::basic_string<CharT> است:

basic_string& operator=( CharT ch );

انواع داده‌های عددی می‌توانند به صورت ضمنی به انواع کاراکتری تبدیل (cast) شوند.

std::string s;
int x = 5965;
s = 6;
s = x;

از توابع تبدیل مناسب یا کاراکترهای لیترال استفاده کنید.

std::string s;
int x = 5965;
s = '6';
s = std::to_string(x);

جهت فرونشاندن مثبت‌های کاذب (false positives)، از تبدیل صریح (explicit cast) استفاده کنید.

std::string s;
s = static_cast<char>(6);

bugprone-string-literal-with-embedded-nul

موارد وقوع رشته لیترال دارای نویسه NUL توکار را پیدا کرده و نحوه استفاده از آن‌ها را اعتبارسنجی می‌کند.

گریزدهی نامعتبر

نویسه‌های خاص را می‌توان در یک رشته لیترال با استفاده از کدگذاری شانزده‌شانزدهی (hexadecimal) آن‌ها مانند \x42 گریز داد (escape کرد). یک اشتباه رایج، گریزدهی آن‌ها به شکل \0x42 است که در آن \0 به معنای نویسه NUL خواهد بود.

const char* Example[] = "Invalid character: \0x12 should be \x12";
const char* Bytes[] = "\x03\0x02\0x01\0x00\0xFF\0xFF\0xFF";

Truncated literal

کلاس‌های شبه‌رشته (string-like) می‌توانند رشته‌های حاوی NUL داخلی را دستکاری کنند، زیرا آن‌ها بایت‌ها و طول رشته را ردیابی و نگهداری می‌کنند. اما این موضوع در مورد رشته‌های char* (خاتمه‌یافته با NUL) صدق نمی‌کند.

یک اشتباه رایج، ارسال یک لیترال رشته‌ای با NUL داخلی به سازنده‌ای از رشته است که انتظار یک رشته خاتمه‌یافته با NUL را دارد. بایت‌های پس از اولین نویسه NUL کوتاه (ترانکیت) می‌شوند.

std::string str("abc\0def");  // "def" is truncated
str += "\0";                  // This statement is doing nothing
if (str == "\0abc") return;   // This expression is always true

bugprone-stringview-nullptr

روش‌های مختلفی را که ممکن است در آن‌ها یک آرگومان null به سازنده const CharT* از std::basic_string_view ارسال شود، بررسی کرده و در بیشتر موارد آن‌ها را با سازنده پیش‌فرض جایگزین می‌کند. برای عملگرهای مقایسه‌ای، لیست مقداردهی اولیه محصور در آکولاد (braced initializer list) کامپایل نمی‌شود، بنابراین در صورت لزوم به جای آن از یک فراخوانی به .empty() یا لیترال رشته خالی استفاده می‌شود.

این بررسی مانع از اجرای کدی می‌شود که رفتار تعریف‌نشده (undefined behavior) قطعی دارد. سازنده تک‌آرگومانی const CharT* قبل از دی‌ریفرنس کردن ورودی خود، حالت null بودن را بررسی نمی‌کند. استاندارد در نظر دارد یک سربارگذاری (overload) صریحاً حذف‌شده اضافه کند تا برخی از این موارد را مدیریت کند: wg21.link/p2166

برای پوشش موارد اضافی NULL (که به __null گسترش می‌یابد) و 0، ابتدا بررسی modernize-use-nullptr را اجرا کنید تا فراخواننده‌ها به nullptr تبدیل شوند.

std::string_view sv = nullptr;
sv = nullptr;
bool is_empty = sv == nullptr;
bool isnt_empty = sv != nullptr;
accepts_sv(nullptr);
accepts_sv({{}});  // A
accepts_sv({nullptr, 0});  // B

تبدیل می‌شود به...

std::string_view sv = {};
sv = {};
bool is_empty = sv.empty();
bool isnt_empty = !sv.empty();
accepts_sv("");
accepts_sv("");  // A
accepts_sv({nullptr, 0});  // B

نکته:

نکته:

bugprone-suspicious-enum-usage

این بررسی‌کننده موارد مختلفی را که یک enum احتمالاً به اشتباه (به عنوان بیت‌ماسک) استفاده شده است، تشخیص می‌دهد.

موارد زیر تنها با استفاده از StrictMode <#cmdoption-arg-StrictMode> مورد بررسی قرار می‌گیرند. ما enum را به عنوان یک بیت‌ماسک (مشکوک) در نظر می‌گیریم اگر سه شرط زیر به طور همزمان برقرار باشند:

بنابراین هر زمان که عنصری که توان ۲ نیست به عنوان یک عنصر بیت‌ماسک استفاده شود، استفاده نادرست را تشخیص داده و یک هشدار صادر می‌کنیم.

مثال‌ها:

enum { A, B, C };
enum { D, E, F = 5 };
enum { G = 10, H = 11, I = 12 };
unsigned flag;
flag =
    A |
    H; // OK, disjoint value intervals in the enum types ->probably good use.
flag = B | F; // Warning, have common values so they are probably misused.
// Case 2:
enum Bitmask {
  A = 0,
  B = 1,
  C = 2,
  D = 4,
  E = 8,
  F = 16,
  G = 31 // OK, real bitmask.
};
enum Almostbitmask {
  AA = 0,
  BB = 1,
  CC = 2,
  DD = 4,
  EE = 8,
  FF = 16,
  GG // Problem, forgot to initialize.
};
unsigned flag = 0;
flag |= E; // OK.
flag |=
    EE; // Warning at the decl, and note that it was used here as a bitmask.

گزینه‌ها

bugprone-suspicious-include

این بررسی مواردی را شناسایی می‌کند که در آن‌ها یک include به فایلی ارجاع می‌دهد که به نظر یک فایل پیاده‌سازی (implementation file) می‌آید؛ امری که اغلب منجر به نقض‌های ODR می‌شود که ردگیری آن‌ها دشوار است.

مثال‌ها:

#include "Dinosaur.hpp"     // OK, .hpp files tend not to have definitions.
#include "Pterodactyl.h"    // OK, .h files tend not to have definitions.
#include "Velociraptor.cpp" // Warning, filename is suspicious.
#include_next <stdio.c>     // Warning, filename is suspicious.

گزینه‌ها

bugprone-suspicious-memory-comparison

فراخوانی‌های بالقوه نادرست به memcmp() را بر اساس ویژگی‌های آرگومان‌ها پیدا می‌کند. موارد زیر پوشش داده شده‌اند:

مورد ۱: نوع با چیدمان غیر استاندارد (Non-standard-layout type)

مقایسه نمایش شیء (object representation) اشیایی که چیدمان غیراستاندارد دارند، ممکن است نمایش مقدار (value representation) را به‌درستی مقایسه نکند.

مورد ۲: انواع بدون نمایش شیء یکتا

اشیایی با مقدار یکسان ممکن است نمایش شیء یکسانی نداشته باشند. این حالت می‌تواند ناشی از فاصله‌گذاری (padding) یا انواع ممیز شناور (floating-point) باشد.

همچنین ببینید: EXP42-C. Do not compare padding data https://wiki.sei.cmu.edu/confluence/display/c/EXP42-C.+Do+not+compare+padding+data و FLP37-C. Do not use object representations to compare floating-point values https://wiki.sei.cmu.edu/confluence/display/c/FLP37-C.+Do+not+use+object+representations+to+compare+floating-point+values

این بررسی همچنین با قوانین استاندارد کدنویسی CERT C++ زیر مرتبط بوده و تا حدی هم‌پوشانی دارد: OOP57-CPP. Prefer special member functions and overloaded operators to C Standard Library functions https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP57-CPP.+Prefer+special+member+functions+and+overloaded+operators+to+C+Standard+Library+functions و EXP62-CPP. Do not access the bits of an object representation that are not part of the object's value representation https://wiki.sei.cmu.edu/confluence/display/cplusplus/EXP62-CPP.+Do+not+access+the+bits+of+an+object+representation+that+are+not+part+of+the+object%27s+value+representation

بررسی cert-exp42-c به عنوان یک نام مستعار برای این بررسی، به اینجا تغییر مسیر می‌دهد.

bugprone-suspicious-memset-usage

این بررسی فراخوانی‌های memset() را که دارای خطاهای بالقوه در آرگومان‌هایشان هستند پیدا می‌کند. با در نظر گرفتن تابع به صورت void* memset(void* destination, int fill_value, size_t byte_count)، موارد زیر پوشش داده می‌شوند:

مورد ۱: مقدار پرکننده یک کاراکتر ``'0'`` است

پر کردن یک ناحیه از حافظه با کاراکترهای کد اسکی ۴۸ مرسوم نیست، احتمالاً منظور اعداد صحیح صفر بوده است. این بررسی پیشنهاد جایگزینی '0' با 0 را ارائه می‌دهد. اجرای memset بر روی اشاره‌گرهای کاراکتری با '0' مجاز است.

مورد ۲: مقدار پرکننده دچار برش (truncated) می‌شود

تابع memset مقدار fill_value را قبل از استفاده به unsigned char تبدیل می‌کند. اگر fill_value خارج از محدوده unsigned character باشد، دچار برش شده و حافظه حاوی الگوی مورد نظر نخواهد بود.

مورد ۳: تعداد بایت‌ها صفر است

فراخوانی memset با مقدار لیترال صفر در آرگومان byte_count آن احتمالاً ناخواسته بوده و با fill_value جابه‌جا شده است. این بررسی پیشنهاد تعویض این دو آرگومان را ارائه می‌دهد.

نام بررسی متناظر در cpplint.py عبارت است از: runtime/memset.

مثال‌ها:

void foo() {
  int i[5] = {1, 2, 3, 4, 5};
  int *ip = i;
  char c = '1';
  char *cp = &c;
  int v = 0;
  // Case 1
  memset(ip, '0', 1); // suspicious
  memset(cp, '0', 1); // OK
  // Case 2
  memset(ip, 0xabcd, 1); // fill value gets truncated
  memset(ip, 0x00, 1);   // OK
  // Case 3
  memset(ip, sizeof(int), v); // zero length, potentially swapped
  memset(ip, 0, 1);           // OK
}

bugprone-suspicious-missing-comma

لیترال‌های رشته‌ای که در کنار یکدیگر قرار می‌گیرند، در فاز ۶ ترجمه (پس از پیش‌پردازنده) الحاق (concatenate) می‌شوند. از این ویژگی برای نمایش لیترال رشته‌ای طولانی در چند خط استفاده می‌شود.

برای نمونه، اعلان‌های زیر معادل هستند:

const char* A[] = "This is a test";
const char* B[] = "This" " is a "    "test";

یک اشتباه رایج برنامه‌نویسان فراموش کردن کاما بین دو لیترال رشته‌ای در یک لیست مقداردهی اولیه آرایه (array initializer list) است.

const char* Test[] = {
  "line 1",
  "line 2"     // Missing comma!
  "line 3",
  "line 4",
  "line 5"
};

این آرایه شامل رشته "line 2line3" در آفست ۱ (یعنی Test[1]) خواهد بود. ابزار Clang در زمان کامپایل هیچ هشداری تولید نخواهد کرد.

این بررسی ممکن است در مواردی مانند زیر به نادرستی هشدار دهد:

const char* SupportedFormat[] = {
  "Error %s",
  "Code " PRIu64,   // May warn here.
  "Warning %s",
};

گزینه‌ها

bugprone-suspicious-realloc-usage

این بررسی مواردی از استفاده از realloc را می‌یابد که در آن‌ها مقدار بازگشتی به همان عبارتی انتساب داده می‌شود که به عنوان آرگومان اول ارسال شده است: p = realloc(p, size); مشکل این ساختار آن است که اگر realloc شکست بخورد، یک اشاره‌گر تهی (null) برمی‌گرداند اما حافظه اصلی را آزاد نمی‌کند. اگر متغیر دیگری به آن اشاره نکند، بلوک حافظه اصلی دیگر برای استفاده یا آزاد‌سازی در دسترس برنامه نخواهد بود. در هر صورت، p = realloc(p, size); نشان‌دهنده سبک کدنویسی بد است و می‌تواند با q = realloc(p, size); جایگزین شود.

عبارت اشاره‌گر (استفاده‌شده در realloc) می‌تواند یک متغیر یا یک عضو فیلد از یک ساختار داده باشد، اما نمی‌تواند شامل فراخوانی‌های تابع یا انواع حل‌نشده (unresolved types) باشد.

در موارد واضحی که اشاره‌گر استفاده‌شده در realloc قبل از فراخوانی realloc به متغیر دیگری انتساب داده شده باشد، هیچ هشداری صادر نمی‌شود. این حالت تنها زمانی رخ می‌دهد که یک عبارت ساده به شکل q = p یا void *q = p در همان تابعی یافت شود که p = realloc(p, ...) در آن پیدا شده است. این انتساب باید قبل از فراخوانی realloc (اما در غیر این صورت در هر نقطه‌ای) در همان تابع باشد. این نادیده‌گیری تنها در صورتی کار می‌کند که p یک متغیر تکی باشد.

مثال‌ها:

struct A {
  void *p;
};
A &getA();
void foo(void *p, A *a, int new_size) {
  p = realloc(p, new_size); // warning: 'p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer
  a->p = realloc(a->p, new_size); // warning: 'a->p' may be set to null if 'realloc' fails, which may result in a leak of the original buffer
  getA().p = realloc(getA().p, new_size); // no warning
}
void foo1(void *p, int new_size) {
  void *p1 = p;
  p = realloc(p, new_size); // no warning
}

bugprone-suspicious-semicolon

بیشتر موارد وجود نقطه‌ویرگول‌های سرگردان را که به طور غیرمنتظره‌ای معنای کد را تغییر می‌دهند، پیدا می‌کند. به‌طور دقیق‌تر، به دنبال دستورهای if، while، for و for-range می‌گردد که بدنه آن‌ها یک نقطه‌ویرگول تکی است، و سپس زمینه کد (مانند تورفتگی) را تحلیل می‌کند تا مشخص کند آیا این مورد عمدی بوده است یا خیر.

if (x < y);
{
  x++;
}

در اینجا بدنه دستور if تنها از یک نقطه‌ویرگول در انتهای خط اول تشکیل شده است، و x صرف‌نظر از شرط افزایش خواهد یافت.

while ((line = readLine(file)) != NULL);
  processLine(line);

در نتیجه این کد، processLine() تنها یک بار فراخوانی خواهد شد، یعنی زمانی که حلقه while با بدنه خالی با وضعیت line == NULL خاتمه یابد. تورفتگی کد قصد برنامه‌نویس را نشان می‌دهد.

if (x >= y);
x -= y;

با اینکه تورفتگی هیچ تودرتویی را نشان نمی‌دهد، اما وجود یک دستور if با بدنه خالی اساساً دلیل موجهی ندارد (هرچند ممکن است برای یک حلقه معنی‌دار باشد). بنابراین این بررسی برای کد بالا هشدار صادر می‌کند.

برای حل مشکل، نقطه‌ویرگول سرگردان را حذف کنید یا در صورتی که بدنه خالی عمدی است، این مورد را با استفاده از تورفتگی کد نشان دهید یا نقطه‌ویرگول را در یک خط جدید قرار دهید. برای مثال:

while (readWhitespace());
  Token t = readNextToken();

در اینجا خط دوم به‌گونه‌ای تورفتگی دارد که نشان می‌دهد قرار است بدنه حلقه while باشد - که در واقع بدنه آن به دلیل وجود نقطه‌ویرگول در انتهای خط اول خالی است.

یا تورفتگی را از خط دوم حذف کنید:

while (readWhitespace());
Token t = readNextToken();

... یا نقطه‌ویرگول را از انتهای خط اول به یک خط جدید منتقل کنید:

while (readWhitespace())
  ;
  Token t = readNextToken();

در این حالت، بررسی فرض خواهد کرد که شما می‌دانید در حال انجام چه کاری هستید و هشداری صادر نخواهد کرد.

bugprone-suspicious-string-compare

استفاده‌های مشکوک از توابع مقایسه رشته در زمان اجرا را می‌یابد. این بررسی در C و C++ معتبر است.

فراخوانی‌ها با عملگر مقایسه ضمنی را بررسی کرده و پیشنهاد می‌دهد که آن را صراحتاً اضافه کنید.

if (strcmp(...))       // مقایسه ضمنی با صفر
if (!strcmp(...))      // هشداری داده نخواهد شد
if (strcmp(...) != 0)  // هشداری داده نخواهد شد

بررسی می‌کند که نتایج تابع مقایسه (مانند strcmp) با یک مقدار ثابت معتبر مقایسه شوند. مقدار حاصل عبارت است از:

<  0    زمانی که کوچکتر باشد،
>  0    زمانی که بزرگتر باشد،
== 0    زمانی که برابر باشد.

یک اشتباه رایج، مقایسه نتیجه با 1 یا -1 است.

if (strcmp(...) == -1)  // استفاده نادرست از مقدار بازگردانده‌شده.

علاوه بر این، در صورتی که مقدار نتیجه به‌طور ضمنی به یک نوع غیرصحیح مشکوک تبدیل (cast) شود، این بررسی هشدار می‌دهد. این حالت زمانی رخ می‌دهد که مقدار بازگردانده‌شده در یک بافت (context) نادرست استفاده شود.

if (strcmp(...) < 0.)  // استفاده نادرست از مقدار بازگردانده‌شده.

گزینه‌ها

bugprone-suspicious-stringview-data-usage

استفاده‌های مشکوک از std::string_view::data() را که ممکن است به دلیل خاتمه‌نیافتن مناسب یا صحیح رشته با null منجر به خواندن داده خارج از محدوده شود، شناسایی می‌کند.

زمانی هشدار می‌دهد که نتیجه data() به یک سازنده یا تابع ارسال شود بدون اینکه نتیجه متناظر توابع عضو size() یا length() نیز ارسال شده باشد. چنین استفاده‌ای می‌تواند منجر به رفتارهای ناخواسته شود، به‌ویژه هنگامی که فرض بر این باشد که داده اشاره‌شده توسط data() به null ختم شده است.

عدم وجود متد c_str() در std::string_view اغلب توسعه‌دهندگان را به استفاده از data() به عنوان جایگزین سوق می‌دهد، به‌ویژه هنگام تعامل با APIهای زبان C که انتظار رشته‌های خاتمه‌یافته با null را دارند. با این حال، از آنجا که data() خاتمه با null را تضمین نمی‌کند، در صورتی که API برای تفسیر صحیح رشته به خاتمه مناسب با null متکی باشد، این امر می‌تواند به رفتار ناخواسته منجر شود.

در برنامه‌نویسی امروزی، این سناریو می‌تواند هنگام تبدیل ضمنی یک std::string_view به std::string رخ دهد. از آنجا که سازنده طراحی‌شده در std::string برای اشیاء شبیه string-view از نوع explicit است، تلاش برای ارسال یک std::string_view به تابعی که انتظار std::string را دارد منجر به خطای کامپایل خواهد شد. به عنوان یک راهکار موقت، ممکن است توسعه‌دهندگان وسوسه شوند تا از متد .data() برای رفع خطای کامپایل استفاده کنند که خطرات بالقوه‌ای به همراه دارد.

برای نمونه:

void printString(const std::string& str) {
  std::cout << "String: " << str << std::endl;
}
void something(std::string_view sv) {
  printString(sv.data());
}

در این مثال، ارسال مستقیم sv به تابع printString به دلیل صریح (explicit) بودن سازنده std::string منجر به خطای کامپایل می‌شود. در نتیجه، ممکن است توسعه‌دهندگان sv.data() را برای حل خطای کامپایل برگزینند، هرچند که خطرات بالقوه ذکرشده را به همراه دارد.

گزینه‌ها

bugprone-swapped-arguments

آرگومان‌هایی که احتمالاً جابه‌جا شده‌اند را با بررسی تبدیل‌های ضمنی پیدا می‌کند. این بررسی انواع آرگومان‌های ارسالی به یک تابع را تحلیل کرده و آن‌ها را با انواع مورد انتظار پارامترهای متناظر مقایسه می‌کند. در صورت عدم تطابق یا وجود تبدیل ضمنی که نشان‌دهنده جابه‌جایی احتمالی باشد، هشدار داده می‌شود.

void printNumbers(int a, float b);
int main() {
  // آرگومان‌های جابه‌جاشده: float به عنوان int ارسال شده، int به عنوان float
  printNumbers(10.0f, 5);
  return 0;
}

طیف گسترده‌ای از تبدیل‌های ضمنی را پوشش می‌دهد، از جمله: - تبدیل‌های تعریف‌شده توسط کاربر (user-defined) - تبدیل‌ها از انواع ممیز شناور به انواع بولی یا صحیح - تبدیل‌ها از انواع صحیح به انواع بولی یا ممیز شناور - تبدیل‌ها از بولی به انواع صحیح یا انواع ممیز شناور - تبدیل‌ها از اشاره‌گرها (و اشاره‌گرهای عضو) به بولی

مهم است توجه داشته باشید که برای بیشتر جابه‌جایی‌های آرگومان، انواع باید دقیقاً یکسان باشند. با این حال، استثناهایی برای این قاعده وجود دارد. به‌ویژه، هنگامی که آرگومان جابه‌جاشده از نوع صحیح باشد، تطابق دقیق همیشه الزامی نیست. تبدیل‌های صریح ضمنی (implicit casts) از سایر انواع صحیح نیز پذیرفته می‌شوند. به طور مشابه، هنگام کار با آرگومان‌های ممیز شناور، تبدیل‌های ضمنی میان انواع مختلف ممیز شناور قابل قبول در نظر گرفته می‌شوند.

برای جلوگیری از سردرگمی، جابه‌جایی‌هایی که در آن‌ها هر دو آرگومان جابه‌جاشده از نوع صحیح، یا هر دو از نوع ممیز شناور باشند، هشدار را فعال نمی‌کنند. در چنین مواردی، فرض بر این است که توسعه‌دهنده عمداً از انواع صحیح یا ممیز شناور مختلف استفاده کرده است و هشداری صادر نمی‌شود. این رویکرد مانع هشدارهای نادرست (false positives) شده و انعطاف‌پذیری لازم را در مدیریت شرایطی که انواع گوناگون صحیح یا ممیز شناور به‌صورت هدفمند استفاده شده‌اند، فراهم می‌کند.

bugprone-switch-missing-default-case

اطمینان حاصل می‌کند که دستورهای switch فاقد حالت default نشانه‌گذاری شوند؛ این بررسی تنها بر پوشش حالت‌های غیر enum تمرکز دارد، جایی که کامپایلر ممکن است هشداری صادر نکند.

دستورهای switch بدون حالت default می‌توانند منجر به رفتارهای غیرمنتظره و مدیریت ناقص تمام حالت‌های ممکن شوند. هنگامی که یک دستور switch فاقد حالت default باشد، در صورت مواجهه با مقداری که با هیچ‌یک از حالت‌های مشخص‌شده مطابقت ندارد، دستور switch هیچ کاری انجام نخواهد داد و برنامه بدون مدیریت آن مقدار، به اجرای خود ادامه می‌دهد.

این بررسی به شناسایی دستورهای switch فاقد حالت default کمک می‌کند و به توسعه‌دهندگان اجازه می‌دهد تا از مدیریت صحیح تمام حالت‌های ممکن مطمئن شوند. افزودن حالت default امکان مدیریت مناسب مقادیر غیرمنتظره یا تطابق‌نیافته را فراهم ساخته و خطر خطاهای برنامه و رفتارهای پیش‌بینی‌نشده را کاهش می‌دهد.

مثال:

// Example 1:
// warning: switching on non-enum value without default case may not cover all cases
switch (i) {
case 0:
  break;
}
// Example 2:
enum E { eE1 };
E e = eE1;
switch (e) { // no-warning
case eE1:
  break;
}
// Example 3:
int i = 0;
switch (i) { // no-warning
case 0:
  break;
default:
  break;
}

نکته:

همچنین ببینید:

bugprone-tagged-union-member-count

هشدارهایی برای tagged unionها صادر می‌کند، در شرایطی که تعداد برچسب‌ها (tags) با تعداد اعضای داده‌ای درون union متفاوت باشد.

یک struct یا یک class در صورتی یک tagged union در نظر گرفته می‌شود که دقیقاً دارای یک عضو داده‌ای union و دقیقاً یک عضو داده‌ای enum باشد و هر تعداد عضو داده‌ای دیگر داشته باشد که نه union هستند و نه enum. علاوه بر این، انواع اعضای union و enum نباید از فایل‌های سرایند سیستمی یا فضای نام std آمده باشند.

مثال:

enum Tags {
  Tag1,
  Tag2,
};
struct TaggedUnion { // warning: tagged union has more data members (3) than tags (2)
  enum Tags Kind;
  union {
    int I;
    float F;
    char *Str;
  } Data;
};

مثال زیر استثنای مربوط به unionها و enumهای برگرفته از فایل‌های سرایند سیستمی و فضای نام std را نشان می‌دهد.

#include <pthread.h>
struct NotTaggedUnion {
  enum MyEnum { MyEnumConstant1, MyEnumConstant2 } En;
  pthread_mutex_t Mutex;
};

نوع pthread_mutex_t ممکن است در پس یک typedef به صورت یک union تعریف شده باشد، که در این حالت بررسی ممکن است این نوع را به اشتباه به عنوان یک tagged union تعریف‌شده توسط کاربر تشخیص دهد؛ چرا که دقیقاً دارای یک عضو داده‌ای enum و دقیقاً یک عضو داده‌ای union است. برای جلوگیری از موارد مثبت کاذب (false-positive) ناشی از این مسئله، unionها و enumهای موجود در سرایندهای سیستمی و فضای نام std هنگام مشخص کردن بخش union و بخش enum یک tagged union بالقوهٔ تعریف‌شده توسط کاربر، نادیده گرفته می‌شوند.

نحوهٔ شمارش ثوابت enum

عامل پیچیدگی اصلی هنگام شمارش تعداد ثوابت enum این است که برخی از آن‌ها ممکن است مقادیر کمکی باشند که عمداً هیچ عضو داده‌ای متناظری در union ندارند و برای مقاصد دیگری استفاده می‌شوند. به عنوان مثال، آخرین ثابت enum گاهی اوقات به‌طور صریح به آخرین ثابت enum معتبر اعلان‌شده "اشاره می‌کند" یا تعداد ثوابت enum اعلان‌شده را دنبال می‌کند.

جهت نمایش:

enum TagWithLast {
  Tag1 = 0,
  Tag2 = 1,
  Tag3 = 2,
  LastTag = 2
};
enum TagWithCounter {
  Tag1, // is 0
  Tag2, // is 1
  Tag3, // is 2
  TagCount, // is 3
};

این بررسی تعداد مقادیر متمایز را در بین ثوابت enum می‌شمارد و نه خود ثوابت enum را. به این ترتیب، ثوابت enum که در اصل تنها نام‌های مستعاری (alias) برای سایر ثوابت enum هستند، در شمارش نهایی لحاظ نمی‌شوند.

مدیریت شمارش ثوابت enum (مواردی مانند TagCount در مثال کد قبلی) با کاهش یک واحد از تعداد مقادیر enum انجام می‌شود، در صورتی که نام آخرین ثابت enum با پیشوند یا پسوند مشخص‌شده در CountingEnumPrefixes یا CountingEnumSuffixes مطابقت داشته باشد و مقدار آن یکی کمتر از تعداد کل مقادیر متمایز در enum باشد.

هنگامی که شمارش نهایی بر اساس این روش اکتشافی (heuristic) تنظیم شود، یک یادداشت عیب‌یابی صادر می‌شود که نشان می‌دهد کدام ثابت enum با معیارها مطابقت داشته است.

این روش اکتشافی می‌تواند کاملاً غیرفعال شود (EnableCountingEnumHeuristic) یا به گونه‌ای پیکربندی شود که از شیوه‌نامهٔ نام‌گذاری شما پیروی کند (CountingEnumPrefixes، CountingEnumSuffixes). رشته‌های مشخص‌شده در CountingEnumPrefixes و CountingEnumSuffixes بدون حساسیت به حروف کوچک و بزرگ مطابقت داده می‌شوند.

مثال‌های شمارش:

// Enum count is 3, because the value 2 is counted only once
enum TagWithLast {
  Tag1 = 0,
  Tag2 = 1,
  Tag3 = 2,
  LastTag = 2
};
// Enum count is 3, because TagCount is heuristically excluded
enum TagWithCounter {
  Tag1, // is 0
  Tag2, // is 1
  Tag3, // is 2
  TagCount, // is 3
};

گزینه‌ها

این گزینه اکتشاف شمارش مقادیر enum (counting enum heuristic) را فعال یا غیرفعال می‌کند. این گزینه از پیشوندها و پسوندهای مشخص‌شده در گزینه‌های CountingEnumPrefixes و CountingEnumSuffixes برای یافتن مقادیر ثابت شمارشگر enum از طریق تطبیق پیشوند و پسوند استفاده می‌کند.

این گزینه به‌طور پیش‌فرض فعال است.

هنگامی که EnableCountingEnumHeuristic برابر با false باشد:

enum TagWithCounter {
  Tag1,
  Tag2,
  Tag3,
  TagCount,
};
struct TaggedUnion {
  TagWithCounter Kind;
  union {
    int A;
    long B;
    char *Str;
    float F;
  } Data;
};

هنگامی که EnableCountingEnumHeuristic برابر با true باشد:

enum TagWithCounter {
  Tag1,
  Tag2,
  Tag3,
  TagCount,
};
struct TaggedUnion { // warning: tagged union has more data members (4) than tags (3)
  TagWithCounter Kind;
  union {
    int A;
    long B;
    char *Str;
    float F;
  } Data;
};

به CountingEnumSuffixes در زیر مراجعه کنید.

گزینه‌های CountingEnumPrefixes و CountingEnumSuffixes فهرست‌هایی از رشته‌های جداشده با نقطه-ویرگول (semicolon) هستند که برای جستجوی مقادیر ثابت احتمالی شمارشگر enum استفاده می‌شوند. این رشته‌ها بدون حساسیت به حروف بزرگ و کوچک (case insensitively) به ترتیب به عنوان پیشوند و پسوند روی نام‌های مقادیر ثابت enum تطبیق داده می‌شوند. اگر EnableCountingEnumHeuristic برابر با false باشد، این گزینه‌ها هیچ عملی انجام نمی‌دهند.

مقدار پیش‌فرض CountingEnumSuffixes برابر با count و برای CountingEnumPrefixes رشته خالی است.

هنگامی که EnableCountingEnumHeuristic برابر با true و CountingEnumSuffixes برابر با count;size باشد:

enum TagWithCounterCount {
  Tag1,
  Tag2,
  Tag3,
  TagCount,
};
struct TaggedUnionCount { // warning: tagged union has more data members (4) than tags (3)
  TagWithCounterCount Kind;
  union {
    int A;
    long B;
    char *Str;
    float F;
  } Data;
};
enum TagWithCounterSize {
  Tag11,
  Tag22,
  Tag33,
  TagSize,
};
struct TaggedUnionSize { // warning: tagged union has more data members (4) than tags (3)
  TagWithCounterSize Kind;
  union {
    int A;
    long B;
    char *Str;
    float F;
  } Data;
};

هنگامی که EnableCountingEnumHeuristic برابر با true و CountingEnumPrefixes برابر با maxsize;last_ باشد:

enum TagWithCounterLast {
  Tag1,
  Tag2,
  Tag3,
  last_tag,
};
struct TaggedUnionLast { // warning: tagged union has more data members (4) than tags (3)
  TagWithCounterLast tag;
  union {
    int I;
    short S;
    char *C;
    float F;
  } Data;
};
enum TagWithCounterMaxSize {
  Tag1,
  Tag2,
  Tag3,
  MaxSizeTag,
};
struct TaggedUnionMaxSize { // warning: tagged union has more data members (4) than tags (3)
  TagWithCounterMaxSize tag;
  union {
    int I;
    short S;
    char *C;
    float F;
  } Data;
};

در صورت فعال بودن، این بررسی زمانی که تعداد برچسب‌ها (tags) بیشتر از تعداد اعضای داده‌ای union باشد نیز هشدار می‌دهد.

این گزینه به‌طور پیش‌فرض غیرفعال است.

هنگامی که StrictMode <#cmdoption-arg-StrictMode> برابر با false باشد:

struct TaggedUnion {
  enum {
    Tag1,
    Tag2,
    Tag3,
  } Tags;
  union {
    int I;
    float F;
  } Data;
};

هنگامی که StrictMode <#cmdoption-arg-StrictMode> برابر با true باشد:

struct TaggedUnion { // warning: tagged union has fewer data members (2) than tags (3)
  enum {
    Tag1,
    Tag2,
    Tag3,
  } Tags;
  union {
    int I;
    float F;
  } Data;
};

void f() {
do {
  // some code
  continue; // terminating continue
  // some other code
} while(false);

bugprone-throw-keyword-missing

درباره احتمال جا افتادن کلمه کلیدی throw هشدار می‌دهد. اگر یک شیء موقت ایجاد شود، اما نوع شیء از کلاسی مشتق شده باشد (یا هم‌نام باشد) که عبارات 'EXCEPTION'، 'Exception' یا 'exception' در نام آن وجود داشته باشد، می‌توانیم فرض کنیم که قصد برنامه‌نویس پرتاب کردن (throw) آن شیء بوده است.

مثال:

void f(int i) {
  if (i < 0) {
    // Exception is created but is not thrown.
    std::runtime_error("Unexpected argument");
  }
}

bugprone-throwing-static-initialization

تمام اعلان‌های متغیرهای static یا thread_local را که مقداردهنده اولیه آن شیء ممکن است استثنایی پرتاب کند، پیدا می‌کند.

References

این بررسی با قاعده ERR58-CPP از استاندارد کدنویسی CERT C++ مطابقت دارد. مدیریت تمام استثناهای پرتاب‌شده پیش از آغاز اجرای ()main https://www.securecoding.cert.org/confluence/display/cplusplus/ERR58-CPP.+Handle+all+exceptions+thrown+before+main%28%29+begins+executing.

bugprone-too-small-loop-variable

حلقه‌های for را شناسایی می‌کند که متغیر حلقه آن‌ها از یک نوع «بسیار کوچک» ("too small") است، به این معنی که این نوع نمی‌تواند تمام مقادیر موجود در محدوده پیمایش را نمایش دهد.

int main() {
  long size = 294967296l;
  for (short i = 0; i < size; ++i) {}
}

این حلقه for یک حلقه بی‌نهایت است زیرا نوع short نمی‌تواند تمام مقادیر بازه [0..size] را نمایش دهد.

در یک کاربرد واقعی، size به معنی اندازه یک ظرف (container) است که به ورودی کاربر بستگی دارد.

int doSomething(const std::vector& items) {
  for (short i = 0; i < items.size(); ++i) {}
}

این الگوریتم برای تعداد اندکی شیء کار می‌کند، اما برای ورودی‌های بزرگتر کاربر منجر به فریز شدن (قفل کردن) برنامه خواهد شد.

توصیه می‌شود هشدار کامپایلر -Wtautological-constant-out-of-range-compare را نیز فعال کنید، چرا که این بررسی برای جلوگیری از تداخل با این هشدار، مرزهای ثابت حلقه در زمان کامپایل را بازرسی نمی‌کند.

Options

int main() {
  long size = 294967296l;
  for (unsigned i = 0; i < size; ++i) {} // no warning with MagnitudeBitsUpperLimit = 31 on a system where unsigned is 32-bit
  for (int i = 0; i < size; ++i) {} // warning with MagnitudeBitsUpperLimit = 31 on a system where int is 32-bit
}

bugprone-unchecked-optional-access

نکته: این بررسی برای تولید نتایج خود از تحلیل ایستا حساس به جریان داده (flow-sensitive) استفاده می‌کند. بنابراین، ممکن است نسبت به یک بررسی معمولی clang-tidy به منابع بیشتری (RAM، CPU) نیاز داشته باشد.

این بررسی دسترسی‌های ناامن به مقادیر موجود در اشیاء std::optional<T>، absl::optional<T>، base::Optional<T>، folly::Optional<T>، bsl::optional، یا BloombergLP::bdlb::NullableValue را شناسایی می‌کند. در ادامه ما به همه این نوع‌ها به صورت جمعی با عنوان optional<T> اشاره خواهیم کرد.

دسترسی به مقدار یک optional<T> زمانی رخ می‌دهد که یکی از توابع عضو value، operator* یا operator-> آن فراخوانی شود. برای همسویی با باورهای نادرست رایج، این بررسی این توابع عضو را معادل در نظر می‌گیرد، اگرچه تفاوت‌های ظریفی بین استثناها و رفتار تعریف‌نشده (undefined behavior) وجود دارد. برای اطلاعات بیشتر در این باره، بخش یادداشت‌های بیشتر را در زیر ببینید.

دسترسی به مقدار یک optional<T> امن تلقی می‌شود اگر و تنها اگر کد موجود در حوزه محلی (برای مثال، بدنه یک تابع) تضمین کند که optional<T> در تمام مسیرهای ممکنِ اجرا که می‌توانند به این دسترسی برسند، دارای مقدار است. این امر باید یا از طریق یک بررسی صریح با استفاده از تابع عضو optional<T>::has_value انجام شود، یا از طریق ساختن optional<T> به روشی که بدون ابهام نشان دهد حاوی مقدار است (مانند استفاده از std::make_optional که همیشه یک std::optional<T> پرشده را برمی‌گرداند).

در زیر مثال‌هایی آورده‌ایم که با الگوهای دسترسی ناامن به optional شروع شده و با الگوهای دسترسی امن ادامه می‌یابند.

Unsafe access patterns

Access the value without checking if it exists

این بررسی، دسترسی‌هایی به مقدار را نشانه‌گذاری می‌کند که به صورت محلی با بررسی وجود محافظت نشده‌اند:

void f(std::optional<int> opt) {
  use(*opt); // unsafe: it is unclear whether `opt` has a value.
}

دسترسی به مقدار در شاخه نادرست

این بررسی از وضعیت یک شیء optional در شاخه‌های مختلف کد آگاه است. برای مثال:

void f(std::optional<int> opt) {
  if (opt.has_value()) {
  } else {
    use(opt.value()); // unsafe: it is clear that `opt` does *not* have a value.
  }
}

فرض بر پایدار بودن نتیجه یک تابع

این بررسی آگاه است که نتایج توابع ممکن است پایدار نباشند. یعنی فراخوانی‌های متوالی یک تابع یکسان ممکن است مقادیر متفاوتی را بازگردانند. برای مثال:

void f(Foo foo) {
  if (foo.take().has_value()) {
    use(*foo.take()); // unsafe: it is unclear whether `foo.take()` has a value.
  }
}

استثنا: متدهای دستیابی (accessor)

این بررسی متدهای accessor یک کلاس را با استفاده از یک روش ابتکاری (heuristic) برای تشخیص اینکه کدام متدها دستیاب هستند، پایدار فرض می‌کند. به‌طور مشخص، متدهای const بدون پارامتر و APIهای شبه‌اشاره‌گر هوشمند (سربارگذاری‌های غیر const از * در صورتی که یک سربارگذاری const موازی وجود داشته باشد) به عنوان متدهای دستیاب در نظر گرفته می‌شوند. توجه داشته باشید که ایمن بودن این کار تضمین‌شده نیست -- اما در عمل به‌طور گسترده (و ایمن) استفاده می‌شود. فرض بر این است که فراخوانی متدهای غیر const وضعیت شیء را تغییر داده و بر پایداری فراخوانی‌های قبلی متدهای دستیاب اثر می‌گذارد.

اتکا به ناورداهای APIهای نامعمول

این بررسی از ناورداهای (invariants) مربوط به APIهای نامعمول آگاه نیست. برای مثال:

void f(Foo foo) {
  if (foo.HasProperty("bar")) {
    use(*foo.GetProperty("bar")); // unsafe: it is unclear whether `foo.GetProperty("bar")` has a value.
  }
}

بررسی وجود مقدار، سپس ارسال optional به تابعی دیگر

این بررسی بر استدلال محلی تکیه دارد. بررسی و دسترسی به مقدار هر دو باید در یک تابع یکسان رخ دهند. دسترسی ناامن تلقی می‌شود، حتی اگر فراخوانندهٔ تابعی که دسترسی را انجام می‌دهد اطمینان حاصل کند که شیء optional حاوی مقدار است. برای مثال:

void g(std::optional<int> opt) {
  use(*opt); // unsafe: it is unclear whether `opt` has a value.
}
void f(std::optional<int> opt) {
  if (opt.has_value()) {
    g(opt);
  }
}

الگوهای دسترسی ایمن

بررسی وجود مقدار، سپس دسترسی به آن

این بررسی تمام روش‌های سرراست برای بررسی وجود مقدار و دسترسی به مقدارِ درون یک شیء optional را شناسایی می‌کند. برای مثال:

void f(std::optional<int> opt) {
  if (opt.has_value()) {
    use(*opt);
  }
}

بررسی وجود مقدار، سپس دسترسی به مقدار از طریق یک کپی

معیاری که این بررسی به کار می‌برد معنایی (semantic) است، نه نحوی (syntactic). این بررسی تشخیص می‌دهد چه زمانی یک کپی از شیء optional در حال دسترسی، دارای مقدار است. برای مثال:

void f(std::optional<int> opt1) {
  if (opt1.has_value()) {
    std::optional<int> opt2 = opt1;
    use(*opt2);
  }
}

اطمینان از وجود مقدار با استفاده از ماکروهای رایج

این بررسی از ماکروهای رایجی مانند CHECK و DCHECK آگاه است. از این ماکروها می‌توان برای اطمینان از اینکه یک شیء optional دارای مقدار است استفاده کرد. برای مثال:

void f(std::optional<int> opt) {
  DCHECK(opt.has_value());
  use(*opt);
}

اطمینان از وجود مقدار، سپس دسترسی به مقدار در شاخه‌ای مرتبط

این بررسی از شاخه‌های مرتبط در کد آگاه است و می‌تواند تشخیص دهد چه زمانی در تمام مسیرهای اجرایی منتهی به دسترسی، وجود مقدار در یک شیء optional تضمین شده است. برای مثال:

void f(std::optional<int> opt) {
  bool safe = false;
  if (opt.has_value() && SomeOtherCondition()) {
    safe = true;
  }
  // ... more code...
  if (safe) {
    use(*opt);
  }
}

تثبیت نتایج توابع

فرض بر این نیست که نتایج تابع در طول فراخوانی‌های پیاپی پایدار باشند، مگر برای متدهای دسترسی‌دهنده (accessor) از نوع const. برای متدهای دسترسی‌دهنده پیچیده‌تر (غیر const، یا وابسته به چندین پارامتر) بهتر است نتیجه فراخوانی تابع در یک متغیر محلی ذخیره شده و از آن متغیر برای دسترسی به مقدار استفاده شود. به عنوان مثال:

void f(Foo foo) {
  if (const auto& foo_opt = foo.take(); foo_opt.has_value()) {
    use(*foo_opt);
  }
}

عدم اتکا به ناورداهای APIهای غیرمعمول

هنگامی که APIهای نامتعارف تضمین می‌کنند که یک optional حاوی محتوا است، به آن اعتماد نکنید -- در عوض، صریحاً بررسی کنید که شیء optional دارای مقدار باشد. برای مثال:

void f(Foo foo) {
  if (const auto& property = foo.GetProperty("bar")) {
    use(*property);
  }
}

به جای زوج HasProperty و GetProperty که در بالا دیدیم.

عدم اتکا به بررسی‌های انجام‌شده توسط فراخواننده

اگر می‌دانید که تمام فراخواننده‌های یک تابع بررسی کرده‌اند که یک آرگومان optional دارای مقدار است، یا تابع را به گونه‌ای تغییر دهید که مقدار را مستقیماً دریافت کند یا optional را دوباره در حوزه محلی تابع فراخوانی‌شده بررسی کنید. برای مثال:

void g(int val) {
  use(val);
}
void f(std::optional<int> opt) {
  if (opt.has_value()) {
    g(*opt);
  }
}

و

struct S {
  std::optional<int> opt;
  int x;
};
void g(const S &s) {
  if (s.opt.has_value() && s.x > 10) {
    use(*s.opt);
}
void f(S s) {
  if (s.opt.has_value()) {
    g(s);
  }
}

نکات تکمیلی

نام‌های مستعار ایجاد شده از طریق اعلان‌های using

این بررسی از نام‌های مستعار انواع optional که از طریق اعلان‌های using ایجاد می‌شوند آگاه است. برای مثال:

using OptionalInt = std::optional<int>;
void f(OptionalInt opt) {
  use(opt.value()); // unsafe: it is unclear whether `opt` has a value.
}

توابع لامبدا

این بررسی در حال حاضر دسترسی‌های ناامن optional را در توابع لامبدا گزارش نمی‌کند. نسخه بعدی با پیروی از قوانین مشخص‌شده در بالا، دامنه را به لامبداها گسترش خواهد داد. بهتر است هنگام استفاده از optionalها در لامبداها از همین اصول پیروی کنید.

دسترسی از طریق operator*() در مقایسه با value()

با توجه به اینکه value() رفتار کاملاً تعریف‌شده‌ای دارد (یا استثنا پرتاب می‌کند یا برنامه را خاتمه می‌دهد)، چرا رفتاری مشابه با operator*() دارد که باعث رفتار تعریف‌نشده (UB) می‌شود؟ به عبارت دیگر، چرا دسترسی به یک optional با استفاده از value() ناامن تلقی می‌شود، در صورتی که قابل اثبات نباشد که حاوی مقدار است؟ به همین ترتیب، چرا CHECK() به همراه operator*() بهتر از value() است، با توجه به اینکه از نظر معنایی معادل یکدیگرند (در پیکربندی‌هایی که استثناها را غیرفعال کرده‌اند)؟

پاسخ این است که ما فرض می‌کنیم اکثر کاربران متوجه تفاوت بین value() و operator*() نیستند. تغییر شیوه به operator*() و نوعی بررسی صریح وجود مقدار یا خاتمه صریح برنامه دارای دو مزیت است:

گزینه‌ها

bugprone-unchecked-string-to-number-conversion

این بررسی فراخوانی توابع تبدیل رشته به عدد را که صحت تبدیل را بررسی نمی‌کنند، مانند atoi() یا scanf()، نشانه‌گذاری می‌کند. این بررسی فراخوانی‌های strtol() یا سایر توابع تبدیل مرتبط را که بررسی خطای بهتری انجام می‌دهند، نشانه‌گذاری نمی‌کند.

#include <stdlib.h>
void func(const char *buff) {
  int si;
  if (buff) {
    si = atoi(buff); /* 'atoi' used to convert a string to an integer, but function will
                         not report conversion errors; consider using 'strtol' instead. */
  } else {
    /* Handle error */
  }
}

مراجع

این بررسی با قاعده استاندارد کدنویسی CERT C مطابقت دارد: ERR34-C. Detect errors when converting a string to a number https://www.securecoding.cert.org/confluence/display/c/ERR34-C.+Detect+errors+when+converting+a+string+to+a+number.

bugprone-undefined-memory-manipulation

فراخوانی توابع دستکاری حافظه memset()، memcpy() و memmove() را روی اشیاء غیر TriviallyCopyable که منجر به رفتار تعریف‌نشده (undefined behavior) می‌شوند، پیدا می‌کند.

استفاده از توابع دستکاری حافظه روی اشیاء غیر TriviallyCopyable می‌تواند منجر به مجموعه‌ای از مشکلات ظریف و چالش‌برانگیز در کدهای C++ شود. فوری‌ترین نگرانی، احتمال بروز رفتار تعریف‌نشده است که در آن ممکن است وضعیت شیء خراب یا نامعتبر شود. این مسئله می‌تواند به صورت کرش، خرابی داده‌ها، یا رفتارهای غیرمنتظره در زمان اجرا ظاهر شود و شناسایی و عیب‌یابی علت اصلی را دشوار سازد. علاوه بر این، استفاده نادرست از توابع دستکاری حافظه می‌تواند عملیات ضروری مختص شیء، مانند سازنده‌ها و نابودکننده‌ها را دور بزند و منجر به نشت منابع یا مقداردهی اولیه نادرست شود.

به عنوان مثال، هنگام استفاده از memcpy برای کپی کردن std::string، داده‌های اشاره‌گر کپی می‌شوند و این امر می‌تواند منجر به خطای آزادسازی مضاعف (double free) شود.

#include <cstring>
#include <string>
int main() {
    std::string source = "Hello";
    std::string destination;
    std::memcpy(&destination, &source, sizeof(std::string));
    // Undefined behavior may occur here, during std::string destructor call.
    return 0;
}

bugprone-undelegated-constructor

ایجاد اشیاء موقت در سازنده‌ها را که شبیه به فراخوانی تابعی از یک سازنده دیگر از همان کلاس به نظر می‌رسند، پیدا می‌کند.

کاربر به احتمال زیاد قصد استفاده از یک سازنده واسط (delegating constructor) یا مقداردهی اولیه کلاس پایه را داشته است.

bugprone-unhandled-exception-at-new

فراخوانی‌های new فاقد مدیریت‌کننده استثنا برای std::bad_alloc را پیدا می‌کند.

فراخوانی‌های new ممکن است استثناهایی از نوع std::bad_alloc پرتاب کنند که باید مدیریت شوند. به عنوان روش جایگزین، می‌توان از شکل بدون پرتاب استثنای (nonthrowing) عملگر new استفاده کرد. این بررسی صحت مدیریت استثنا در تابعی را که new را فراخوانی می‌کند، تأیید می‌نماید.

اگر از نسخه nonthrowing استفاده شود یا اجازه داده شود استثنا به خارج از تابع منتشر (propagate) شود، هیچ هشداری تولید نمی‌شود.

بررسی می‌شود که آیا مدیریت‌کننده استثنا یک استثنا از نوع std::bad_alloc، یا std::exception، و یا همه استثناها (catch-all) را دریافت می‌کند یا خیر. این بررسی فرض می‌کند هر operator new تعریف‌شده توسط کاربر یا noexcept است یا ممکن است استثنایی از نوع std::bad_alloc (یا مشتق‌شده از آن) پرتاب کند. سایر انواع کلاس‌های استثنا در نظر گرفته نمی‌شوند.

int *f() noexcept {
  int *p = new int[1000]; // warning: missing exception handler for allocation failure at 'new'
  // ...
  return p;
}

int *f1() { // not 'noexcept'
  int *p = new int[1000]; // no warning: exception can be handled outside
                          // of this function
  // ...
  return p;
}
int *f2() noexcept {
  try {
    int *p = new int[1000]; // no warning: exception is handled
    // ...
    return p;
  } catch (std::bad_alloc &) {
    // ...
  }
  // ...
}
int *f3() noexcept {
  int *p = new (std::nothrow) int[1000]; // no warning: "nothrow" is used
  // ...
  return p;
}

bugprone-unhandled-self-assignment

شناسه cert-oop54-cpp به عنوان نام مستعار این بررسی به اینجا تغییر مسیر می‌دهد. برای نام مستعار CERT، گزینه WarnOnlyIfThisHasSuspiciousField بر روی false تنظیم شده است.

عملگرهای انتساب کپی تعریف‌شده توسط کاربر را که با بررسی صریح انتساب به خود یا با استفاده از روش copy-and-swap یا copy-and-move از کد در برابر انتساب به خود محافظت نمی‌کنند، پیدا می‌کند.

به‌طور پیش‌فرض، این بررسی برای جلوگیری از هشدارهای نادرست (false positives)، تنها کلاس‌هایی را جستجو می‌کند که دارای فیلد اشاره‌گر یا آرایه C هستند. در صورت وجود اشاره‌گر یا آرایه C، اگر عملگر انتساب کپی با دقت نوشته نشده باشد، احتمال دارد انتساب کپی به خود باعث خرابی شیء شود.

همچنین ببینید: OOP54-CPP. Gracefully handle self-copy assignment https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP54-CPP.+Gracefully+handle+self-copy+assignment

یک عملگر انتساب کپی باید از خراب شدن وضعیت شیء توسط انتساب کپی به خود جلوگیری کند. یک سناریوی رایج زمانی است که کلاس دارای یک فیلد اشاره‌گر باشد و عملگر انتساب کپی ابتدا شیء اشاره‌شده را آزاد کرده و سپس سعی کند آن را انتساب دهد:

class T {
int* p;
public:
  T(const T &rhs) : p(rhs.p ? new int(*rhs.p) : nullptr) {}
  ~T() { delete p; }
  // ...
  T& operator=(const T &rhs) {
    delete p;
    p = new int(*rhs.p);
    return *this;
  }
};

برای جلوگیری از این مشکل، دو الگوی رایج C++ وجود دارد. الگوی اول، بررسی انتساب به خود (self-assignment check) است:

class T {
int* p;
public:
  T(const T &rhs) : p(rhs.p ? new int(*rhs.p) : nullptr) {}
  ~T() { delete p; }
  // ...
  T& operator=(const T &rhs) {
    if(this == &rhs)
      return *this;
    delete p;
    p = new int(*rhs.p);
    return *this;
  }
};

روش دوم روش copy-and-swap است، هنگامی که یک کپی موقت (با استفاده از سازنده کپی) ایجاد می‌کنیم و سپس این شیء موقت را با this تعویض (swap) می‌نماییم:

class T {
int* p;
public:
  T(const T &rhs) : p(rhs.p ? new int(*rhs.p) : nullptr) {}
  ~T() { delete p; }
  // ...
  void swap(T &rhs) {
    using std::swap;
    swap(p, rhs.p);
  }
  T& operator=(const T &rhs) {
    T(rhs).swap(*this);
    return *this;
  }
};

الگوی سومی نیز وجود دارد که کمتر رایج است. می‌توان آن را روش copy-and-move نامید، زمانی که یک کپی موقت ایجاد می‌کنیم (با استفاده از سازنده کپی) و سپس این شیء موقت را به this انتقال (move) می‌دهیم (به یک عملگر انتساب انتقال نیاز دارد):

class T {
int* p;
public:
  T(const T &rhs) : p(rhs.p ? new int(*rhs.p) : nullptr) {}
  ~T() { delete p; }
  // ...
  T& operator=(const T &rhs) {
    T t = rhs;
    *this = std::move(t);
    return *this;
  }
  T& operator=(T &&rhs) {
    p = rhs.p;
    rhs.p = nullptr;
    return *this;
  }
};

Options

bugprone-unintended-char-ostream-output

خروجی‌های ناخواسته کاراکتر از نوع‌های unsigned char و signed char به یک ostream را می‌یابد.

معمولاً هنگامی که unsigned char (uint8_t) یا signed char (int8_t) استفاده می‌شود، بیشتر بیانگر یک عدد است تا یک کاراکتر. با این حال، هنگامی که مستقیماً به operator<< در std::ostream فرستاده می‌شود، نتیجه به جای مقدار عددی، خروجی کاراکتری خواهد بود. این مسئله اغلب با قصد برنامه‌نویس برای چاپ مقادیر عددی صحیح مغایرت دارد.

uint8_t v = 65;
std::cout << v; // output 'A' instead of '65'

این بررسی پیشنهاد تبدیل نوع (cast) مقدار به نوعی مناسب را برای مشخص کردن هدف ارائه می‌دهد؛ به صورت پیش‌فرض، برای unsigned char به unsigned int و برای signed char به int تبدیل می‌کند.

std::cout << static_cast<unsigned int>(v); // when v is unsigned char
std::cout << static_cast<int>(v); // when v is signed char

برای جلوگیری از عبارات طولانی تبدیل نوع، افزودن پیشوند + به متغیر نیز می‌تواند هشدارها را سرکوب کند؛ زیرا عبارت یکانی مقدار را به یک int ارتقا می‌دهد (type promotion).

std::cout << +v;

یا می‌توان آن را به صورت صریح به char تبدیل نوع کرد تا مشخص شود خروجی حتماً باید یک کاراکتر باشد.

std::cout << static_cast<char>(v);

Options

bugprone-unique-ptr-array-mismatch

مقداردهی‌های اولیهٔ اشاره‌گرهای یکتای ++C (از نوع std::unique_ptr) از انواع غیرآرایه‌ای را که با یک آرایه مقداردهی شده‌اند، پیدا می‌کند.

اگر یک اشاره‌گر std::unique_ptr<T> با یک عبارت new از نوع new T[] مقداردهی اولیه شود، حافظه به درستی آزاد نمی‌شود. در این حالت برای آزادسازی حافظهٔ هدف از یک delete معمولی استفاده می‌شود؛ در حالی که به فراخوانی delete[] نیاز است. ساختار std::unique_ptr<T[]> از عملگر delete صحیح استفاده می‌کند. اگر از یک unique_ptr با deleter تعریف‌شده توسط کاربر استفاده شود، این بررسی هشداری صادر نمی‌کند.

اگر در اعلان یک متغیر منفرد استفاده شده باشد (یک متغیر در یک دستور)، این بررسی جایگزینی unique_ptr<T> با unique_ptr<T[]> را پیشنهاد می‌دهد.

مثال:

std::unique_ptr<Foo> x(new Foo[10]); // -> std::unique_ptr<Foo[]> x(new Foo[10]);
//                     ^ warning: unique pointer to non-array is initialized with array
std::unique_ptr<Foo> x1(new Foo), x2(new Foo[10]); // no replacement
//                                   ^ warning: unique pointer to non-array is initialized with array
D d;
std::unique_ptr<Foo, D> x3(new Foo[10], d); // no warning (custom deleter used)
struct S {
  std::unique_ptr<Foo> x(new Foo[10]); // no replacement in this case
  //                     ^ warning: unique pointer to non-array is initialized with array
};

این بررسی تا حدی قاعدهٔ MEM51-CPP مربوط به CERT C++ Coding Standard را پوشش می‌دهد: Properly deallocate dynamically allocated resources https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM51-CPP.+Properly+deallocate+dynamically+allocated+resources با این حال، تنها حالت std::unique_ptr توسط این بررسی شناسایی می‌شود.

bugprone-unsafe-functions

توابعی را بررسی می‌کند که جایگزین‌های ایمن‌تر و امن‌تری برای آن‌ها در دسترس است، یا به دلیل ایرادات طراحی منسوخ (deprecated) در نظر گرفته می‌شوند. این بررسی به شدت به توابع موجود در Annex K. به عنوان «Bounds-checking interfaces» در استاندارد C11 متکی است.

گزینه‌های cert-msc24-c و cert-msc33-c به عنوان نام‌های مستعار این بررسی به اینجا هدایت می‌شوند.

Unsafe functions

توابع زیر در صورت فعال بودن ReportDefaultFunctions گزارش می‌شوند.

در صورت در دسترس بودن Annex K.، یک جایگزین از Annex K. برای توابع زیر پیشنهاد می‌شود:

asctime, asctime_r, bsearch, ctime, fopen, fprintf, freopen, fscanf, fwprintf, fwscanf, getenv, gets, gmtime, localtime, mbsrtowcs, mbstowcs, memcpy, memmove, memset, printf, qsort, scanf, snprintf, sprintf, sscanf, strcat, strcpy, strerror, strlen, strncat, strncpy, strtok, swprintf, swscanf, vfprintf, vfscanf, vfwprintf, vfwscanf, vprintf, vscanf, vsnprintf, vsprintf, vsscanf, vswprintf, vswscanf, vwprintf, vwscanf, wcrtomb, wcscat, wcscpy, wcslen, wcsncat, wcsncpy, wcsrtombs, wcstok, wcstombs, wctomb, wmemcpy, wmemmove, wprintf, wscanf.

اگر Annex K. در دسترس نباشد، جایگزین‌ها تنها برای توابع زیر از فهرست قبلی پیشنهاد می‌شوند:

توابع زیر بدون در نظر گرفتن در دسترس بودن Annex K، همواره بررسی می‌شوند:

اگر ReportMoreUnsafeFunctions فعال باشد، توابع زیر نیز بررسی می‌شوند:

اگرچه در قواعد مرتبط CERT ذکر شده‌اند، توابع زیر توسط این بررسی نادیده گرفته می‌شوند:

atof, atoi, atol, atoll, tmpfile.

در دسترس بودن Annex K بر اساس ماکروهای زیر تعیین می‌شود:

هر دو ماکرو باید تعریف شده باشند تا توابع جایگزین از Annex K. پیشنهاد شوند. __STDC_LIB_EXT1__ توسط پیاده‌سازی کتابخانه تعریف می‌شود، و __STDC_WANT_LIB_EXT1__ باید پیش از گنجاندن هرگونه فایل سرایند سیستمی توسط کاربر برابر با 1 تعریف شود.

توابع سفارشی

گزینهٔ CustomFunctions به کاربر امکان می‌دهد تا توابع سفارشی را برای بررسی شدن تعریف کند. قالب آن به صورت زیر و بدون خطوط جدید (newline) است:

bugprone-unsafe-functions.CustomFunctions="
  functionRegex1[, replacement1[, reason1]];
  functionRegex2[, replacement2[, reason2]];
  ...
"

توابع با استفاده از عبارت‌های منظم تعمیم‌یافتهٔ POSIX تطبیق داده می‌شوند. (نکته: عبارت‌های منظم از تطبیق‌های منفی (?!) پشتیبانی نمی‌کنند.)

شناسهٔ reason اختیاری است و برای ارائهٔ اطلاعات بیشتر در مورد دلیلِ پشتِ این جایگزینی استفاده می‌شود. دلیل پیش‌فرض عبارت است از is marked as unsafe.

اگر replacement خالی باشد، متن پیش‌فرض it should not be used به جای پیشنهادی برای جایگزینی نمایش داده خواهد شد.

اگر reason با نویسهٔ > شروع شود، دلیل کاملاً سفارشی می‌شود. پسوند پیش‌فرض حتی در صورت وجود replacement نیز غیرفعال شده و برای ایجاد امکان کنترل بهتر بر روی پیشنهادات، تنها پیام دلیل پس از تابع تطبیق‌یافته نمایش داده می‌شود. (نویسهٔ > ابتدایی و فاصله‌های خالی بلافاصله پس از آن از پیام حذف می‌شوند.)

به عنوان مثال، پیکربندی زیر تنها تابع original در فضای‌نام پیش‌فرض را تطبیق می‌دهد. یک پیام عیب‌یابی مشابه را می‌توان با استفاده از یک دلیل کاملاً سفارشی نیز چاپ کرد.

// bugprone-unsafe-functions.CustomFunctions:
//   ^original$, replacement, is deprecated;
// Using the fully custom message syntax:
//   ^suspicious$,,> should be avoided if possible.
original(); // warning: function 'original' is deprecated; 'replacement' should be used instead.
suspicious(); // warning: function 'suspicious' should be avoided if possible.
::std::original(); // no-warning
original_function(); // no-warning

اگر عبارت منظم شامل نویسهٔ : باشد، با نام دارای صلاحیت (یعنی std::original) تطبیق داده می‌شود؛ در غیر این صورت عبارت منظم با نام بدون صلاحیت (original) تطبیق داده خواهد شد. اگر عبارت منظم با :: (یا ^::) آغاز شود، با نام دارای صلاحیت کامل (::std::original) تطبیق داده می‌شود.

یکی از موارد کاربرد پیام‌های کاملاً سفارشی، پیشنهاد دادن گزینه‌های کامپایلر و فلگ‌های هشدار است:

// bugprone-unsafe-functions.CustomFunctions:
//   ^memcpy$,,>is recommended to have compiler hardening using '_FORTIFY_SOURCE';
//   ^printf$,,>is recommended to have the '-Werror=format-security' compiler warning flag;
memcpy(dest, src, 999'999); // warning: function 'memcpy' is recommended to have compiler hardening using '_FORTIFY_SOURCE'
printf(raw_str); // warning: function 'printf' is recommended to have the '-Werror=format-security' compiler warning flag

نکته:

گزینه‌ها

مثال‌ها

#ifndef __STDC_LIB_EXT1__
#error "Annex K is not supported by the current standard library implementation."
#endif
#define __STDC_WANT_LIB_EXT1__ 1
#include <string.h> // Defines functions from Annex K.
#include <stdio.h>
enum { BUFSIZE = 32 };
void Unsafe(const char *Msg) {
  static const char Prefix[] = "Error: ";
  static const char Suffix[] = "\n";
  char Buf[BUFSIZE] = {0};
  strcpy(Buf, Prefix); // warning: function 'strcpy' is not bounds-checking; 'strcpy_s' should be used instead.
  strcat(Buf, Msg);    // warning: function 'strcat' is not bounds-checking; 'strcat_s' should be used instead.
  strcat(Buf, Suffix); // warning: function 'strcat' is not bounds-checking; 'strcat_s' should be used instead.
  if (fputs(buf, stderr) < 0) {
    // error handling
    return;
  }
}
void UsingSafeFunctions(const char *Msg) {
  static const char Prefix[] = "Error: ";
  static const char Suffix[] = "\n";
  char Buf[BUFSIZE] = {0};
  if (strcpy_s(Buf, BUFSIZE, Prefix) != 0) {
    // error handling
    return;
  }
  if (strcat_s(Buf, BUFSIZE, Msg) != 0) {
    // error handling
    return;
  }
  if (strcat_s(Buf, BUFSIZE, Suffix) != 0) {
    // error handling
    return;
  }
  if (fputs(Buf, stderr) < 0) {
    // error handling
    return;
  }
}

bugprone-unused-local-non-trivial-variable

هنگامی که یک متغیر غیربدیهی (non-trivial) محلی درون یک تابع بدون استفاده بماند، هشدار می‌دهد. انواع متغیرهای زیر از این بررسی مستثنی هستند:

این بررسی می‌تواند پیکربندی شود تا با تنظیم IncludeTypes بر روی .* برای تمام متغیرهای غیربدیهی هشدار دهد، و انواع خاصی را با استفاده از ExcludeTypes مستثنی کند.

در این مثال، my_lock هشداری مبنی بر استفاده نشدن ایجاد می‌کند.

std::mutex my_lock;
// my_lock local variable is never used

در مثال بعدی، future2 هشداری مبنی بر استفاده نشدن ایجاد می‌کند.

std::future<MyObject> future1;
std::future<MyObject> future2;
// ...
MyObject foo = future1.get();
// future2 is not used.

گزینه‌ها

bugprone-unused-raii

اشیاء موقتی را که شبیه به اشیاء RAII هستند پیدا می‌کند.

مثال کلاسیک برای این مورد، یک قفل با محدوده متغیر (scoped lock) است.

{
  scoped_lock(&global_mutex);
  critical_section();
}

مخرب (destructor) مربوط به scoped_lock پیش از ورود به critical_section فراخوانی می‌شود و آن را بدون محافظت باقی می‌گذارد.

ما از تعدادی روش ابتکاری (heuristics) برای کاهش تعداد موارد مثبت کاذب در این بررسی استفاده می‌کنیم:

bugprone-unused-return-value

در مورد مقادیر بازگشتی استفاده‌نشده توابع هشدار می‌دهد. توابع مورد بررسی را می‌توان پیکربندی کرد.

سربارگذاری عملگرها (operator overloading) با معنای انتساب نادیده گرفته می‌شوند.

گزینه‌ها

بررسی cert-err33-c <> نام مستعاری (alias) برای این بررسی است که مجموعه ثابت و بزرگی از توابع کتابخانه استاندارد را بررسی می‌کند.

bugprone-use-after-move

هشدار می‌دهد اگر از یک شیء پس از انتقال (move) داده شدن استفاده شود، برای نمونه:

std::string str = "Hello, world!\n";
std::vector<std::string> messages;
messages.emplace_back(std::move(str));
std::cout << str;

خط آخر هشداری صادر می‌کند مبنی بر اینکه str پس از انتقال یافتن، استفاده شده است.

این بررسی در صورتی که شیء پس از انتقال و پیش از استفاده دوباره مقداردهی اولیه (reinitialize) شود، هشداری صادر نمی‌کند. برای نمونه، برای این کد هیچ هشداری ایجاد نخواهد شد:

messages.emplace_back(std::move(str));
str = "Greetings, stranger!\n";
std::cout << str;

بخش‌های زیر دقیق‌تر توضیح می‌دهند که این بررسی دقیقاً چه مواردی را انتقال، استفاده و مقداردهی اولیه در نظر می‌گیرد.

این بررسی جریان کنترل (control flow) را در نظر می‌گیرد. هشدار تنها در صورتی صادر می‌شود که استفاده از شیء از نقطه انتقال قابل دستیابی باشد. این بدین معناست که کد زیر هشداری تولید نمی‌کند:

if (condition) {
  messages.emplace_back(std::move(str));
} else {
  std::cout << str;
}

از سوی دیگر، کد زیر یک هشدار تولید می‌کند:

for (int i = 0; i < 10; ++i) {
  std::cout << str;
  messages.emplace_back(std::move(str));
}

(استفاده پس از انتقال در تکرار دوم حلقه رخ می‌دهد.)

در برخی موارد، این بررسی ممکن است قادر به تشخیص ناسازگار بودن (mutually exclusive) دو شاخه نباشد. برای نمونه (با فرض اینکه i یک int است):

if (i == 1) {
  messages.emplace_back(std::move(str));
}
if (i == 2) {
  std::cout << str;
}

در این حالت، بررسی به اشتباه هشداری تولید خواهد کرد، هرچند که اجرای هم‌زمان هر دو دستورِ انتقال و استفاده ناممکن است. به بیان رسمی‌تر، تحلیل این ابزار به جریان حساس است اما به مسیر حساس نیست (flow-sensitive but not path-sensitive) https://en.wikipedia.org/wiki/Data-flow_analysis#Sensitivities.

بی‌صدا کردن هشدارهای نادرست

یک هشدار نادرست را می‌توان با مقداردهی اولیه دوباره شیء پس از انتقال بی‌صدا کرد:

if (i == 1) {
  messages.emplace_back(std::move(str));
  str = "";
}
if (i == 2) {
  std::cout << str;
}

اگر می‌خواهید از بار اضافی ناشی از مقداردهی اولیه مجدد شیء جلوگیری کنید، می‌توانید یک تابع صوری (dummy) بسازید که باعث شود این بررسی فرض کند شیء دوباره مقداردهی اولیه شده است:

template <class T>
void IS_INITIALIZED(T&) {}

می‌توانید از آن به صورت زیر استفاده کنید:

if (i == 1) {
  messages.emplace_back(std::move(str));
}
if (i == 2) {
  IS_INITIALIZED(str);
  std::cout << str;
}

در این حالت، بررسی هشداری صادر نخواهد کرد زیرا ارسال شیء به یک تابع به عنوان یک اشاره‌گر یا ارجاع غیر-ثابت (non-const) به عنوان مقداردهی اولیه دوباره به حساب می‌آید (بخش مقداردهی اولیه دوباره را در زیر ببینید).

انتقال‌ها، استفاده‌ها و مقداردهی‌های اولیه مرتب‌نشده (Unsequenced)

در بسیاری از موارد، C++ هیچ تضمینی در مورد ترتیبی که در آن زیرعبارت‌های یک گزاره ارزیابی می‌شوند ارائه نمی‌دهد. این بدان معناست که در کدهایی مانند نمونه زیر، تضمینی وجود ندارد که استفاده قبل از انتقال رخ خواهد داد یا بعد از آن:

void f(int i, std::vector<int> v);
std::vector<int> v = { 1, 2, 3 };
f(v[1], std::move(v));

در چنین شرایطی، بررسی متذکر خواهد شد که استفاده و انتقال از نوع مرتب‌نشده (unsequenced) هستند.

این بررسی همچنین قواعد ترتیب‌بندی را هنگامی که مقداردهی اولیه دوباره در همان عبارت انتقال یا استفاده رخ می‌دهد، در نظر می‌گیرد. مقداردهی اولیه دوباره تنها در صورتی برای یک متغیر معتبر شناخته می‌شود که تضمین شده باشد پس از انتقال و پیش از استفاده ارزیابی می‌شود.

انتقال (Move)

این بررسی در حال حاضر تنها فراخوانی‌های std::move روی متغیرهای محلی یا پارامترهای تابع را در نظر می‌گیرد. این بررسی انتقال متغیرهای عضو یا متغیرهای سراسری (global) را بررسی نمی‌کند.

هرگونه فراخوانی std::move روی یک متغیر به عنوان عامل ایجاد انتقال آن متغیر در نظر گرفته می‌شود، حتی اگر نتیجهٔ std::move به یک پارامتر ارجاع rvalue ارسال نشود.

این بدان معناست که بررسی حتی روی نوعی که دارای سازندهٔ انتقال (move constructor) یا عملگر انتساب انتقال (move assignment operator) نیست نیز یک use-after-move را گزارش می‌کند. این رفتار عمدی است. توسعه‌دهندگان ممکن است با این انتظار که در آینده سمنتیک انتقال (move semantics) به این نوع اضافه خواهد شد، از std::move استفاده کنند. اگر چنین فراخوانی std::move پتانسیل ایجاد یک use-after-move را داشته باشد، می‌خواهیم دربارهٔ آن هشدار دهیم حتی اگر آن نوع هنوز سمنتیک انتقال را پیاده‌سازی نکرده باشد.

علاوه بر این، اگر نتیجهٔ std::move به یک پارامتر ارجاع rvalue پاس داده شود، این حالت همواره به عنوان انتقال در نظر گرفته می‌شود، حتی اگر تابعی که این پارامتر را دریافت می‌کند مقداری از آن منتقل نکند، یا این کار را فقط به‌صورت مشروط انجام دهد. به عنوان مثال، در شرایط زیر، بررسی فرض می‌کند که انتقال همواره رخ می‌دهد:

std::vector<std::string> messages;
void f(std::string &&str) {
  // Only remember the message if it isn't empty.
  if (!str.empty()) {
    messages.emplace_back(std::move(str));
  }
}
std::string str = "";
f(std::move(str));

بررسی فرض خواهد کرد که خط آخر باعث یک انتقال می‌شود، اگرچه در این مورد خاص، چنین اتفاقی نمی‌افتد. مجدداً، این رفتار عمدی است.

یک حالت خاص وجود دارد: فراخوانی std::move درون فراخوانی try_emplace به صورت محتاطانه انتقال‌نیافته فرض می‌شود. این کار به منظور جلوگیری از هشدارهای کاذب است، زیرا این بررسی روشی برای استنتاج مقدار bool بازگردانده‌شده توسط try_emplace ندارد.

هنگام تحلیل ترتیبی که در آن انتقال‌ها، استفاده‌ها و مقداردهی‌های مجدد رخ می‌دهند (بخش Unsequenced moves, uses, and reinitializations را ببینید)، فرض می‌شود که انتقال در همان تابعی رخ می‌دهد که نتیجهٔ std::move به آن پاس داده شده است.

این بررسی همچنین perfect-forwarding با std::forward را مدیریت می‌کند، بنابراین کد زیر نیز باعث ایجاد یک هشدار use-after-move خواهد شد.

void consume(int);
void f(int&& i) {
  consume(std::forward<int>(i));
  consume(std::forward<int>(i)); // use-after-move
}

استفاده (Use)

هرگونه رخداد متغیر منتقل‌شده که مقداردهی مجدد نباشد (زیر را ببینید) به‌عنوان یک استفاده در نظر گرفته می‌شود.

یک استثنا برای این موضوع اشیاء از نوع std::unique_ptr، std::shared_ptr، std::weak_ptr، std::optional و std::any هستند. یک استثنا برای این موضوع اشیاء از نوع std::unique_ptr، std::shared_ptr، std::weak_ptr، std::optional و std::any هستند که می‌توانند از طریق reset دوباره مقداردهی اولیه شوند. به طور خاص برای اشاره‌گرهای هوشمند، اشیاء منتقل‌شده دارای وضعیت مشخص nullptr هستند و تنها operator*، operator-> و operator[] دسترسی‌های نامعتبر در نظر گرفته می‌شوند چرا که به یک nullptr ارجاع‌زدایی خواهند کرد.

اگر چندین استفاده پس از یک انتقال رخ دهد، تنها اولین مورد پرچم‌گذاری می‌شود.

مقداردهی مجدد (Reinitialization)

این بررسی یک متغیر را در موارد زیر مقداردهی‌مجدد‌شده در نظر می‌گیرد:

اگر متغیر مورد نظر یک struct باشد و مقداری در یکی از متغیرهای عضو مجزای آن نوشته شود، این بررسی آن را مقداردهی مجدد در نظر نمی‌گیرد -- حتی اگر در نهایت، تمامی متغیرهای عضو آن struct مقداردهی شوند. به عنوان مثال:

struct S {
  std::string str;
  int i;
};
S s = { "Hello, world!\n", 42 };
S s_other = std::move(s);
s.str = "Lorem ipsum";
s.i = 99;

این بررسی s را پس از خط آخر دوباره مقداردهی‌شده در نظر نخواهد گرفت؛ در عوض، خطی که به s.str مقدار انتساب می‌دهد به عنوان یک use-after-move پرچم‌گذاری خواهد شد. این رفتار عمدی است چرا که این الگوی مقداردهی مجدد یک struct مستعد خطا است. برای مثال، اگر یک متغیر عضو اضافی به S افزوده شود، به سادگی ممکن است مقداردهی مجدد برای این عضو اضافی فراموش شود. در عوض، انتساب به کل struct در یک گام ایمن‌تر است و از اخطار use-after-move نیز جلوگیری خواهد کرد.

گزینه‌ها (Options)

bugprone-virtual-near-miss

اگر تابعی دچار خطای نزدیک به هدف باشد (یعنی نام آن بسیار شبیه و امضای تابع با یک تابع مجازی از کلاس پایه یکسان باشد)، هشدار می‌دهد.

مثال:

struct Base {
  virtual void func();
};
struct Derived : Base {
  virtual void funk();
  // warning: 'Derived::funk' has a similar name and the same signature as virtual method 'Base::func'; did you mean to override it?
};

cert-arr39-c

بررسی cert-arr39-c یک نام مستعار است، لطفاً برای اطلاعات بیشتر به bugprone-sizeof-expression <> مراجعه کنید.

cert-con36-c

بررسی cert-con36-c یک نام مستعار است، لطفاً برای اطلاعات بیشتر به bugprone-spuriously-wake-up-functions <> مراجعه کنید.

cert-con54-cpp

بررسی cert-con54-cpp یک نام مستعار است، لطفاً برای اطلاعات بیشتر به bugprone-spuriously-wake-up-functions <> مراجعه کنید.

cert-ctr56-cpp

بررسی cert-ctr56-cpp یک نام مستعار است، لطفاً برای اطلاعات بیشتر به bugprone-pointer-arithmetic-on-polymorphic-object <> مراجعه کنید.

cert-dcl03-c

بررسی cert-dcl03-c یک نام مستعار است، لطفاً برای اطلاعات بیشتر به misc-static-assert <> مراجعه کنید.

cert-dcl16-c

بررسی cert-dcl16-c یک نام مستعار است، لطفاً برای اطلاعات بیشتر به readability-uppercase-literal-suffix <> مراجعه کنید.

cert-dcl37-c

بررسی cert-dcl37-c یک نام مستعار است، لطفاً برای اطلاعات بیشتر به bugprone-reserved-identifier <> مراجعه کنید.

cert-dcl50-cpp

بررسی cert-dcl50-cpp یک نام مستعار است، لطفاً برای اطلاعات بیشتر به modernize-avoid-variadic-functions <> مراجعه کنید.

این بررسی متناظر با قاعدهٔ DCL50-CPP از استاندارد کدنویسی CERT C++ است: Do not define a C-style variadic function https://www.securecoding.cert.org/confluence/display/cplusplus/DCL50-CPP.+Do+not+define+a+C-style+variadic+function.

cert-dcl51-cpp

بررسی cert-dcl51-cpp یک نام مستعار است، لطفاً برای اطلاعات بیشتر به bugprone-reserved-identifier <> مراجعه کنید.

cert-dcl54-cpp

بررسی cert-dcl54-cpp یک نام مستعار است، لطفاً برای اطلاعات بیشتر به misc-new-delete-overloads <> مراجعه کنید.

cert-dcl58-cpp

بررسی cert-dcl58-cpp یک نام مستعار است، لطفاً برای اطلاعات بیشتر به bugprone-std-namespace-modification <> مراجعه کنید.

این بررسی متناظر با قاعدهٔ DCL58-CPP از استاندارد کدنویسی CERT C++ است: Do not modify the standard namespaces https://www.securecoding.cert.org/confluence/display/cplusplus/DCL58-CPP.+Do+not+modify+the+standard+namespaces.

cert-dcl59-cpp

بررسی cert-dcl59-cpp یک نام مستعار است، لطفاً برای اطلاعات بیشتر به misc-anonymous-namespace-in-header <> مراجعه کنید.

cert-env33-c

بررسی cert-env33-c یک نام مستعار است، لطفاً برای اطلاعات بیشتر به bugprone-command-processor <> مراجعه کنید.

این بررسی متناظر با قاعدهٔ ENV33-C از استاندارد کدنویسی CERT C است: Do not call system() <https://www.securecoding.cert.org/confluence/display/c/ENV33-C.+Do+not+call+system()>.

cert-err09-cpp

بررسی cert-err09-cpp یک نام مستعار است، لطفاً برای اطلاعات بیشتر به misc-throw-by-value-catch-by-reference <> مراجعه کنید.

این بررسی با توصیهٔ ERR09-CPP در استاندارد کدنویسی CERT C++ مطابقت دارد: Throw anonymous temporaries. با این حال، تمام توصیه‌های CERT از دید عموم حذف شده‌اند و بنابراین مشاهدهٔ توجیه آن‌ها برای رفتار این بررسی نیازمند داشتن یک حساب کاربری در ویکی آن‌ها است.

cert-err33-c

در مورد مقادیر بازگشتی استفاده‌نشدهٔ توابع هشدار می‌دهد. بسیاری از توابع کتابخانهٔ استاندارد مقداری را برمی‌گردانند که موفقیت‌آمیز بودن فراخوانی را مشخص می‌کند. نادیده گرفتن مقدار بازگشتی در صورت بروز خطا می‌تواند رفتارهای پیش‌بینی‌نشده‌ای ایجاد کند. توابع زیر بررسی می‌شوند:

این بررسی یک نام مستعار از بررسی bugprone-unused-return-value <> با مجموعه‌ای ثابت از توابع است.

نادیده‌گرفتن هشدارها با تبدیل نوع (cast) به void به طور پیش‌فرض فعال است و می‌تواند با تنظیم گزینه AllowCastToVoid روی false غیرفعال شود.

این بررسی متناظر با بخشی از قاعده ERR33-C در استاندارد کدنویسی CERT C است: «شناسایی و مدیریت خطاهای کتابخانه استاندارد» https://wiki.sei.cmu.edu/confluence/display/c/ERR33-C.+Detect+and+handle+standard+library+errors. فهرست توابع بررسی‌شده از این قاعده برگرفته شده است، به استثنای موارد زیر:

cert-err34-c

بررسی cert-err34-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-unchecked-string-to-number-conversion <> را ببینید.

cert-err52-cpp

بررسی cert-err52-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر modernize-avoid-setjmp-longjmp <> را ببینید.

این بررسی متناظر با قاعده ERR52-CPP در استاندارد کدنویسی CERT C++ است: «از setjmp() یا longjmp() استفاده نکنید» https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=1834.

cert-err58-cpp

بررسی cert-err58-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-throwing-static-initialization <> را ببینید.

این بررسی متناظر با قاعده ERR58-CPP در استاندارد کدنویسی CERT C++ است: «مدیریت تمام استثناهای پرتاب‌شده پیش از آغاز اجرای main()» https://www.securecoding.cert.org/confluence/display/cplusplus/ERR58-CPP.+Handle+all+exceptions+thrown+before+main%28%29+begins+executing.

cert-err60-cpp

بررسی cert-err60-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-exception-copy-constructor-throws <> را ببینید.

این بررسی متناظر با قاعده ERR60-CPP در استاندارد کدنویسی CERT C++ است: «اشیاء استثنا باید دارای سازنده کپی بدون پرتاب استثنا (nothrow) باشند» https://wiki.sei.cmu.edu/confluence/display/cplusplus/ERR60-CPP.+Exception+objects+must+be+nothrow+copy+constructible.

cert-err61-cpp

بررسی cert-err61-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر misc-throw-by-value-catch-by-reference <> را ببینید.

cert-exp42-c

بررسی cert-exp42-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-suspicious-memory-comparison <> را ببینید.

cert-fio38-c

بررسی cert-fio38-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر misc-non-copyable-objects <> را ببینید.

این بررسی متناظر با قاعده FIO38-C در استاندارد کدنویسی CERT C++ است: «یک شیء FILE را کپی نکنید» https://www.securecoding.cert.org/confluence/display/c/FIO38-C.+Do+not+copy+a+FILE+object.

cert-flp30-c

بررسی cert-flp30-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-float-loop-counter <> را ببینید.

این بررسی متناظر با قاعده FLP30-C در استاندارد کدنویسی CERT C است: «از متغیرهای ممیز شناور به عنوان شمارنده حلقه استفاده نکنید» https://www.securecoding.cert.org/confluence/display/c/FLP30-C.+Do+not+use+floating-point+variables+as+loop+counters.

cert-flp37-c

بررسی cert-flp37-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-suspicious-memory-comparison <> را ببینید.

cert-int09-c

بررسی cert-int09-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر readability-enum-initial-value <> را ببینید.

cert-mem57-cpp

بررسی cert-mem57-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-default-operator-new-on-overaligned-type <> را ببینید.

این بررسی متناظر با قاعده MEM57-CPP در استاندارد کدنویسی CERT C++ است: «اجتناب از استفاده از operator new پیش‌فرض برای انواع بیش‌از‌حد تراز‌شده (over-aligned)» https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types.

cert-msc24-c

بررسی cert-msc24-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-unsafe-functions <> را ببینید.

cert-msc30-c

بررسی cert-msc30-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر misc-predictable-rand <> را ببینید.

این بررسی متناظر با قاعده MSC30-C در استاندارد کدنویسی CERT C است: «برای تولید اعداد شبه‌تصادفی از تابع rand() استفاده نکنید» https://wiki.sei.cmu.edu/confluence/display/c/MSC30-C.+Do+not+use+the+rand%28%29+function+for+generating+pseudorandom+numbers.

cert-msc32-c

بررسی cert-msc32-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-random-generator-seed <> را ببینید.

این بررسی متناظر با قاعده MSC32-C در استاندارد کدنویسی CERT C است: «مولدهای اعداد شبه‌تصادفی را به درستی مقداردهی اولیه (seed) کنید» https://wiki.sei.cmu.edu/confluence/display/c/MSC32-C.+Properly+seed+pseudorandom+number+generators.

cert-msc33-c

بررسی cert-msc33-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-unsafe-functions <> را ببینید.

cert-msc50-cpp

بررسی cert-msc50-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر misc-predictable-rand <> را ببینید.

این بررسی متناظر با قاعده MSC50-CPP در استاندارد کدنویسی CERT C است: «برای تولید اعداد شبه‌تصادفی از std::rand() استفاده نکنید» https://wiki.sei.cmu.edu/confluence/display/cplusplus/MSC50-CPP.+Do+not+use+std%3A%3Arand%28%29+for+generating+pseudorandom+numbers.

cert-msc51-cpp

بررسی cert-msc51-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-random-generator-seed <> را ببینید.

این بررسی متناظر با قاعده MSC51-CPP در استاندارد کدنویسی CERT C++ است: «اطمینان حاصل کنید که مولد اعداد تصادفی شما به درستی مقداردهی اولیه (seed) شده است» https://wiki.sei.cmu.edu/confluence/display/cplusplus/MSC51-CPP.+Ensure+your+random+number+generator+is+properly+seeded.

cert-msc54-cpp

بررسی cert-msc54-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-signal-handler <> را ببینید.

cert-oop11-cpp

بررسی cert-oop11-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر performance-move-constructor-init <> را ببینید.

این بررسی با توصیه‌نامهٔ OOP11-CPP از استاندارد کدنویسی CERT C++ مطابقت دارد: «اعضا یا کلاس‌های پایه را از طریق یک سازندهٔ انتقال به‌صورت رونوشت مقداردهی اولیه نکنید» (Do not copy-initialize members or base classes from a move constructor). با این حال، تمامی توصیه‌های CERT از دید عموم حذف شده‌اند و به همین دلیل، مشاهدهٔ دلایل و توجیهات آن‌ها برای رفتار این بررسی نیازمند داشتن حساب کاربری در ویکی آن‌ها است.

cert-oop54-cpp

بررسی cert-oop54-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-unhandled-self-assignment <> را ببینید.

cert-oop57-cpp

بررسی cert-oop57-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-raw-memory-call-on-non-trivial-type <> را ببینید.

این بررسی با قاعدهٔ OOP57-CPP از استاندارد کدنویسی CERT C++ مطابقت دارد: «توابع عضو ویژه و عملگرهای بارگذاری‌شده را به توابع کتابخانهٔ استاندارد C ترجیح دهید» (Prefer special member functions and overloaded operators to C Standard Library functions) https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP57-CPP.+Prefer+special+member+functions+and+overloaded+operators+to+C+Standard+Library+functions.

cert-oop58-cpp

بررسی cert-oop58-cpp یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-copy-constructor-mutates-argument <> را ببینید.

cert-pos44-c

بررسی cert-pos44-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-bad-signal-to-kill-thread <> را ببینید.

cert-pos47-c

بررسی cert-pos47-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر concurrency-thread-canceltype-asynchronous <> را ببینید.

cert-sig30-c

بررسی cert-sig30-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-signal-handler <> را ببینید.

cert-str34-c

بررسی cert-str34-c یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر bugprone-signed-char-misuse <> را ببینید.

clang-analyzer-core.BitwiseShift

مواردی را پیدا می‌کند که در آن‌ها عملیات تغییر بیتی (bitwise shift) منجر به رفتار تعریف‌نشده (undefined behaviour) می‌شود.

بررسی clang-analyzer-core.BitwiseShift یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-bitwiseshift را ببینید.

clang-analyzer-core.CallAndMessage

خطاهای منطقی مربوط به فراخوانی‌های توابع و عبارات پیام Objective-C را بررسی می‌کند (مانند آرگومان‌های مقداردهی‌نشده، اشاره‌گرهای تابع تهی/null).

بررسی clang-analyzer-core.CallAndMessage یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-callandmessage را ببینید.

clang-analyzer-core.DivideZero

تقسیم بر صفر را بررسی می‌کند.

بررسی clang-analyzer-core.DivideZero یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-dividezero را ببینید.

clang-analyzer-core.NonNullParamChecker

اشاره‌گرهای تهی (null) پاس‌داده‌شده به‌عنوان آرگومان به تابعی که آرگومان‌های آن ارجاع هستند یا با صفت 'nonnull' علامت‌گذاری شده‌اند را بررسی می‌کند.

بررسی clang-analyzer-core.NonNullParamChecker یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-nonnullparamchecker را ببینید.

clang-analyzer-core.NullDereference

ابطال ارجاع (dereference) اشاره‌گرهای تهی (null) را بررسی می‌کند.

بررسی clang-analyzer-core.NullDereference یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-nulldereference را ببینید.

clang-analyzer-core.StackAddressEscape

بررسی می‌کند که آدرس‌های حافظهٔ پشته (stack) به بیرون از تابع نشت نکنند (escape).

بررسی clang-analyzer-core.StackAddressEscape یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-stackaddressescape را ببینید.

clang-analyzer-core.UndefinedBinaryOperatorResult

نتایج تعریف‌نشدهٔ عملگرهای باینری را بررسی می‌کند.

بررسی clang-analyzer-core.UndefinedBinaryOperatorResult یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-undefinedbinaryoperatorresult را ببینید.

clang-analyzer-core.VLASize

تعریف‌های آرایه‌های با طول متغیر (VLA) با اندازهٔ تعریف‌نشده یا صفر را بررسی می‌کند.

بررسی clang-analyzer-core.VLASize یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-vlasize را ببینید.

clang-analyzer-core.uninitialized.ArraySubscript

استفاده از مقادیر مقداردهی‌نشده به‌عنوان اندیس آرایه را بررسی می‌کند.

بررسی clang-analyzer-core.uninitialized.ArraySubscript یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-uninitialized-arraysubscript را ببینید.

clang-analyzer-core.uninitialized.Assign

انتساب مقادیر مقداردهی‌نشده را بررسی می‌کند.

بررسی clang-analyzer-core.uninitialized.Assign یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-uninitialized-assign را ببینید.

clang-analyzer-core.uninitialized.Branch

استفاده از مقادیر مقداردهی‌نشده به‌عنوان شرایط انشعاب (branch conditions) را بررسی می‌کند.

بررسی clang-analyzer-core.uninitialized.Branch یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-uninitialized-branch را ببینید.

clang-analyzer-core.uninitialized.CapturedBlockVariable

بلاک‌هایی را که مقادیر مقداردهی‌نشده را تسخیر می‌کنند (capture)، بررسی می‌کند.

بررسی clang-analyzer-core.uninitialized.CapturedBlockVariable یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-uninitialized-capturedblockvariable را ببینید.

clang-analyzer-core.uninitialized.NewArraySize

بررسی می‌کند که آیا اندازهٔ آرایه در یک عبارت []new تعریف‌نشده است یا خیر.

بررسی clang-analyzer-core.uninitialized.NewArraySize یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-uninitialized-newarraysize را ببینید.

clang-analyzer-core.uninitialized.UndefReturn

بازگرداندن مقادیر مقداردهی‌نشده به فراخواننده (caller) را بررسی می‌کند.

بررسی clang-analyzer-core.uninitialized.UndefReturn یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#core-uninitialized-undefreturn را ببینید.

clang-analyzer-cplusplus.ArrayDelete

تخریب آرایه‌هایی از اشیاء چندریختی (polymorphic) را که به عنوان کلاس پایه‌شان تخریب می‌شوند، گزارش می‌دهد.

بررسی clang-analyzer-cplusplus.ArrayDelete یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-arraydelete مراجعه کنید.

clang-analyzer-cplusplus.InnerPointer

اشاره‌گرهای داخلی دربرگیرنده‌های ++C را که پس از تخصیص مجدد یا آزادسازی حافظه (re/deallocation) استفاده شده‌اند بررسی می‌کند.

بررسی clang-analyzer-cplusplus.InnerPointer یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-innerpointer مراجعه کنید.

clang-analyzer-cplusplus.Move

باگ‌های استفاده پس از انتقال (use-after-move) را در ++C پیدا می‌کند.

بررسی clang-analyzer-cplusplus.Move یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-move مراجعه کنید.

clang-analyzer-cplusplus.NewDelete

مشکلات آزادسازی مضاعف (double-free) و استفاده پس از آزادسازی (use-after-free) را بررسی می‌کند. حافظه مدیریت‌شده توسط new/delete را ردگیری می‌کند.

بررسی clang-analyzer-cplusplus.NewDelete یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-newdelete مراجعه کنید.

clang-analyzer-cplusplus.NewDeleteLeaks

نشت‌های حافظه (memory leaks) را بررسی می‌کند. حافظه مدیریت‌شده توسط new/delete را ردگیری می‌کند.

بررسی clang-analyzer-cplusplus.NewDeleteLeaks یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-newdeleteleaks مراجعه کنید.

clang-analyzer-cplusplus.PlacementNew

بررسی می‌کند که آیا placement new پیش‌فرض به اشاره‌گرهایی با ظرفیت ذخیره‌سازی کافی مجهز شده است یا خیر.

بررسی clang-analyzer-cplusplus.PlacementNew یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-placementnew مراجعه کنید.

clang-analyzer-cplusplus.SelfAssignment

عملگرهای انتساب کپی و انتقال در ++C را برای انتساب به خود (self assignment) بررسی می‌کند.

بررسی clang-analyzer-cplusplus.SelfAssignment یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-stringchecker مراجعه کنید.

clang-analyzer-cplusplus.StringChecker

باگ‌های std::string در ++C را بررسی می‌کند.

بررسی clang-analyzer-cplusplus.StringChecker یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-stringchecker مراجعه کنید.

clang-analyzer-deadcode.DeadStores

مقادیر ذخیره‌شده در متغیرهایی را که پس از آن هرگز خوانده نمی‌شوند بررسی می‌کند.

بررسی clang-analyzer-deadcode.DeadStores یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#deadcode-deadstores مراجعه کنید.

clang-analyzer-fuchsia.HandleChecker

بررسی‌کننده‌ای که نشت‌های مربوط به هندل‌های Fuchsia را شناسایی می‌کند.

بررسی clang-analyzer-fuchsia.HandleChecker یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#fuchsia-handlechecker برای اطلاعات بیشتر مراجعه کنید.

clang-analyzer-nullability.NullPassedToNonnull

هنگامی که یک اشاره‌گر null به اشاره‌گری با نوع _Nonnull ارسال می‌شود، هشدار می‌دهد.

بررسی clang-analyzer-nullability.NullPassedToNonnull یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#nullability-nullpassedtononnull مراجعه کنید.

clang-analyzer-nullability.NullReturnedFromNonnull

هنگامی که یک اشاره‌گر null از تابعی که نوع بازگشتی آن _Nonnull است برگردانده شود، هشدار می‌دهد.

بررسی clang-analyzer-nullability.NullReturnedFromNonnull یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#nullability-nullreturnedfromnonnull مراجعه کنید.

clang-analyzer-nullability.NullableDereferenced

هنگامی که ارجاع یک اشاره‌گر nullable بازمی‌شود (dereference می‌شود)، هشدار می‌دهد.

بررسی clang-analyzer-nullability.NullableDereferenced یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#nullability-nullabledereferenced مراجعه کنید.

clang-analyzer-nullability.NullablePassedToNonnull

هنگامی که یک اشاره‌گر nullable به اشاره‌گری با نوع _Nonnull ارسال می‌شود، هشدار می‌دهد.

بررسی clang-analyzer-nullability.NullablePassedToNonnull یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#nullability-nullablepassedtononnull مراجعه کنید.

clang-analyzer-nullability.NullableReturnedFromNonnull

هنگامی که یک اشاره‌گر nullable از تابعی با نوع بازگشتی _Nonnull بازگردانده می‌شود، هشدار می‌دهد.

بررسی clang-analyzer-nullability.NullableReturnedFromNonnull یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#nullability-nullablereturnedfromnonnull مراجعه کنید.

clang-analyzer-optin.core.EnumCastOutOfRange

تبدیل‌های نوع عدد صحیح به شمارشی را برای مقادیر خارج از محدوده بررسی می‌کند.

بررسی clang-analyzer-optin.core.EnumCastOutOfRange یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-core-enumcastoutofrange مراجعه کنید.

clang-analyzer-optin.cplusplus.UninitializedObject

فیلدهای مقداردهی‌نشده پس از ساخت شیء را گزارش می‌دهد.

بررسی clang-analyzer-optin.cplusplus.UninitializedObject یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-cplusplus-uninitializedobject مراجعه کنید.

clang-analyzer-optin.cplusplus.VirtualCall

فراخوانی توابع مجازی در طول ساخت/تخریب شیء را بررسی می‌کند.

بررسی clang-analyzer-optin.cplusplus.VirtualCall یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-cplusplus-virtualcall مراجعه کنید.

clang-analyzer-optin.mpi.MPI-Checker

کدهای MPI را بررسی می‌کند.

بررسی clang-analyzer-optin.mpi.MPI-Checker یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-mpi-mpi-checker مراجعه کنید.

clang-analyzer-optin.osx.cocoa.localizability.EmptyLocalizationContextChecker

بررسی می‌کند که آیا ماکروهای NSLocalizedString شامل یک کامنت برای بافتار (context) هستند یا خیر.

بررسی clang-analyzer-optin.osx.cocoa.localizability.EmptyLocalizationContextChecker یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-osx-cocoa-localizability-emptylocalizationcontextchecker مراجعه کنید.

clang-analyzer-optin.osx.cocoa.localizability.NonLocalizedStringChecker

در مورد استفاده از NSStringهای محلی‌سازی‌نشده که به متدهای رابط کاربری نیازمند NSStringهای محلی‌سازی‌شده ارسال می‌شوند، هشدار می‌دهد.

بررسی clang-analyzer-optin.osx.cocoa.localizability.NonLocalizedStringChecker یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-osx-cocoa-localizability-nonlocalizedstringchecker مراجعه کنید.

clang-analyzer-optin.performance.GCDAntipattern

بررسی ضدالگوهای (anti-patterns) کارایی هنگام استفاده از Grand Central Dispatch.

بررسی clang-analyzer-optin.performance.GCDAntipattern یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-performance-gcdantipattern را ببینید.

clang-analyzer-optin.performance.Padding

بررسی structهایی که دارای لایه‌گذاری (padding) بیش از حد هستند.

بررسی clang-analyzer-optin.performance.Padding یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-performance-padding را ببینید.

clang-analyzer-optin.portability.UnixAPI

یافتن رفتارهای وابسته به پیاده‌سازی (implementation-defined) در توابع UNIX/Posix.

بررسی clang-analyzer-optin.portability.UnixAPI یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-portability-unixapi را ببینید.

clang-analyzer-optin.taint.TaintedAlloc

بررسی تخصیص‌های حافظه‌ای که ممکن است پارامتر اندازهٔ آن‌ها یک مقدار آلوده (کنترل‌شده توسط مهاجم) باشد.

بررسی clang-analyzer-optin.taint.TaintedAlloc یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#optin-taint-taintedalloc را ببینید.

clang-analyzer-osx.API

بررسی استفادهٔ صحیح از رابط‌های برنامه‌نویسی مختلف Apple.

بررسی clang-analyzer-osx.API یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-api را ببینید.

clang-analyzer-osx.NumberObjectConversion

بررسی تبدیل‌های نادرست شیءهای نمایش‌دهندهٔ اعداد به عددها.

بررسی clang-analyzer-osx.NumberObjectConversion یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-numberobjectconversion را ببینید.

clang-analyzer-osx.ObjCProperty

بررسی استفادهٔ مناسب از ویژگی‌های Objective-C.

بررسی clang-analyzer-osx.ObjCProperty یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-objcproperty را ببینید.

clang-analyzer-osx.SecKeychainAPI

بررسی استفادهٔ صحیح از APIهای Secure Keychain.

بررسی clang-analyzer-osx.SecKeychainAPI یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-seckeychainapi را ببینید.

clang-analyzer-osx.cocoa.AtSync

بررسی اشاره‌گرهای nil که به عنوان mutex برای @synchronized استفاده شده‌اند.

بررسی clang-analyzer-osx.cocoa.AtSync یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-atsync را ببینید.

clang-analyzer-osx.cocoa.AutoreleaseWrite

هشدار در مورد عملیات نوشتن بالقوه منجر به فروپاشی (crash) روی اشیاء autoreleasing از poolهای آزادسازی خودکار مختلف در Objective-C.

بررسی clang-analyzer-osx.cocoa.AutoreleaseWrite یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-autoreleasewrite را ببینید.

clang-analyzer-osx.cocoa.ClassRelease

بررسی ارسال مستقیم 'retain'، 'release'، یا 'autorelease' به یک Class.

بررسی clang-analyzer-osx.cocoa.ClassRelease یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-classrelease را ببینید.

clang-analyzer-osx.cocoa.Dealloc

هشدار دربارهٔ کلاس‌های Objective-C که فاقد پیاده‌سازی صحیح -dealloc هستند.

بررسی clang-analyzer-osx.cocoa.Dealloc یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-dealloc را ببینید.

clang-analyzer-osx.cocoa.IncompatibleMethodTypes

هشدار در مورد امضای متدهای Objective-C با ناسازگاری‌های نوع (type incompatibilities).

بررسی clang-analyzer-osx.cocoa.IncompatibleMethodTypes یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-incompatiblemethodtypes را ببینید.

clang-analyzer-osx.cocoa.Loops

مدل‌سازی بهبودیافته از حلقه‌ها با استفاده از انواع مجموعه‌های Cocoa.

بررسی clang-analyzer-osx.cocoa.Loops یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-loops را ببینید.

clang-analyzer-osx.cocoa.MissingSuperCall

هشدار دربارهٔ متدهای Objective-C که فاقد فراخوانی لازم به super هستند.

بررسی clang-analyzer-osx.cocoa.MissingSuperCall یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-missingsupercall را ببینید.

clang-analyzer-osx.cocoa.NSAutoreleasePool

هشدار در مورد استفاده‌های غیربهینه از NSAutoreleasePool در حالت GC زبان Objective-C.

بررسی clang-analyzer-osx.cocoa.NSAutoreleasePool یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-nsautoreleasepool را ببینید.

clang-analyzer-osx.cocoa.NSError

بررسی نحوهٔ استفاده از پارامترهای **NSError.

بررسی clang-analyzer-osx.cocoa.NSError یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-nserror را ببینید.

clang-analyzer-osx.cocoa.NilArg

بررسی آرگومان‌های غیرمجاز nil در فراخوانی متدهای ObjC.

بررسی clang-analyzer-osx.cocoa.NilArg یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-nilarg را ببینید.

clang-analyzer-osx.cocoa.NonNilReturnValue

مدل‌سازی APIهایی که تضمین می‌کنند مقداری غیر از nil برمی‌گردانند.

بررسی clang-analyzer-osx.cocoa.NonNilReturnValue یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-nonnilreturnvalue را ببینید.

clang-analyzer-osx.cocoa.ObjCGenerics

بررسی خطاهای نوع هنگام استفاده از جنریک‌های Objective-C.

بررسی clang-analyzer-osx.cocoa.ObjCGenerics یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-objcgenerics را ببینید.

clang-analyzer-osx.cocoa.RetainCount

بررسی نشت‌ها و مدیریت نادرست شمارندهٔ ارجاع (reference count).

بررسی clang-analyzer-osx.cocoa.RetainCount یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-retaincount را ببینید.

clang-analyzer-osx.cocoa.RunLoopAutoreleaseLeak

بررسی حافظهٔ نشت‌یافته در autorelease poolهایی که هرگز تخلیه نمی‌شوند.

بررسی clang-analyzer-osx.cocoa.RunLoopAutoreleaseLeak یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر بخش Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-runloopautoreleaseleak را ببینید.

clang-analyzer-osx.cocoa.SelfInit

بررسی می‌کند که 'self' درون یک متد مقداردهی اولیه (initializer) به‌درستی مقداردهی شده باشد.

بررسی clang-analyzer-osx.cocoa.SelfInit یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-selfinit مراجعه کنید.

clang-analyzer-osx.cocoa.SuperDealloc

درباره استفاده نادرست از '[super dealloc]' در Objective-C هشدار می‌دهد.

بررسی clang-analyzer-osx.cocoa.SuperDealloc یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-superdealloc مراجعه کنید.

clang-analyzer-osx.cocoa.UnusedIvars

درباره ivarهای خصوصی که هرگز استفاده نشده‌اند هشدار می‌دهد.

بررسی clang-analyzer-osx.cocoa.UnusedIvars یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-unusedivars مراجعه کنید.

clang-analyzer-osx.cocoa.VariadicMethodTypes

ارسال انواع غیر Objective-C به متدهای مقداردهی اولیه مجموعه‌های متغیر (variadic) را که فقط انتظار انواع Objective-C دارند، بررسی می‌کند.

بررسی clang-analyzer-osx.cocoa.VariadicMethodTypes یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-cocoa-variadicmethodtypes مراجعه کنید.

clang-analyzer-osx.coreFoundation.CFError

استفاده از پارامترهای *CFErrorRef را بررسی می‌کند.

بررسی clang-analyzer-osx.coreFoundation.CFError یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-corefoundation-cferror مراجعه کنید.

clang-analyzer-osx.coreFoundation.CFNumber

استفاده صحیح از APIهای CFNumber را بررسی می‌کند.

بررسی clang-analyzer-osx.coreFoundation.CFNumber یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-corefoundation-cfnumber مراجعه کنید.

clang-analyzer-osx.coreFoundation.CFRetainRelease

آرگومان‌های تهی (null) به CFRetain/CFRelease/CFMakeCollectable را بررسی می‌کند.

بررسی clang-analyzer-osx.coreFoundation.CFRetainRelease یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-corefoundation-cfretainrelease مراجعه کنید.

clang-analyzer-osx.coreFoundation.containers.OutOfBounds

خارج از محدوده بودن اندیس را هنگام استفاده از API مربوط به 'CFArray' بررسی می‌کند.

بررسی clang-analyzer-osx.coreFoundation.containers.OutOfBounds یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-corefoundation-containers-outofbounds مراجعه کنید.

clang-analyzer-osx.coreFoundation.containers.PointerSizedValues

اگر 'CFArray'، 'CFDictionary' یا 'CFSet' با مقادیری با اندازه‌ای غیر از اندازه اشاره‌گر ساخته شوند، هشدار می‌دهد.

بررسی clang-analyzer-osx.coreFoundation.containers.PointerSizedValues یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#osx-corefoundation-containers-pointersizedvalues مراجعه کنید.

clang-analyzer-security.FloatLoopCounter

در مورد استفاده از یک مقدار ممیز شناور به عنوان شمارنده حلقه هشدار می‌دهد (CERT: FLP30-C, FLP30-CPP).

بررسی clang-analyzer-security.FloatLoopCounter یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-floatloopcounter مراجعه کنید.

clang-analyzer-security.PutenvStackArray

فراخوانی‌های تابع putenv را پیدا می‌کند که اشاره‌گری به یک آرایه تخصیص‌یافته روی پشته (خودکار/اتوماتیک) را به عنوان آرگومان ارسال می‌کنند. تابع putenv رشته ارسالی را کپی نمی‌کند، بلکه تنها یک اشاره‌گر به داده ذخیره می‌شود و این داده حتی توسط ریسه‌های دیگر نیز قابل خواندن است. محتوای یک آرایه تخصیص‌یافته روی پشته به احتمال زیاد پس از خروج از تابع رونویسی می‌شود.

بررسی clang-analyzer-security.PutenvStackArray یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-putenvstackarray-c مراجعه کنید.

clang-analyzer-security.SetgidSetuidOrder

این بررسی‌کننده توالی‌های فراخوانی‌های setuid(getuid()) و setgid(getgid()) را (به همین ترتیب) بررسی می‌کند. اگر چنین توالی‌ای یافت شود و هیچ فراخوانی تابع تغییردهنده مجوز دیگری (seteuid، setreuid، setresuid و نسخه‌های GID آن‌ها) در این بین نباشد، یک هشدار صادر می‌شود. این بررسی‌کننده فقط فراخوانی‌های دقیقاً setuid(getuid()) (و نسخه‌های GID) را می‌یابد، نه مثلاً مواردی که نتیجه getuid() در یک متغیر ذخیره شده باشد.

بررسی clang-analyzer-security.SetgidSetuidOrder یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-setgidsetuidorder-c مراجعه کنید.

clang-analyzer-security.cert.env.InvalidPtr

استفاده از اشاره‌گرهای احتمالاً باطل‌شده را می‌یابد.

بررسی clang-analyzer-security.cert.env.InvalidPtr یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-cert-env-invalidptr مراجعه کنید.

clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling

در مورد استفاده از توابع ناامن یا منسوخ‌شده دستکاری بافر هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-deprecatedorunsafebufferhandling مراجعه کنید.

clang-analyzer-security.insecureAPI.UncheckedReturn

در مورد استفاده از توابعی که مقادیر بازگشتی آن‌ها همیشه باید بررسی شوند، هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.UncheckedReturn یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-uncheckedreturn مراجعه کنید.

clang-analyzer-security.insecureAPI.bcmp

در مورد استفاده از تابع 'bcmp' هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.bcmp یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-bcmp مراجعه کنید.

clang-analyzer-security.insecureAPI.bcopy

در مورد استفاده از تابع 'bcopy' هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.bcopy یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-bcopy مراجعه کنید..SS clang-analyzer-security.insecureAPI.bzero

درباره استفاده از تابع 'bzero' هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.bzero یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-bzero مراجعه کنید.

clang-analyzer-security.insecureAPI.decodeValueOfObjCType

درباره استفاده از متد '-decodeValueOfObjCType:at:' هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.decodeValueOfObjCType یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer security.insecureAPI.decodeValueOfObjCType https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-decodevalueofobjctype مراجعه کنید.

clang-analyzer-security.insecureAPI.getpw

درباره استفاده از تابع 'getpw' هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.getpw یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-getpw مراجعه کنید.

clang-analyzer-security.insecureAPI.gets

درباره استفاده از تابع 'gets' هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.gets یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-gets مراجعه کنید.

clang-analyzer-security.insecureAPI.mkstemp

هنگامی که کمتر از ۶ نویسه X در رشته قالب‌بندی به 'mkstemp' ارسال شود، هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.mkstemp یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-mkstemp مراجعه کنید.

clang-analyzer-security.insecureAPI.mktemp

درباره استفاده از تابع 'mktemp' هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.mktemp یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-mktemp مراجعه کنید.

clang-analyzer-security.insecureAPI.rand

درباره استفاده از توابع 'rand'، 'random' و توابع مرتبط هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.rand یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-rand مراجعه کنید.

clang-analyzer-security.insecureAPI.strcpy

درباره استفاده از توابع 'strcpy' و 'strcat' هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.strcpy یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-strcpy مراجعه کنید.

clang-analyzer-security.insecureAPI.vfork

درباره استفاده از تابع 'vfork' هشدار می‌دهد.

بررسی clang-analyzer-security.insecureAPI.vfork یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#security-insecureapi-vfork مراجعه کنید.

clang-analyzer-unix.API

فراخوانی توابع مختلف UNIX/Posix را بررسی می‌کند.

بررسی clang-analyzer-unix.API یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-api مراجعه کنید.

clang-analyzer-unix.BlockInCriticalSection

فراخوانی توابع مسدودکننده (blocking) در داخل بخش بحرانی (critical section) را بررسی می‌کند.

بررسی clang-analyzer-unix.BlockInCriticalSection یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-blockincriticalsection مراجعه کنید.

clang-analyzer-unix.Errno

استفاده نادرست از 'errno' را بررسی می‌کند.

بررسی clang-analyzer-unix.Errno یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-errno مراجعه کنید.

clang-analyzer-unix.Malloc

نشتی حافظه (memory leaks)، آزادسازی دوباره (double free) و مشکلات استفاده پس از آزادسازی (use-after-free) را بررسی می‌کند. حافظه مدیریت‌شده توسط malloc()/free() را ردیابی می‌کند.

بررسی clang-analyzer-unix.Malloc یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-malloc مراجعه کنید.

clang-analyzer-unix.MallocSizeof

آرگومان‌های مشکوک malloc شامل sizeof را بررسی می‌کند.

بررسی clang-analyzer-unix.MallocSizeof یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-mallocsizeof مراجعه کنید.

clang-analyzer-unix.MismatchedDeallocator

عدم تطابق توابع تخصیص‌زدا (deallocators) را بررسی می‌کند.

بررسی clang-analyzer-unix.MismatchedDeallocator یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-mismatcheddeallocator مراجعه کنید.

clang-analyzer-unix.StdCLibraryFunctions

آرگومان‌های نامعتبر توابع کتابخانه استاندارد C را بررسی کرده و روابط میان آرگومان‌ها و مقدار بازگشتی را اعمال می‌کند.

بررسی clang-analyzer-unix.StdCLibraryFunctions یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-stdclibraryfunctions مراجعه کنید.

clang-analyzer-unix.Stream

توابع مدیریت جریان (stream) را بررسی می‌کند.

بررسی clang-analyzer-unix.Stream یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-stream مراجعه کنید.

clang-analyzer-unix.Vfork

استفاده صحیح از vfork را بررسی می‌کند.

بررسی clang-analyzer-unix.Vfork یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-vfork مراجعه کنید.

clang-analyzer-unix.cstring.BadSizeArg

آرگومان اندازه پاس داده شده به توابع رشته‌ای C را برای الگوهای خطای رایج بررسی می‌کند.

بررسی clang-analyzer-unix.cstring.BadSizeArg یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-cstring-badsizearg مراجعه کنید.

clang-analyzer-unix.cstring.NullArg

پاس داده شدن اشاره‌گرهای تهی (null) به عنوان آرگومان به توابع رشته‌ای C را بررسی می‌کند.

بررسی clang-analyzer-unix.cstring.NullArg یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#unix-cstring-nullarg مراجعه کنید.

clang-analyzer-webkit.NoUncountedMemberChecker

عدم وجود متغیرهای عضو شمارش‌نشده (uncounted) را بررسی می‌کند.

بررسی clang-analyzer-webkit.NoUncountedMemberChecker یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#webkit-nouncountedmemberchecker مراجعه کنید.

clang-analyzer-webkit.RefCntblBaseVirtualDtor

بررسی می‌کند که آیا هر کلاس پایه‌ای با قابلیت شمارش ارجاع (ref-countable) دارای مخرب مجازی (virtual destructor) است یا خیر.

بررسی clang-analyzer-webkit.RefCntblBaseVirtualDtor یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#webkit-refcntblbasevirtualdtor مراجعه کنید.

clang-analyzer-webkit.UncountedLambdaCapturesChecker

گرفتن‌های (captures) شمارش‌نشده در عبارات لامبدا را بررسی می‌کند.

بررسی clang-analyzer-webkit.UncountedLambdaCapturesChecker یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به Clang Static Analyzer Available Checkers https://clang.llvm.org/docs/analyzer/checkers.html#webkit-uncountedlambdacaptureschecker مراجعه کنید.

concurrency-mt-unsafe

برخی از توابع ناامن از نظر ریسه‌بندی (thread-unsafe) را در برابر یک لیست سیاه از توابع شناخته‌شده به ناامنی بررسی می‌کند. معمولاً این توابع بدون همگام‌سازی به متغیرهای ایستا دسترسی پیدا می‌کنند (مانند gmtime(3)) یا از سیگنال‌ها به شکلی همراه با شرایط رقابتی (racy) استفاده می‌نمایند. مجموعه توابعی که باید بررسی شوند با گزینه FunctionSet مشخص می‌شود.

توجه داشته باشید که استفاده از برخی توابع thread-unsafe ممکن است در برنامه‌نویسی همروند در صورتی که تنها از یک ریسه استفاده شود همچنان معتبر باشد (مانند setenv(3))؛ با این حال، برخی از توابع ممکن است حالتی را در متغیرهای سراسری ردیابی کنند که با فراخوانی‌های بعدی (غیرموازی، اما همروند) به یک تابع مرتبط تخریب می‌شود. به عنوان مثال، کد زیر از دسترسی‌های محافظت‌نشده به یک وضعیت سراسری رنج می‌برد:

// getnetent(3) maintains global state with DB connection, etc.
// If a concurrent green thread calls getnetent(3), the global state is corrupted.
netent = getnetent();
yield();
netent = getnetent();

مثال‌ها:

tm = gmtime(timep); // uses a global buffer
sleep(1); // implementation may use SIGALRM

گزینه‌ها

concurrency-thread-canceltype-asynchronous

فراخوانی‌های تابع pthread_setcanceltype را که در آن‌ها نوع لغو ریسه روی ناهمگام (asynchronous) تنظیم شده است، پیدا می‌کند. نوع لغو ناهمگام (PTHREAD_CANCEL_ASYNCHRONOUS) به طور کلی ناامن است؛ به جای آن از نوع PTHREAD_CANCEL_DEFERRED که حالت پیش‌فرض است استفاده کنید. حتی با لغو به تعویق افتاده (deferred)، یک نقطه لغو در یک مدیر سیگنال ناهمگام ممکن است همچنان اعمال شود و اثر آن به گونه‌ای خواهد بود که گویی یک لغو ناهمگام بوده است.

pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);

این بررسی با قاعده استاندارد کدنویسی CERT C مطابقت دارد: POS47-C. Do not use threads that can be canceled asynchronously https://wiki.sei.cmu.edu/confluence/display/c/POS47-C.+Do+not+use+threads+that+can+be+canceled+asynchronously.

بررسی cert-pos47-c به عنوان نام مستعار این بررسی به اینجا هدایت می‌شود.

cppcoreguidelines-avoid-c-arrays

بررسی cppcoreguidelines-avoid-c-arrays یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به modernize-avoid-c-arrays <> مراجعه کنید.

cppcoreguidelines-avoid-capturing-lambda-coroutines

لامبداهای کوروتین C++20 با لیست‌های ضبط غیرخالی را که ممکن است باعث خطاهای use-after-free شوند نشانه‌گذاری می‌کند و پیشنهاد می‌کند از گرفتن مقادیر خودداری شود یا اطمینان حاصل شود که شیء بستار (closure) لامبدا دارای طول عمر تضمین‌شده است.

این بررسی قاعده CP.51 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rcoro-capture از C++ Core Guidelines را پیاده‌سازی می‌کند.

استفاده از لامبداهای کوروتین با لیست‌های گرفتن (capture lists) غیرخالی می‌تواند پرخطر باشد، زیرا گرفتن متغیرها می‌تواند منجر به دسترسی به حافظه آزاد شده پس از اولین نقطه تعلیق (suspension point) شود. این مشکل حتی ممکن است با اشاره‌گرهای هوشمند شمارش ارجاع‌شده (refcounted) و انواع قابل کپی نیز رخ دهد. هنگامی که یک عبارت لامبدا یک کوروتین ایجاد می‌کند، منجر به ایجاد یک شیء closure با فضای ذخیره‌سازی می‌شود که اغلب روی پشته قرار دارد و در نهایت از محدوده (scope) خارج می‌شود. هنگامی که شیء closure از محدوده خارج می‌شود، مقادیر ضبط‌شده آن نیز از محدوده خارج می‌شوند. در حالی که لامبداهای معمولی قبل از وقوع این امر اجرای خود را به پایان می‌رسانند، لامبداهای کوروتین ممکن است پس از تخریب شیء closure از حالت تعلیق از سر گرفته شوند که این امر منجر به دسترسی به حافظه use-after-free برای تمام مقادیر ضبط‌شده می‌شود.

مثال زیر را در نظر بگیرید:

int value = get_value();
std::shared_ptr<Foo> sharedFoo = get_foo();
{
    const auto lambda = [value, sharedFoo]() -> std::future<void>
    {
        co_await something();
        // "sharedFoo" and "value" have already been destroyed
        // the "shared" pointer didn't accomplish anything
    };
    lambda();
} // the lambda closure object has now gone out of scope

در این مثال، شیء لامبدا با دو مورد ضبط تعریف شده است: value و sharedFoo. هنگامی که lambda() فراخوانی می‌شود، شیء لامبدا روی پشته ایجاد می‌شود و مقادیر ضبط‌شده در شیء closure کپی می‌شوند. هنگامی که کوروتین معلق می‌شود، شیء لامبدا از محدوده خارج شده و شیء closure تخریب می‌شود. هنگامی که کوروتین از سر گرفته می‌شود، متغیرهای ضبط‌شده ممکن است تخریب شده باشند که منجر به باگ‌های use-after-free می‌شود.

در نتیجه، استفاده از لامبداهای کوروتین با لیست‌های ضبط غیرخالی می‌تواند هنگام ازسرگیری کوروتین پس از تخریب شیء closure منجر به خطاهای use-after-free شود. این بررسی با نشانه‌گذاری لامبداهای کوروتین C++20 با لیست‌های ضبط غیرخالی و پیشنهاد اجتناب از captures یا تضمین طول عمر معتبر شیء closure لامبدا، به جلوگیری از چنین خطاهایی کمک می‌کند.

پیروی از این دستورالعمل‌ها می‌تواند به تضمین استفاده ایمن و قابل اعتماد از لامبداهای کوروتین در کدهای C++ کمک کند.

cppcoreguidelines-avoid-const-or-ref-data-members

این بررسی زمانی هشدار می‌دهد که ساختارها یا کلاس‌هایی که قابلیت کپی یا انتقال دارند، دارای اعضای داده‌ای واجد شرایط const یا ارجاعی (lvalue یا rvalue) باشند. داشتن چنین اعضایی به ندرت مفید است و باعث می‌شود کلاس تنها قابلیت ساخت با کپی (copy-constructible) داشته باشد اما قابلیت انتساب با کپی (copy-assignable) را از دست بدهد.

مثال‌ها:

// Bad, const-qualified member
struct Const {
  const int x;
}
// Good:
class Foo {
 public:
  int get() const { return x; }
 private:
  int x;
};
// Bad, lvalue reference member
struct Ref {
  int& x;
};
// Good:
struct Foo {
  int* x;
  std::unique_ptr<int> x;
  std::shared_ptr<int> x;
  gsl::not_null<int*> x;
};
// Bad, rvalue reference member
struct RefRef {
  int&& x;
};

این بررسی بند C.12 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rc-constref از C++ Core Guidelines را پیاده‌سازی می‌کند.

مطالعه بیشتر: Data members: Never const https://quuxplusone.github.io/blog/2022/01/23/dont-const-all-the-things/#data-members-never-const.

cppcoreguidelines-avoid-do-while

هنگام استفاده از حلقه‌های do-while هشدار می‌دهد. خوانایی آن‌ها نسبت به حلقه‌های سادهٔ while کمتر است، زیرا شرط پایان در انتها قرار دارد و شرط پیش از اولین تکرار حلقه بررسی نمی‌شود. این مسئله می‌تواند منجر به باگ‌های نامحسوس شود.

این بررسی بند ES.75 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#res-do از C++ Core Guidelines را پیاده‌سازی می‌کند.

مثال‌ها:

int x;
do {
    std::cin >> x;
    // ...
} while (x < 0);

گزینه‌ها

#define FOO_BAR(x) \
do { \
  foo(x); \
  bar(x); \
} while(0)

cppcoreguidelines-avoid-goto

استفاده از goto برای کنترل جریان خطا‌پذیر است و باید با ساختارهای تکرار حلقه جایگزین شود. تنها پرش‌های روبه‌جلو در حلقه‌های تو‌در‌تو مجاز هستند.

این بررسی بند ES.76 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es76-avoid-goto از C++ Core Guidelines و بند 6.3.1 https://www.perforce.com/resources/qac/high-integrity-cpp-coding-standard/statements از High Integrity C++ Coding Standard را پیاده‌سازی می‌کند.

برای اطلاعات بیشتر در مورد چرایی پرهیز از برنامه‌نویسی با goto می‌توانید مقالهٔ مشهور A Case against the GO TO Statement را مطالعه کنید: https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF.

این بررسی goto را برای پرش‌های روبه‌عقب در تمامی حالت‌های زبان عیب‌یابی می‌کند. این موارد باید با ساختارهای تکرار حلقه در C/C++ جایگزین شوند.

// Bad, handwritten for loop.
int i = 0;
// Jump label for the loop
loop_start:
do_some_operation();
if (i < 100) {
  ++i;
  goto loop_start;
}
// Better
for(int i = 0; i < 100; ++i)
  do_some_operation();

زبان C++ مدرن فقط برای پرش به بیرون از حلقه‌های تودرتو به goto نیاز دارد.

for(int i = 0; i < 100; ++i) {
  for(int j = 0; j < 100; ++j) {
    if (i * j > 500)
      goto early_exit;
  }
}
early_exit:
some_operation();

سایر کاربردهای goto در C++ عیب‌یابی می‌شوند.

گزینه‌ها

cppcoreguidelines-avoid-magic-numbers

بررسی cppcoreguidelines-avoid-magic-numbers یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به readability-magic-numbers <> مراجعه کنید.

cppcoreguidelines-avoid-non-const-global-variables

متغیرهای سراسری غیر-const را همان‌طور که در بند I.2 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#i2-avoid-non-const-global-variables از C++ Core Guidelines توصیف شده است پیدا می‌کند. از آنجا که قاعده R.6 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rr-global از C++ Core Guidelines تکرار قاعده I.2 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#i2-avoid-non-const-global-variables است، این بررسی آن قاعده را نیز پوشش می‌دهد.

char a;  // Warns!
const char b =  0;
namespace some_namespace
{
    char c;  // Warns!
    const char d = 0;
}
char * c_ptr1 = &some_namespace::c;  // Warns!
char *const c_const_ptr = &some_namespace::c;  // Warns!
char & c_reference = some_namespace::c;  // Warns!
class Foo  // No Warnings inside Foo, only namespace scope is covered
{
public:
    char e = 0;
    const char f = 0;
protected:
    char g = 0;
private:
    char h = 0;
};

متغیرهای a، c، c_ptr1، c_const_ptr و c_reference همگی هشدار ایجاد خواهند کرد، زیرا یا یک متغیر غیر-const با دسترسی سراسری هستند، یا اشاره‌گر یا ارجاعی هستند که دسترسی سراسری به داده‌های غیر-const را فراهم می‌کنند، و یا هر دو.

گزینه‌ها

cppcoreguidelines-avoid-reference-coroutine-parameters

زمانی که یک کوروتین (coroutine) پارامترهای ارجاعی می‌پذیرد هشدار می‌دهد. پس از نقطه تعلیق (suspend point) کوروتین، ارجاع‌ها ممکن است معلق (dangling) شده و دیگر معتبر نباشند. در عوض، پارامترها را به صورت مقداری (by value) ارسال کنید.

مثال‌ها:

std::future<int> someCoroutine(int& val) {
  co_await ...;
  // When the coroutine is resumed, 'val' might no longer be valid.
  if (val) ...
}

این بررسی قاعده CP.53 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rcoro-reference-parameters از C++ Core Guidelines را پیاده‌سازی می‌کند.

cppcoreguidelines-c-copy-assignment-signature

بررسی cppcoreguidelines-c-copy-assignment-signature یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به misc-unconventional-assign-operator <> مراجعه کنید.

cppcoreguidelines-explicit-virtual-functions

بررسی cppcoreguidelines-explicit-virtual-functions یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به modernize-use-override <> مراجعه کنید.

cppcoreguidelines-init-variables

بررسی می‌کند که آیا متغیرهای محلی وجود دارند که بدون مقدار اولیه اعلان شده باشند. در صورتی که مسیر کدی وجود داشته باشد که متغیر را قبل از مقداردهی بخواند، این امر ممکن است منجر به رفتار غیرمنتظره شود.

این قاعده بخشی از نمایه ایمنی نوع (Type.5) https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#pro-type-init و ES.20 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#res-always از C++ Core Guidelines است.

تنها اعداد صحیح، بولی‌ها، اعشاری‌های float و double و اشاره‌گرها بررسی می‌شوند. گزینه اصلاح (fix) تمام مقادیر شناسایی‌شده را با مقدار صفر مقداردهی اولیه می‌کند. یک استثنا انواع float و double هستند که با NaN مقداردهی اولیه می‌شوند.

به عنوان مثال تابعی که به این صورت است:

void function() {
  int x;
  char *txt;
  double d;
  // Rest of the function.
}

به این صورت بازنویسی می‌شود:

#include <math.h>
void function() {
  int x = 0;
  char *txt = nullptr;
  double d = NAN;
  // Rest of the function.
}

برای حالت enum مقداردهی‌نشده هشدار می‌دهد، اما بدون FixIt:

enum A {A1, A2, A3};
enum A_c : char { A_c1, A_c2, A_c3 };
enum class B { B1, B2, B3 };
enum class B_i : int { B_i1, B_i2, B_i3 };
void function() {
  A a;     // Warning: variable 'a' is not initialized
  A_c a_c; // Warning: variable 'a_c' is not initialized
  B b;     // Warning: variable 'b' is not initialized
  B_i b_i; // Warning: variable 'b_i' is not initialized
}

گزینه‌ها

cppcoreguidelines-interfaces-global-init

این بررسی مقداردهنده‌های متغیرهای سراسری (globals) را که به اشیای extern دسترسی دارند پرچم‌گذاری می‌کند، چرا که این موضوع می‌تواند به مشکل در ترتیب مقداردهی اولیه (order-of-initialization) منجر شود.

این بررسی بخش I.22 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#ri-global-init از C++ Core Guidelines را پیاده‌سازی می‌کند.

توجه داشته باشید که در حال حاضر این بررسی، فراخوانی‌های توابع غیر constexpr را پرچم‌گذاری نمی‌کند، بنابراین متغیرهای سراسری همچنان ممکن است از درون خود توابع قابل دسترسی باشند.

cppcoreguidelines-macro-to-enum

بررسی cppcoreguidelines-macro-to-enum یک نام مستعار (alias) است، لطفاً برای اطلاعات بیشتر modernize-macro-to-enum <> را ببینید.

cppcoreguidelines-macro-usage

موارد استفاده از ماکروها را که به دلیل وجود ساختارهای زبانی بهتر برای انجام آن کار مشکل‌ساز تلقی می‌شوند، پیدا می‌کند.

بخش‌های مربوطه در C++ Core Guidelines عبارتند از ES.31 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es31-dont-use-macros-for-constants-or-functions و ES.32 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es32-use-all_caps-for-all-macro-names.

مثال‌ها:

#define C 0
#define F1(x, y) ((a) > (b) ? (a) : (b))
#define F2(...) (__VA_ARGS__)
#define F3(x, y) x##y
#define COMMA ,
#define NORETURN [[noreturn]]
#define DEPRECATED attribute((deprecated))
#if LIB_EXPORTS
#define DLLEXPORTS __declspec(dllexport)
#else
#define DLLEXPORTS __declspec(dllimport)
#endif

به هشدارهای زیر منجر می‌شود:

4 warnings generated.
test.cpp:1:9: warning: macro 'C' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
#define C 0
        ^
test.cpp:2:9: warning: function-like macro 'F1' used; consider a 'constexpr' template function [cppcoreguidelines-macro-usage]
#define F1(x, y) ((a) > (b) ? (a) : (b))
        ^
test.cpp:3:9: warning: variadic macro 'F2' used; consider using a 'constexpr' variadic template function [cppcoreguidelines-macro-usage]
#define F2(...) (__VA_ARGS__)
        ^

گزینه‌ها

cppcoreguidelines-misleading-capture-default-by-value

زمانی که یک لامبدا پیش‌فرض دریافت با مقدار (by-value) را مشخص کرده و this را ضبط می‌کند، هشدار می‌دهد.

دریافت‌های پیش‌فرض با مقدار در توابع عضو می‌تواند درباره اینکه آیا اعضای داده‌ای با مقدار یا با ارجاع دریافت شده‌اند گمراه‌کننده باشد. این امر به این دلیل رخ می‌دهد که مشخص کردن دریافت پیش‌فرض با مقدار [=] در عمل اشاره‌گر this را با مقدار دریافت می‌کند، نه خود اعضای داده‌ای را. در نتیجه، اعضای داده‌ای همچنان به‌طور غیرمستقیم از طریق اشاره‌گر دریافت‌شدهٔ this در دسترس قرار می‌گیرند، که اساساً به این معنی است که با ارجاع مورد دسترسی قرار گرفته‌اند. بنابراین، حتی هنگام استفاده از [=]، اعضای داده‌ای عملاً با ارجاع ضبط می‌شوند، که ممکن است با انتظارات کاربر همخوانی نداشته باشد.

مثال‌ها:

struct AClass {
  int member;
  void misleadingLogic() {
    int local = 0;
    member = 0;
    auto f = [=]() mutable {
      local += 1;
      member += 1;
    };
    f();
    // Here, local is 0 but member is 1
  }
  void clearLogic() {
    int local = 0;
    member = 0;
    auto f = [this, local]() mutable {
      local += 1;
      member += 1;
    };
    f();
    // Here, local is 0 but member is 1
  }
};

این بررسی بخش F.54 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f54-when-writing-a-lambda-that-captures-this-or-any-class-data-member-dont-use--default-capture از C++ Core Guidelines را پیاده‌سازی می‌کند.

cppcoreguidelines-missing-std-forward

زمانی که یک پارامتر ارجاع هدایت‌کننده (forwarding reference) در بدنه تابع فوروارد نشده باشد، هشدار می‌دهد.

مثال:

template <class T>
void wrapper(T&& t) {
  impl(std::forward<T>(t), 1, 2); // Correct
}
template <class T>
void wrapper2(T&& t) {
  impl(t, 1, 2); // Oops - should use std::forward<T>(t)
}
template <class T>
void wrapper3(T&& t) {
  impl(std::move(t), 1, 2); // Also buggy - should use std::forward<T>(t)
}
template <class F>
void wrapper_function(F&& f) {
  std::forward<F>(f)(1, 2); // Correct
}
template <class F>
void wrapper_function2(F&& f) {
  f(1, 2); // Incorrect - may not invoke the desired qualified function operator
}

گزینه‌ها

این بررسی، بخش F.19 http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rf-forward از C++ Core Guidelines را پیاده‌سازی می‌کند.

cppcoreguidelines-narrowing-conversions

این بررسی بخشی از ES.46 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es46-avoid-lossy-narrowing-truncating-arithmetic-conversions از C++ Core Guidelines را پیاده‌سازی می‌کند.

بررسی cppcoreguidelines-narrowing-conversions یک نام مستعار (alias) است؛ لطفاً برای اطلاعات بیشتر به bugprone-narrowing-conversions <> مراجعه کنید.

cppcoreguidelines-no-malloc

این بررسی مدیریت حافظه به سبک زبان C با استفاده از malloc()، realloc()، calloc() و free() را مدیریت می‌کند. درباره استفاده از آن‌ها هشدار داده و سعی می‌کند استفاده از یک شیء RAII مناسب را پیشنهاد دهد. علاوه بر این، می‌تواند طوری پیکربندی شود که فهرستی تعیین‌شده توسط کاربر از توابع مورد استفاده برای مدیریت حافظه (مانند posix_memalign()) را بررسی کند.

این بررسی، بخش R.10 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rr-mallocfree از C++ Core Guidelines را پیاده‌سازی می‌کند.

هیچ تلاشی برای ارائه راهنمایی‌های تصحیح خودکار (fix-it hints) صورت نگرفته است، زیرا مدیریت دستی منابع را نمی‌توان به سادگی و به صورت خودکار به RAII تبدیل کرد.

// Warns each of the following lines.
// Containers like std::vector or std::string should be used.
char* some_string = (char*) malloc(sizeof(char) * 20);
char* some_string = (char*) realloc(sizeof(char) * 30);
free(some_string);
int* int_array = (int*) calloc(30, sizeof(int));
// Rather use a smartpointer or stack variable.
struct some_struct* s = (struct some_struct*) malloc(sizeof(struct some_struct));

گزینه‌ها

cppcoreguidelines-no-suspend-with-lock

کوروتین‌هایی (coroutines) را نشانه‌گذاری می‌کند که در نقطه تعلیق، یک lock guard در دامنه (scope) آن‌ها وجود دارد و به حالت تعلیق درمی‌آیند.

هنگامی که یک کوروتین معلق می‌شود، هر قفل یا mutex در اختیار آن تا زمان ازسرگیری مجدد کوروتین و نهایتاً تخریب lock guard، قفل باقی خواهد ماند. این امر می‌تواند منجر به دوره‌های طولانی نگه‌داشتن mutex شده و خطر قفل متقابل (deadlock) را به همراه داشته باشد.

در عوض، قفل‌ها باید پیش از تعلیق یک کوروتین آزاد شوند.

این بررسی تنها تعلیق کوروتین‌ها در شرایطی که lock_guard در دامنه وجود دارد را بررسی می‌کند؛ و قفل‌گذاری یا آزادسازی دستی mutexها را، به عنوان مثال از طریق فراخوانی std::mutex::lock()، در نظر نمی‌گیرد.

مثال‌ها:

future bad_coro() {
  std::lock_guard lock{mtx};
  ++some_counter;
  co_await something(); // Suspending while holding a mutex
}
future good_coro() {
  {
    std::lock_guard lock{mtx};
    ++some_counter;
  }
  // Destroy the lock_guard to release the mutex before suspending the coroutine
  co_await something(); // Suspending while holding a mutex
}

این بررسی، بخش CP.52 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rcoro-locks از C++ Core Guidelines را پیاده‌سازی می‌کند.

cppcoreguidelines-noexcept-destructor

این بررسی، بخش C.37 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c37-make-destructors-noexcept از C++ Core Guidelines را پیاده‌سازی می‌کند.

بررسی cppcoreguidelines-noexcept-destructor یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به performance-noexcept-destructor <> مراجعه کنید.

cppcoreguidelines-noexcept-move-operations

این بررسی، بخش C.66 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c66-make-move-operations-noexcept از C++ Core Guidelines را پیاده‌سازی می‌کند.

بررسی cppcoreguidelines-noexcept-move-operations یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به performance-noexcept-move-constructor <> مراجعه کنید.

cppcoreguidelines-noexcept-swap

این بررسی، بخش‌های C.83 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c83-for-value-like-types-consider-providing-a-noexcept-swap-function ، C.84 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c84-a-swap-function-must-not-fail و C.85 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c85-make-swap-noexcept از C++ Core Guidelines را پیاده‌سازی می‌کند.

بررسی cppcoreguidelines-noexcept-swap check یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به performance-noexcept-swap <> مراجعه کنید.

cppcoreguidelines-non-private-member-variables-in-classes

بررسی cppcoreguidelines-non-private-member-variables-in-classes یک نام مستعار است؛ لطفاً برای اطلاعات بیشتر به misc-non-private-member-variables-in-classes <> مراجعه کنید.

cppcoreguidelines-owning-memory

این بررسی، معناشناسی مبتنی بر نوع gsl::owner<T*> را پیاده‌سازی می‌کند که تحلیل ایستا را روی کدهایی که از اشاره‌گرهای خام برای مدیریت منابعی مانند حافظه پویا استفاده می‌کنند ولی مفاهیم RAII را به کار نمی‌گیرند، امکان‌پذیر می‌سازد.

این بررسی، بخش‌های I.11 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#i11-never-transfer-ownership-by-a-raw-pointer-t-or-reference-t، C.33 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c33-if-a-class-has-an-owning-pointer-member-define-a-destructor، R.3 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r3-a-raw-pointer-a-t-is-non-owning و GSL.Views https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#ss-views از C++ Core Guidelines را پیاده‌سازی می‌کند. تعریف یک gsl::owner<T*> بسیار سرراست است

namespace gsl { template <typename T> owner = T; }

بنابراین، معرفی مالک حتی بدون استفاده از پیاده‌سازی Guideline Support Library https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#s-gsl نیز ساده است.

همه بررسی‌ها کاملاً مبتنی بر نوع هستند و (هنوز) به جریان حساس (flow sensitive) نمی‌باشند.

مثال‌های زیر مقداردهی‌های اولیه درست و نادرست مالک‌ها را نشان می‌دهند؛ با انتساب‌ها نیز به همین روش برخورد می‌شود. توجه داشته باشید که هر دو توابع منابع new و توابع مشابه malloc()، به عنوان تولیدکننده منبع در نظر گرفته می‌شوند.

// Creating an owner with factory functions is checked.
gsl::owner<int*> function_that_returns_owner() { return gsl::owner<int*>(new int(42)); }
// Dynamic memory must be assigned to an owner
int* Something = new int(42); // BAD, will be caught
gsl::owner<int*> Owner = new int(42); // Good
gsl::owner<int*> Owner = new int[42]; // Good as well
// Returned owner must be assigned to an owner
int* Something = function_that_returns_owner(); // Bad, factory function
gsl::owner<int*> Owner = function_that_returns_owner(); // Good, result lands in owner
// Something not a resource or owner should not be assigned to owners
int Stack = 42;
gsl::owner<int*> Owned = &Stack; // Bad, not a resource assigned

در مورد حافظه پویا به عنوان منبع، تنها متغیرهای gsl::owner<T*> مجاز به حذف (delete) شدن هستند.

// Example Bad, non-owner as resource handle, will be caught.
int* NonOwner = new int(42); // First warning here, since new must land in an owner
delete NonOwner; // Second warning here, since only owners are allowed to be deleted
// Example Good, Ownership correctly stated
gsl::owner<int*> Owner = new int(42); // Good
delete Owner; // Good as well, statically enforced, that only owners get deleted

علاوه بر این، بررسی تضمین می‌کند توابعی که یک gsl::owner<T*> را به عنوان شناسه انتظار دارند، یا با یک gsl::owner<T*> یا با یک منبع تازه‌ساخته‌شده فراخوانی شوند.

void expects_owner(gsl::owner<int*> o) { delete o; }
// Bad Code
int NonOwner = 42;
expects_owner(&NonOwner); // Bad, will get caught
// Good Code
gsl::owner<int*> Owner = new int(42);
expects_owner(Owner); // Good
expects_owner(new int(42)); // Good as well, recognized created resource
// Port legacy code for better resource-safety
gsl::owner<FILE*> File = fopen("my_file.txt", "rw+");
FILE* BadFile = fopen("another_file.txt", "w"); // Bad, warned
// ... use the file
fclose(File); // Ok, File is annotated as 'owner<>'
fclose(BadFile); // BadFile is not an 'owner<>', will be warned

گزینه‌ها

محدودیت‌ها

استفاده از gsl::owner<T*> در یک typedef یا alias به درستی مدیریت نمی‌شود.

using heap_int = gsl::owner<int*>;
heap_int allocated = new int(42); // False positive!

مورد gsl::owner<T*> به عنوان یک نام مستعار نوع قالب‌بندی‌شده (templated type alias) اعلان شده است. در توابع و کلاس‌های قالب (template)، مانند مثال زیر، اطلاعات نام‌های مستعار نوع از بین می‌رود. بنابراین، استفاده از gsl::owner<T*> در یک پایگاه کد به شدت مبتنی بر قالب ممکن است به مثبت کاذب (false positive) منجر شود.

ساختارهای کدی شناخته‌شده‌ای که به درستی عیب‌یابی نمی‌شوند عبارتند از:

// This template function works as expected. Type information doesn't get lost.
template <typename T>
void delete_owner(gsl::owner<T*> owned_object) {
  delete owned_object; // Everything alright
}
gsl::owner<int*> function_that_returns_owner() { return gsl::owner<int*>(new int(42)); }
// Type deduction does not work for auto variables.
// This is caught by the check and will be noted accordingly.
auto OwnedObject = function_that_returns_owner(); // Type of OwnedObject will be int*
// Problematic function template that looses the typeinformation on owner
template <typename T>
void bad_template_function(T some_object) {
  // This line will trigger the warning, that a non-owner is assigned to an owner
  gsl::owner<T*> new_owner = some_object;
}
// Calling the function with an owner still yields a false positive.
bad_template_function(gsl::owner<int*>(new int(42)));
// The same issue occurs with templated classes like the following.
template <typename T>
class OwnedValue {
public:
  const T getValue() const { return _val; }
private:
  T _val;
};
// Code, that yields a false positive.
OwnedValue<gsl::owner<int*>> Owner(new int(42)); // Type deduction yield T -> int *
// False positive, getValue returns int* and not gsl::owner<int*>
gsl::owner<int*> OwnedInt = Owner.getValue();

محدودیت دیگر پیاده‌سازی فعلی، بررسیِ صرفاً مبتنی بر نوع است. فرض کنید کدی شبیه به زیر دارید:

// Two owners with assigned resources
gsl::owner<int*> Owner1 = new int(42);
gsl::owner<int*> Owner2 = new int(42);
Owner2 = Owner1; // Conceptual Leak of initial resource of Owner2!
Owner1 = nullptr;

معناشناسی یک gsl::owner<T*> عمدتاً شبیه به یک std::unique_ptr<T> است، بنابراین انتساب دو gsl::owner<T*> به عنوان یک انتقال (move) در نظر گرفته می‌شود، که مستلزم آن است منبع Owner2 باید قبل از انتساب آزاد شده باشد. این نوع شرایط می‌تواند در بهبودهای آینده این بررسی با تحلیل حساس به جریان (flow-sensitive analysis) شناسایی شود. در حال حاضر، ابزار Clang Static Analyzer این باگ را برای حافظه پویا شناسایی می‌کند، اما نه برای انواع عمومی منابع.

cppcoreguidelines-prefer-member-initializer

مقداردهی‌های اولیه اعضا را در بدنه سازنده پیدا می‌کند که می‌توانند به جای آن به مقداردهنده‌های اولیه عضو (member initializers) سازنده تبدیل شوند. این کار نه تنها خوانایی کد را بهبود می‌بخشد، بلکه بر کارایی و عملکرد آن نیز تأثیر مثبتی دارد. انتساب‌های اعضای کلاس در داخل یک عبارت کنترلی یا پس از اولین عبارت کنترلی نادیده گرفته می‌شوند.

این بررسی قاعده C.49 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c49-prefer-initialization-to-assignment-in-constructors از C++ Core Guidelines را پیاده‌سازی می‌کند.

لطفاً توجه داشته باشید که این بررسی قاعده C.48 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c48-prefer-in-class-initializers-to-member-initializers-in-constructors-for-constant-initializers از C++ Core Guidelines را اعمال نمی‌کند. برای این منظور، بررسی modernize-use-default-member-init <> را ببینید.

مثال ۱

class C {
  int n;
  int m;
public:
  C() {
    n = 1; // Literal in default constructor
    if (dice())
      return;
    m = 1;
  }
};

در اینجا n بر خلاف m می‌تواند در فهرست مقداردهنده اولیه سازنده مقداردهی شود، زیرا مقداردهی اولیه m پس از یک عبارت کنترلی (if) قرار دارد:

class C {
  int n;
  int m;
public:
  C(): n(1) {
    if (dice())
      return;
    m = 1;
  }
};

مثال ۲

class C {
  int n;
  int m;
public:
  C(int nn, int mm) {
    n = nn; // Neither default constructor nor literal
    if (dice())
      return;
    m = mm;
  }
};

در اینجا برخلاف m، می‌توان n را در فهرست مقداردهی اولیهٔ سازنده مقداردهی کرد، زیرا مقداردهی اولیهٔ m پس از یک دستور کنترلی (if) قرار دارد:

C(int nn, int mm) : n(nn) {
  if (dice())
    return;
  m = mm;
}

cppcoreguidelines-pro-bounds-array-to-pointer-decay

این بررسی تمام زوال‌های آرایه به اشاره‌گر (decay) را پرچم‌گذاری می‌کند.

اشاره‌گرها نباید به عنوان آرایه استفاده شوند. ساختار span<T> یک جایگزین امن و با بررسی محدوده (bounds-checked) برای استفاده از اشاره‌گرها جهت دسترسی به آرایه‌ها است.

این قاعده بخشی از نمایهٔ ایمنی محدوده (Bounds 3) https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#pro-bounds-decay از C++ Core Guidelines است.

cppcoreguidelines-pro-bounds-avoid-unchecked-container-access

فراخوانی‌های operator[] را در نگه‌دارنده‌های STL پیدا کرده و جایگزینی آن‌ها با گزینه‌های امن را پیشنهاد می‌کند. جایگزین‌های امن شامل توابع at از STL یا at از GSL، توابع begin() یا end()، حلقه‌های range-for، std::span، یا یک تابع مناسب از <algorithms> هستند.

برای مثال، هر دوی

std::vector<int> a;
int b = a[4];

و

std::unique_ptr<vector> a;
int b = a[0];

یک هشدار ایجاد خواهند کرد.

نگه‌دارنده‌های STL که در آن‌ها operator[] برای همهٔ ورودی‌ها خوش‌تعریف است، از این بررسی مستثنی هستند (مانند: std::map::operator[]).

این بررسی بخشی از رهنمود SL.con.3 https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slcon3-avoid-bounds-errors را اعمال می‌کند و بخشی از نمایهٔ ایمنی محدوده (Bounds 4) https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#pro-bounds-arrayindex از C++ Core Guidelines است.

گزینه‌ها

cppcoreguidelines-pro-bounds-constant-array-index

این بررسی تمام عبارات زیرنویس آرایه روی آرایه‌های ایستا و std::arrayها را که فاقد اندیس از نوع عبارت عدد صحیح ثابت هستند یا از محدوده خارج‌اند (برای std::array) پرچم‌گذاری می‌کند. برای بررسی خروج از محدوده در آرایه‌های ایستا، به عیب‌یابی -Warray-bounds در Clang مراجعه کنید.

این قاعده بخشی از نمایهٔ ایمنی محدوده (Bounds 2) https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#pro-bounds-arrayindex از C++ Core Guidelines است.

به صورت اختیاری، این بررسی می‌تواند اصلاحاتی را با استفاده از gsl::at برای اندیس‌گذاری تولید کند.

گزینه‌ها