Undefined Behavior ও নিরাপদ C++ — চুক্তি ভাঙলে কী হয়, কীভাবে ধরবেন

১ · C++ standard একটি চুক্তি — আর UB মানে আপনি নিজের অংশ ভেঙেছেন

মডিউল ৬-এর শেষ পর্বে এসে একটি প্রশ্ন করা যাক, যা এই কোর্সে বারবার ফিরে এসেছে: পর্ব ০৫-এ মান না দেওয়া ভ্যারিয়েবল, পর্ব ১৫-এ nullptr-এর ভেতরে ঢোকা, পর্ব ১৮-এ মৃত object ছোঁয়া — সব জায়গায় একই কথা লেখা ছিল, “এটি undefined behavior.” কিন্তু এর ঠিক মানে কী? “ভুল ফল আসবে”? “crash করবে”? কোনোটিই নয়। এর মানে আরও অদ্ভুত, আর সেটা বুঝলেই C++-এর অনেক রহস্য পরিষ্কার হয়ে যায়।

C++ standard দুই পক্ষের দায়িত্ব লিখে রাখে। আপনার দায়িত্ব: array-র সীমার ভেতরে থাকবেন, signed সংখ্যার হিসাব সীমা ছাড়াবে না, মৃত object ছোঁবেন না, এমন আরও কিছু শর্ত। Compiler-এর দায়িত্ব: আপনি শর্ত মানলে প্রোগ্রাম ঠিক standard-এ লেখা আচরণ করবে। যে প্রোগ্রাম কোনো শর্ত ভাঙে, তার জন্য standard কোনো আচরণই দাবি করে না — একটুও না। Standard-এর ভাষায় তখন “this document imposes no requirements”.

এর সবচেয়ে গুরুত্বপূর্ণ ফল হলো উল্টো দিকে: compiler ধরে নিতে পারে যে UB কখনো ঘটবে না, আর সেই ধারণার ওপর ভিত্তি করে কোড অপটিমাইজ করতে পারে। কারখানা যেমন ধরে নেয় মাপ সবসময় ঠিক, তাই যাচাইয়ের ধাপ বাদ দেয়। এজন্যই UB-এর ফল “যা খুশি” — শুধু ভুল সংখ্যা নয়, কোডের কোনো অংশ পুরো উধাও হয়ে যাওয়া, অন্য কোনো লাইনের আচরণ বদলে যাওয়া, কিংবা আজ সব ঠিক চলে পরের compiler সংস্করণে ভেঙে পড়া। এর সবচেয়ে বিপজ্জনক রূপ হলো শেষটি: “seems to work” — আপনার মেশিনে, আপনার টেস্টে, আজ।

২ · তিন রকম “অনিশ্চয়তা” — শুধু একটিই বিপজ্জনক

Standard সব কিছু শতভাগ বেঁধে দেয় না। কিছু জায়গায় ইচ্ছা করেই ফাঁক রাখে, যাতে C++ ছোট মাইক্রোকন্ট্রোলার থেকে সুপারকম্পিউটার পর্যন্ত সব মেশিনে দক্ষভাবে চলতে পারে। কিন্তু সব ফাঁক এক রকম নয়। তিনটি শব্দ আলাদা করে চিনে রাখুন:

প্রথম দুটি প্রোগ্রামকে ভাঙে না — শুধু আপনাকে সতর্ক থাকতে বলে। sizeof(int) ৪ ধরে নিয়ে লেখা কোড অন্য মেশিনে ভুল হতে পারে, তাই নির্দিষ্ট মাপ লাগলে std::int32_t ব্যবহার করুন (পর্ব ০৫)। আর ফাংশনের প্যারামিটারের ক্রমের ওপর নির্ভর না করতে চাইলে a() আর b()-এর ফল আগে আলাদা ভ্যারিয়েবলে রাখুন। কিন্তু তৃতীয়টি অন্য জাতের। নিচের ডায়াগ্রামে কয়েকটি পরিচিত উদাহরণ সাজিয়ে দেখুন:

৩ · Optimizer কেন UB-কে কাজে লাগায়

অনেকে প্রথমবার শুনে রেগে যান: “Compiler ভুলটা ধরতে পারলে আমাকে বলে না কেন, বরং কোড মুছে দেয় কেন?” আসল কথা হলো, compiler কোনো ভুল “ধরে” না। সে শুধু একটি যুক্তিসঙ্গত ধারণা থেকে অঙ্ক কষে: এই প্রোগ্রাম বৈধ, তাই এখানে UB ঘটে না। সেই ধারণা থেকে যা সত্য হতে বাধ্য, সেটুকু ব্যবহার করে সে কোড ছোট আর দ্রুত বানায়। এর নাম optimization, আর standard-এর যে নিয়ম এটা অনুমতি দেয় তার নাম as-if rule: বৈধ প্রোগ্রামের দেখা যায় এমন আচরণ ঠিক রাখলে compiler ভেতরে যা খুশি বদলাতে পারে।

সবচেয়ে বিখ্যাত উদাহরণটি একটি নিরীহ “overflow যাচাই।” প্রোগ্রামার ভাবলেন, x যদি সর্বোচ্চ মানে থাকে, x + 1 ঘুরে ঋণাত্মক হবে, তাই x + 1 < x সত্য হবে। ধাপে ধাপে দেখুন compiler কী ভাবে:

1bool willOverflow(int x) {2    return x + 1 < x;   // overflow হলে true?3}4// -O2-এর পরে কার্যত যা থাকে:5bool willOverflow(int) { return false; }6// নিরাপদ: return x == INT_MAX;

এটা কেন “ভালো” নিয়ম? কারণ একই যুক্তি প্রতিদিন লাখো জায়গায় আসল লাভ দেয়। একটি লুপ for (int i = 0; i < n; ++i)-এ compiler ধরে নিতে পারে i কখনো ঘুরে ঋণাত্মক হবে না, তাই সে i-কে ৬৪-বিট রেজিস্টারে চওড়া করে, ঠিকানার হিসাব সরল করে, আর লুপকে vector নির্দেশে (একসাথে কয়েকটি সংখ্যা) ভাঙে। যদি overflow-এর একটি নির্দিষ্ট আচরণ থাকত, প্রতিটি লুপে সেই সম্ভাবনা মাথায় রেখে ধীর কোড বানাতে হতো। C আর C++ ঐতিহাসিকভাবে এই বিনিময়টি বেছেছে: দায়িত্ব প্রোগ্রামারের, গতি সবার।

৪ · UB-এর তালিকা — ভুল রূপ আর নিরাপদ রূপ পাশাপাশি

C++ standard-এ UB-এর জায়গা শত শত, কিন্তু বাস্তব কোডের বেশিরভাগ বাগ দশটির মতো চেনা ধাঁচ থেকে আসে। নিচের ছোট কোডগুলো চালানোর জন্য নয় — শুধু চেনার জন্য। প্রতিটির পাশে তার নিরাপদ রূপ দেওয়া আছে।

১. Signed integer overflow

পর্ব ০৫-এ দেখেছেন, int সাধারণত প্রায় ২১৪ কোটি পর্যন্ত ধরে। এর বেশি হলেই overflow. Unsigned টাইপে overflow UB নয় — মান ইচ্ছা করেই ঘুরে শূন্যের দিকে যায় (modular arithmetic). তাই hash বা checksum-এর মতো জায়গায় যেখানে ঘুরে যাওয়াই উদ্দেশ্য, সেখানে unsigned সচেতনভাবে ব্যবহার করুন; কিন্তু টাকা, নম্বর, গণনার মতো জায়গায় ঘুরে যাওয়া মানেই ভুল।

int total = marksA * marksB;               // ভুল: গুণফল int ছাড়াতে পারে
long long total = 1LL * marksA * marksB;   // নিরাপদ: চওড়া টাইপে হিসাব
if (b > 0 && a > INT_MAX - b) { /* সামলান */ }  // নিরাপদ: আগে যাচাই

C++26-এ <numeric> header-এ saturation arithmetic-এর ফাংশন (std::add_sat, std::sub_sat ইত্যাদি) যোগ হয়েছে: ফল সীমা ছাড়ালে সর্বোচ্চ বা সর্বনিম্ন মানে আটকে থাকে, ঘোরে না। আপনার compiler-এ এখনো না থাকলে GCC আর Clang-এর __builtin_add_overflow বা হাতে লেখা যাচাই ব্যবহার করুন (অংশ ৫)।

২. সীমার বাইরে পড়া বা লেখা

v[i] কোনো সীমা যাচাই করে না — এটিই C++-এর “শূন্য খরচ” নীতি। i == v.size() হলেও সে চুপচাপ পাশের মেমরি পড়ে। এই out-of-bounds access থেকেই buffer overflow, ইতিহাসের সবচেয়ে বেশি দেখা নিরাপত্তা-ত্রুটির একটি।

for (std::size_t i = 0; i <= v.size(); ++i) use(v[i]);  // ভুল: <= মানে একটি বেশি
for (const auto& x : v) use(x);                          // নিরাপদ: index-ই নেই
use(v.at(i));                                            // নিরাপদ: ভুল হলে exception

Range-for (পর্ব ০৮) সবচেয়ে ভালো, কারণ ভুল index লেখার সুযোগই থাকে না। ফাংশনে array বা vector-এর অংশ পাঠাতে std::span নিন — সে ঠিকানার সাথে দৈর্ঘ্যও বয়ে বেড়ায়। আর যেখানে index লাগবেই, সেখানে .at() সীমা যাচাই করে std::out_of_range ছোড়ে। খেয়াল করুন, span-এর []-ও সাধারণ মোডে যাচাই করে না; সেটির জন্য hardened মোড লাগে (অংশ ৬)।

৩. Null pointer-এর ভেতরে ঢোকা

পর্ব ১৫-এ দেখেছেন, nullptr কোনো object-এর দিকে তাকিয়ে নেই। *p বা p->x করলে null dereference — সাধারণত crash, কিন্তু standard তা নিশ্চিত করে না, আর অংশ ৩-এর নোট দেখিয়েছে যাচাই মুছে যাওয়ার সম্ভাবনাও। নিরাপদ রূপ: যেখানে “না-ও থাকতে পারে” বোঝাতে চান, সেখানে pointer-এর বদলে std::optional বা reference ব্যবহার করুন; pointer লাগলে ব্যবহারের আগে যাচাই।

৪. Use-after-free আর dangling

মৃত object-কে reference, pointer, iterator বা view দিয়ে ছোঁয়া। এর পুরো বিবরণ — temporary, string_view, vector-এর reallocation, lambda capture — পর্ব ১৮-এ (lifetime ও dangling) দেখেছেন, এখানে পুনরাবৃত্তি করছি না। মনে রাখার নিয়ম একটাই: পর্যবেক্ষক কখনো মালিকের চেয়ে বেশি দিন বাঁচবে না। ASan এই ভুলকে use-after-free নামে ধরে।

৫. মান না দেওয়া ভ্যারিয়েবল পড়া

int total;            // ভুল: মান নেই, যা ছিল তাই
total += price;       // আবর্জনার সাথে যোগ
int total = 0;        // নিরাপদ: সবসময় শুরুতেই মান
int total{};          // নিরাপদ: {} মানে শূন্য

Uninitialized variable পড়া C++23 পর্যন্ত UB. C++26-এর জন্য একটি পরিবর্তন গৃহীত হয়েছে: local ভ্যারিয়েবলের মান না দিয়ে পড়া এখন erroneous behavior — “ভুল, কিন্তু নিয়মহীন নয়।” ভ্যারিয়েবলটি তখন compiler-এর ঠিক করা একটি নির্দিষ্ট মান পায়, আর compiler বা টুল চাইলে ভুলটি জানাতে পারে। এটা নিরাপত্তা বাড়ায়, কিন্তু কোডকে সঠিক বানায় না — total শূন্য না হয়ে অন্য কোনো মান হলে হিসাব তবুও ভুল। তাই নিয়ম বদলায় না: সবকিছু initialize করুন।

৬. Data race

দুটি thread একই ভ্যারিয়েবলে একসাথে কাজ করছে, অন্তত একটি লিখছে, আর মাঝে কোনো mutex বা atomic নেই — এর নাম data race, আর C++11-এর memory model অনুযায়ী এটি UB. শুধু “একটু ভুল সংখ্যা” নয়: compiler ধরে নিতে পারে অন্য কেউ ভ্যারিয়েবলটি বদলায় না, তাই মান রেজিস্টারে রেখে লুপ চিরকাল চালাতে পারে। এর নিরাপদ রূপ — std::mutex, std::atomic — পর্ব ৪৫ আর ৪৬-এ দেখবেন।

৭. Strict aliasing — অন্য টাইপের চোখে মেমরি পড়া

একটি float-এর ভেতরের বিটগুলো std::uint32_t হিসেবে দেখতে চান? পুরোনো ধাঁচে মানুষ pointer cast করত। কিন্তু C++-এর strict aliasing নিয়ম বলে: কোনো object-কে সাধারণত তার নিজের টাইপ (বা char, unsigned char, std::byte) দিয়েই পড়তে হবে। অন্য টাইপের pointer দিয়ে পড়া UB, কারণ compiler ধরে নেয় ভিন্ন টাইপের দুটি pointer একই মেমরির দিকে তাকায় না (পর্ব ১০-এর aliasing মনে করুন)।

float f = 1.0f;
auto u = *reinterpret_cast<std::uint32_t*>(&f);  // ভুল: strict aliasing ভাঙা
auto u = std::bit_cast<std::uint32_t>(f);          // নিরাপদ: C++20, <bit>
std::uint32_t u; std::memcpy(&u, &f, sizeof u);    // নিরাপদ: পুরোনো উপায়

এই কাজটিকে বলে type punning. std::bit_cast একই মাপের দুটি টাইপের মধ্যে বিটগুলো হুবহু কপি করে একটি নতুন object দেয় — কোনো aliasing নেই, আর compiler সাধারণত বাড়তি কোনো কাজও করে না।

৮–১০. আরও তিনটি চেনা ফাঁদ

শেষটি একটু ব্যাখ্যা চায়। Standard-এর forward progress নিয়ম অনুযায়ী, যে লুপ কোনো side effect (I/O, volatile বা atomic কাজ) ঘটায় না, compiler ধরে নিতে পারে সেটি একসময় শেষ হবে। ফলে ভুল করে লেখা অসীম infinite loop পুরো উধাও হয়ে যেতে পারে, আর প্রোগ্রাম এমন জায়গায় চলে যায় যেখানে যাওয়ার কথা নয়। C++26-এর জন্য একটি পরিবর্তন গৃহীত হয়েছে, যেখানে একদম ফাঁকা while (true) {}-এর মতো সরল লুপকে এই নিয়মের বাইরে রাখা হয়েছে, তবে সাধারণ নীতিটি একই আছে।

৫ · তিনটি বাস্তব বাগ — নম্বরের গড়, রসিদ প্রিন্টার আর শপিং কার্ট

তালিকা মুখস্থ করে লাভ কম, যদি বাস্তব কোডে ভুলটি চেনা না যায়। এখানে তিনটি ছোট গল্প — প্রতিটি সত্যিকারের প্রজেক্টে দেখা যায় এমন ধাঁচের।

গল্প ১ — জাতীয় পরীক্ষার গড় নম্বর

একটি শিক্ষা বোর্ডের সফটওয়্যার সব শিক্ষার্থীর মোট নম্বর যোগ করে গড় বের করে। লেখা হয়েছিল int sum = 0; for (int m : marks) sum += m;. পরীক্ষামূলক ফাইলে ৫০০ জন শিক্ষার্থী, সব ঠিক। আসল দিনে বিশ লাখ শিক্ষার্থী, প্রত্যেকের মোট নম্বর গড়ে ধরুন ১,১০০ — যোগফল দাঁড়ায় প্রায় ২২০ কোটি, যা int-এর প্রায় ২১৪ কোটির সীমার বাইরে। এটি signed overflow, অর্থাৎ UB; বাস্তবে সাধারণত একটি অর্থহীন ঋণাত্মক গড় আসে। সমাধান: যোগফল রাখুন চওড়া টাইপে, আর যেখানে সীমা নিশ্চিত নয় সেখানে যাচাই করুন। নিচের প্রোগ্রামে দুটি বোর্ডের যোগফল দিয়ে তিনটি নিরাপদ উপায় দেখুন:

#include <limits>
#include <optional>
#include <print>
#include <vector>

std::optional<int> checkedAdd(int a, int b) {
    if (b > 0 && a > std::numeric_limits<int>::max() - b) return std::nullopt;
    if (b < 0 && a < std::numeric_limits<int>::min() - b) return std::nullopt;
    return a + b;                                // safe: checked before adding
}

int main() {
    std::vector<int> boardTotals{1'200'000'000, 1'000'000'000};
    auto s = checkedAdd(boardTotals[0], boardTotals[1]);
    std::println("fits in int? {}", s.has_value());
    long long wide = 0;
    for (int t : boardTotals) wide += t;         // wider type: no overflow
    std::println("long long sum = {}", wide);
    int r = 0;
    bool over = __builtin_add_overflow(boardTotals[0], boardTotals[1], &r);
    std::println("builtin reports overflow: {}", over);
}

গল্প ২ — রসিদ প্রিন্টারের একটি বেশি ঘর

একটি মুদি দোকানের রসিদ প্রিন্টার লুপে i <= items.size() লেখে — একটি off-by-one ভুল। শেষ ঘরের পরের মেমরি থেকে একটি “দাম” পড়া হয়। কখনো রসিদের শেষে একটি অচেনা সংখ্যা ছাপা হয়, কখনো কিছুই হয় না, কারণ পাশের মেমরিতে ঘটনাক্রমে শূন্য ছিল। এই ভুলটি সাধারণ মোডে নিঃশব্দ — তাই ডেভেলপমেন্টের সময় আমরা চাই এটি জোরে চিৎকার করুক। নিচে .at() দিয়ে সেই চিৎকার, range-for দিয়ে ভুলের সুযোগই বন্ধ করা, আর সাথে std::bit_cast দিয়ে নিরাপদ type punning:

#include <bit>
#include <cstdint>
#include <print>
#include <stdexcept>
#include <vector>

int main() {
    std::vector<int> prices{120, 45, 300};          // valid index: 0, 1, 2
    try {
        for (std::size_t i = 0; i <= prices.size(); ++i)   // bug: <= goes one too far
            std::println("item {}: {} Tk", i, prices.at(i));
    } catch (const std::out_of_range&) {
        std::println("caught: index past the end");
    }
    int sum = 0;
    for (int p : prices) sum += p;                  // range-for: no index to get wrong
    std::println("total: {} Tk", sum);
    auto bits = std::bit_cast<std::uint32_t>(1.0f); // safe type punning (C++20)
    std::println("bits of 1.0f: {:#010x}", bits);
}

গল্প ৩ — শপিং কার্টের মোট টাকা

একটি অনলাইন দোকানের কার্টে মোট টাকা হিসাবের ফাংশন int total; দিয়ে শুরু হয়েছিল, মান ছাড়া। ডেভেলপারের কম্পিউটারে stack-এর ওই জায়গায় ঘটনাক্রমে শূন্য ছিল, তাই সব টেস্ট পাস করল। গ্রাহকের ফোনে release সংস্করণে কখনো কখনো মোট টাকা হাজার হাজার টাকা বেশি আসত। এই বাগটিকে আমরা অংশ ৭-এ “নিরাপদ সিঁড়ি” দিয়ে ধাপে ধাপে ধরব আর ঠিক করব।

৬ · ধরার যন্ত্র — warning থেকে fuzzing পর্যন্ত

UB চালিয়ে দেখে ধরা যায় না, কিন্তু টুল দিয়ে ধরা যায়। প্রতিটি টুল একটি আলাদা দিক থেকে তাকায় — কেউ কোড পড়ে (compile-এর সময়), কেউ প্রোগ্রাম চলার সময় পাহারা দেয়। কোনোটিই সব ধরে না, তাই পেশাদাররা কয়েকটি একসাথে চালান।

স্তর ১ — compiler warning

পর্ব ০৩-এ -Wall -Wextra শিখেছেন। UB-এর জন্য আরও দুটি যোগ করুন: -Wpedantic (standard-এর বাইরের extension ব্যবহার করলে জানায়) আর -Wconversion (চুপচাপ ছোট টাইপে রূপান্তর, যেমন long long থেকে int). আর CI (প্রতিটি পরিবর্তনে স্বয়ংক্রিয় build ও টেস্ট)-এ -Werror দিন, যাতে নতুন warning এলে build ব্যর্থ হয় — warning জমতে জমতে কেউ আর পড়ে না, এই রোগ এভাবে বন্ধ হয়।

g++ -std=c++23 -Wall -Wextra -Wpedantic -Wconversion -O2 cart.cpp -o cart
g++ ... -Werror        # CI-তে: warning মানেই build ব্যর্থ

স্তর ২ — sanitizer: চলার সময়ের পাহারাদার

Sanitizer হলো compiler-এর একটি সুবিধা, যা প্রোগ্রামের ভেতরে বাড়তি যাচাইয়ের কোড বসায়। প্রোগ্রাম চলার সময় UB ঘটলেই সে থামিয়ে বিস্তারিত রিপোর্ট দেয়। GCC আর Clang-এ চারটি প্রধান sanitizer:

প্রতিদিনের ডেভেলপমেন্ট আর টেস্টের জন্য সবচেয়ে কাজের জোড়া হলো -fsanitize=address,undefined, সাথে -g (রিপোর্টে লাইন নম্বর) আর -fno-omit-frame-pointer (পরিষ্কার stack trace). এগুলো টেস্টের জন্য, চূড়ান্ত সংস্করণের জন্য নয়। ASan-এর রিপোর্ট প্রথমবার দেখলে ভয় লাগে, কিন্তু এর গঠন সবসময় একই। গল্প ২-এর রসিদ প্রিন্টার [] দিয়ে লেখা হলে ASan যা বলত, তার একটি সরল রূপ ধাপে ধাপে পড়ুন:

1==4242==ERROR: AddressSanitizer:2  heap-buffer-overflow3READ of size 4 ... thread T04  #0 in printReceipt receipt.cpp:75  #1 in main receipt.cpp:136located 0 bytes after7  12-byte region8allocated by thread T0 here:9  #0 in operator new10  #3 in main receipt.cpp:1211SUMMARY: AddressSanitizer:12  heap-buffer-overflow receipt.cpp:7

একটি গুরুত্বপূর্ণ সীমা: sanitizer শুধু সেই পথের UB ধরে, যে পথে প্রোগ্রাম আসলে চলেছে। রসিদের লুপ যদি টেস্টে কখনো না চলে, ASan কিছুই বলবে না। তাই sanitizer যত ভালো, তার টেস্ট তত ভালো হতে হয় — এখানেই fuzzing আসে (নিচে)।

স্তর ৩ — static analyzer: চালানো ছাড়াই কোড পড়া

Static analyzer প্রোগ্রাম না চালিয়ে কোড বিশ্লেষণ করে, সম্ভাব্য সব পথ ভেবে দেখার চেষ্টা করে। clang-tidy (LLVM প্রজেক্টের) শত শত নিয়ম জানে — bugprone-* সাধারণ বাগ, cppcoreguidelines-* Core Guidelines-এর নিয়ম, modernize-* পুরোনো ধাঁচ বদলানোর পরামর্শ। cppcheck একটি স্বাধীন ওপেন-সোর্স টুল, যা কম ভুল সতর্কবার্তা দেওয়ার দিকে জোর দেয়। Static analyzer কখনো কখনো ভুল সতর্কবার্তা দেয়, আবার কিছু বাগ ছেড়েও যায় — তবু এটি সেই পথগুলো দেখে, যেগুলো আপনার টেস্ট কখনো চালায়নি।

clang-tidy cart.cpp --checks='bugprone-*,cppcoreguidelines-*' -- -std=c++23
cppcheck --enable=warning,style cart.cpp

স্তর ৪ — hardened standard library

পর্ব ১৩-এ hardened standard library-এর কথা শুনেছেন। এখন একটু বিস্তারিত: GCC-র library (libstdc++)-তে -D_GLIBCXX_ASSERTIONS দিলে vector, string, span-এর [], front(), back() সহ অনেক জায়গায় সীমা ও শর্ত যাচাই চালু হয়; ভাঙলে প্রোগ্রাম একটি স্পষ্ট বার্তা দিয়ে থেমে যায়। Clang-এর library (libc++)-তে একই কাজ করে _LIBCPP_HARDENING_MODE (যেমন _LIBCPP_HARDENING_MODE_FAST). এর খরচ সাধারণত খুব কম, তাই কিছু বড় প্রতিষ্ঠান এটি চূড়ান্ত সংস্করণেও চালু রাখে। C++26-এ “standard library hardening” standard-এরই অংশ হিসেবে গৃহীত হয়েছে, তাই ভবিষ্যতে এটি compiler-ভেদে আরও এক রকম হবে।

এর আত্মীয় হলো -D_FORTIFY_SOURCE (সাধারণত =2 বা =3), যা glibc-র memcpy, strcpy-এর মতো C ফাংশনে compile-এর সময় জানা মাপের সাথে যাচাই যোগ করে; এটি কাজ করতে optimization (-O1 বা বেশি) লাগে। GCC 14 থেকে -fhardened নামে একটি flag এর কয়েকটি সুরক্ষা একসাথে চালু করে।

স্তর ৫ — fuzzing আর constexpr

Fuzzing একটি টেস্টিং কৌশল: একটি টুল আপনার ফাংশনকে লাখ লাখ স্বয়ংক্রিয়ভাবে বানানো, অদ্ভুত ইনপুট দেয়, আর কোন ইনপুটে নতুন কোড-পথ খোলে তা দেখে আরও ইনপুট বানায়। Sanitizer-এর সাথে জোড়া দিলে এটি এমন সীমার বাইরের পড়া বা overflow খুঁজে পায়, যা কোনো মানুষ টেস্ট লিখে ভাবতেন না। libFuzzer (LLVM) আর AFL++ এর পরিচিত টুল, আর Google-এর OSS-Fuzz ২০১৬ সাল থেকে বহু ওপেন-সোর্স প্রজেক্টকে বিনামূল্যে নিয়মিত fuzz করে আসছে। আপনার প্রজেক্টে এর সবচেয়ে ভালো লক্ষ্য হলো যেকোনো parser — ফাইল, নেটওয়ার্ক বার্তা বা ব্যবহারকারীর ইনপুট পড়ার কোড।

শেষ অস্ত্রটি আপনি পর্ব ৩৯-এ (constexpr) দেখেছেন: compile-এর সময় হিসাব চলার সময় core language-এর UB ঘটলে compiler-কে সেটি error হিসেবে জানাতে হয়। অর্থাৎ constexpr ফাংশনকে static_assert-এ চালালে signed overflow বা সীমার বাইরে পড়া compile error হয়ে যায়। এটি ছোট, বিশুদ্ধ হিসাবের ফাংশন পরীক্ষার একটি বিনামূল্যের sanitizer.

৭ · নিরাপদ সিঁড়ি — একটি বাগ থেকে স্থায়ী সমাধান

টুলগুলো আলাদা আলাদা শিখলেন। এবার একসাথে, গল্প ৩-এর শপিং কার্টের বাগ দিয়ে। ভালো দল প্রতিটি বাগে একই সিঁড়ি বেয়ে ওঠে: warning দেখা, sanitizer দিয়ে প্রমাণ, মূল কারণে সমাধান, আর এমন টেস্ট যা বাগটিকে আর কখনো ফিরতে দেবে না।

int cartTotal(const std::vector<Item>& items) {
    int total;                     // মান নেই
    for (const auto& it : items)
        total += it.price * it.qty;
    return total;
}

cart.cpp:5:15: warning: 'total' is used uninitialized
    [-Wuninitialized]

WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 in main cart.cpp:12
  Uninitialized value was created by an allocation
    of 'total' in the stack frame of cartTotal

int cartTotal(const std::vector<Item>& items) {
    long long total = 0;          // মান + চওড়া টাইপ
    for (const auto& it : items)
        total += 1LL * it.price * it.qty;
    return checkedToInt(total);   // যাচাই করা রূপান্তর
}

assert(cartTotal({}) == 0);                   // খালি কার্ট
assert(cartTotal({{"Rice", 80, 5}}) == 400);
# CI: প্রতিটি পরিবর্তনে দুবার build
g++ -Wall -Wextra -Werror ...
g++ -fsanitize=address,undefined -g ... && ./tests

৮ · নিরাপদ C++-এর অভ্যাস — আর memory safety নিয়ে আজকের আলোচনা

টুল বাগ ধরে, কিন্তু অভ্যাস বাগ জন্মাতেই দেয় না। এই কোর্সে যত “আধুনিক C++” শিখেছেন, তার বেশিরভাগই আসলে নিরাপত্তার নিয়ম। এক জায়গায় সাজিয়ে রাখি:

• সবকিছু initialize করুন। int x{};, std::string s; (নিজেই খালি), member-এ default মান (পর্ব ২১)। ঘোষণা আর প্রথম মান একই লাইনে।
• মালিকানা টাইপে লিখুন। RAII, std::vector, std::string, আর smart pointer (পর্ব ১৭)। কাঁচা new/delete (naked new) সাধারণ কোডে নয়।
• Index-এর বদলে range. range-for, STL algorithm, ranges (পর্ব ৩৩, ৩৫)। index লাগলে debug-এ .at() বা hardened মোড।
• View সাবধানে। std::span আর std::string_view প্যারামিটারে দারুণ, কিন্তু মালিক নয় — member বা ফেরতের টাইপে নিলে মালিকের আয়ু নিশ্চিত করুন (পর্ব ১৮)।
• C-style cast নয়। (int)x চুপচাপ যেকোনো রূপান্তর করে ফেলে; static_cast শুধু যুক্তিসঙ্গতটি করে, আর খুঁজে পাওয়া সহজ। C-style cast clang-tidy দিয়ে ধরা যায়।
• সংখ্যা-রূপান্তর যাচাই করে। বড় থেকে ছোট টাইপে নেওয়ার সময় মান ধরবে কি না দেখুন — gsl::narrow-এর মতো একটি ছোট ফাংশন, নিচে দেখুন। আর {} দিয়ে initialize করলে narrowing compile error হয়।
• Build-এ নিরাপত্তা। warning পরিষ্কার, টেস্টে sanitizer, release-এ _FORTIFY_SOURCE ও hardened library বিবেচনা।

“যাচাই করা রূপান্তর” কেমন দেখায়? Microsoft-এর GSL (Guidelines Support Library)-এ gsl::narrow<int>(x) আছে: রূপান্তরের পর মান বদলে গেলে সে exception ছোড়ে। নিজে একটি সরল রূপ লেখা যায় C++20-এর std::in_range দিয়ে:

int checkedToInt(long long v) {
    if (!std::in_range<int>(v)) throw std::out_of_range("does not fit in int");
    return static_cast<int>(v);   // এখন নিশ্চিত: মান বদলাবে না
}

Memory safety — সরকার, শিল্প আর C++-এর জবাব

গত কয়েক বছরে UB শুধু প্রোগ্রামারদের আলোচনা নয়, নীতিনির্ধারকদেরও আলোচনা। কারণ বড় প্রতিষ্ঠানগুলো নিজেদের তথ্য প্রকাশ করেছে: Microsoft আর Chromium দুই দলই জানিয়েছে, তাদের গুরুতর নিরাপত্তা-ত্রুটির প্রায় ৭০% memory safety-সংক্রান্ত (বিস্তারিত ভাবনার প্রশ্ন ০৩-এ)। এমন বাগ ইতিহাসে বহুবার গুরুতর নিরাপত্তা-দুর্বলতার জন্ম দিয়েছে।

C++ সমাজের জবাব কয়েক স্তরের। প্রথমত, C++ Core Guidelines — Bjarne Stroustrup আর Herb Sutter-এর নেতৃত্বে লেখা নিয়মের সংকলন, যার অনেকগুলো clang-tidy আর MSVC-র টুল যাচাই করতে পারে। দ্বিতীয়ত, safety profile প্রস্তাব: কোডের কোনো অংশে “type”, “bounds”, “lifetime”-এর মতো নিরাপত্তা-নিয়মের একটি দল চালু করা, যাতে compiler সেই অংশে বিপজ্জনক ধাঁচ আটকায়। Stroustrup এই পথের প্রধান সমর্থক; তাঁর যুক্তি, C++-কে বাদ না দিয়ে, পুরোনো কোড না ভেঙে, ধাপে ধাপে নিরাপদ করা বেশি বাস্তবসম্মত, আর “safety” একটিমাত্র জিনিস নয়, অনেক রকম নিশ্চয়তার একটি পরিবার। Profiles C++26-এর অংশ হয়নি; কাজটি আলাদা নথি হিসেবে এগোচ্ছে, আর সমালোচকরা প্রশ্ন তোলেন এটি কতটা নিশ্চয়তা দিতে পারবে। তৃতীয়ত, যা ইতিমধ্যে C++26-এর জন্য গৃহীত — library hardening, uninitialized পড়ার erroneous behavior, আর contracts — এগুলো ছোট কিন্তু বাস্তব পদক্ষেপ।

৯ · AI-এর যুগে — AI-এর লেখা কোডে UB খোঁজা

AI টুল C++ কোড দ্রুত লেখে, আর সেই কোড সাধারণত compile হয়, ছোট উদাহরণে ঠিক চলে। ঠিক এই কারণেই UB-এর জন্য বিপজ্জনক: UB-এর বৈশিষ্ট্যই হলো “ছোট টেস্টে ঠিক চলা।” AI ইন্টারনেটের কোটি কোটি লাইন কোড থেকে শিখেছে, যার বড় অংশ পুরোনো ধাঁচের — C-style cast, int-এ বড় যোগফল, index দিয়ে লুপ। যে ভুলগুলো বারবার দেখা যায়:

AI-এর কোডে UB যাচাইয়ের চেকলিস্ট

• প্রতিটি যোগফল বা গুণফলের সর্বোচ্চ সম্ভাব্য মান হিসাব করেছি, আর টাইপটি তা ধরে
• প্রতিটি []-এর index কোথা থেকে আসে জানি, আর সীমা যাচাই হয়েছে — বা range-for দিয়ে index-ই বাদ দিয়েছি
• প্রতিটি ভ্যারিয়েবল ঘোষণার সাথেই মান পেয়েছে
• কোনো C-style cast নেই; প্রতিটি রূপান্তর static_cast বা যাচাই করা ফাংশন দিয়ে
• -Wall -Wextra -Wpedantic -Wconversion পরিষ্কার
• টেস্টগুলো -fsanitize=address,undefined দিয়ে চালিয়েছি; thread থাকলে আলাদা build-এ TSan
• AI-এর দেওয়া রিভিউ আমি নিজে যাচাই করেছি — AI-ও ভুল “সমস্যা” দেখাতে পারে, আসল সমস্যা ছেড়েও যেতে পারে