Undefined Behavior ও নিরাপদ কোডিং — চুক্তি ভাঙলে কী হয়

১ · C স্ট্যান্ডার্ড একটি চুক্তিপত্র

এই কোর্সে অনেকগুলো পর্বে একটি শব্দ বারবার এসেছে — undefined behavior, সংক্ষেপে UB. পর্ব ০৭-এ i = i++, পর্ব ১৬-তে array-র সীমার বাইরে পড়া, পর্ব ১৯-এ buffer overflow, পর্ব ২০-এ free করা মেমরি আবার ব্যবহার, পর্ব ৪৫-এ strict aliasing. প্রতিবার আমরা বলেছি “এটি UB, করবেন না।” এই পর্বে সেই সব টুকরো এক জায়গায় জুড়ব। আর দেখব, কেন এই ছোট ছোট ভুলই পৃথিবীর সবচেয়ে বড় নিরাপত্তা-বিপর্যয়গুলোর উৎস।

শুরু করি একটি মৌলিক কথা দিয়ে। C ভাষার মালিক কোনো একটি compiler নয়। ভাষাটির নিয়ম লেখা আছে একটি আন্তর্জাতিক দলিলে — ISO C standard-এ। GCC, Clang, Microsoft-এর compiler, এমনকি ছোট microcontroller-এর compiler — সবাই এই দলিল মেনে চলার চেষ্টা করে।

এখানেই নতুনদের সবচেয়ে বড় ভুল ধারণা। তাঁরা ভাবেন, “UB মানে হয়তো ভুল একটা সংখ্যা আসবে, বা প্রোগ্রাম crash করবে।” না। স্ট্যান্ডার্ড আক্ষরিক অর্থেই বলে, এই অবস্থায় আচরণের ওপর কোনো শর্ত নেই। ফল ঠিক আসতে পারে, ভুল আসতে পারে, crash হতে পারে, আবার আপনার লেখা অন্য একটি if নিঃশব্দে উধাও হয়ে যেতে পারে।

C-তে UB রাখা হলো কেন?

প্রশ্ন জাগতেই পারে — এত বিপজ্জনক জিনিস ভাষায় রাখার দরকার কী? উত্তর দুটি শব্দে: portability আর গতি।

• সব যন্ত্রে চলা: ১৯৮০-র দশকে C যখন প্রমিত হচ্ছিল, তখন বাজারে নানা রকম CPU — কোনোটিতে ঋণাত্মক সংখ্যা রাখার নিয়ম আলাদা, কোনোটি ভুল ঠিকানায় পড়লে থেমে যায়, কোনোটি থামে না। সবার আচরণ একটি নিয়মে বাঁধলে অনেক যন্ত্রে প্রতিটি যোগ-বিয়োগের সাথে বাড়তি যাচাই লাগত।
• যাচাইয়ের খরচ না দেওয়া: array-র প্রতিটি ব্যবহারে সীমা যাচাই, প্রতিটি pointer ব্যবহারের আগে null যাচাই — এগুলো ভাষা নিজে করলে প্রোগ্রাম ধীর হতো। C এই দায়িত্ব প্রোগ্রামারের হাতে দিয়েছে।
• Optimizer-কে স্বাধীনতা দেওয়া: “signed সংখ্যা কখনো উপচে পড়ে না” — এই অনুমান থাকলে compiler লুপকে অনেক দ্রুত করতে পারে। অংশ ৪-এ আমরা দেখব, এই স্বাধীনতাই কখনো কখনো ভয়ংকর রূপ নেয়।

২ · তিন রকম “অনির্দিষ্টতা”

স্ট্যান্ডার্ড সব কিছু একভাবে নির্দিষ্ট করে না। কিছু জিনিস ইচ্ছা করেই খোলা রাখা হয়েছে। কিন্তু খোলা রাখার তিনটি ভিন্ন মাত্রা আছে, আর পার্থক্যটি জানা খুব জরুরি।

৩ · পুরো কোর্সের UB — এক তালিকায়

নিচের তালিকাটি মুখস্থ করার জন্য নয়, চিনে রাখার জন্য। কোড রিভিউ বা AI-এর কোড পড়ার সময় এই প্রতিটি জিনিসের দিকে চোখ রাখবেন। পাশে লেখা আছে কোন পর্বে বিস্তারিত দেখেছেন।

তালিকাটি খেয়াল করুন — বেশিরভাগই মেমরি নিয়ে। ভুল জায়গায় পড়া, ভুল জায়গায় লেখা, ভুল সময়ে লেখা। নিরাপত্তার জগতে এদের একসাথে বলা হয় মেমরি-নিরাপত্তার ভুল, বা memory safety bug. অংশ ৫-এ দেখব, কেন এরাই আক্রমণকারীদের সবচেয়ে প্রিয়।

৪ · Optimizer কীভাবে UB-কে কাজে লাগায়

এবার আসল চমক। Compiler বিদ্বেষী নয় — সে কেবল নিয়ম মেনে যুক্তি চালায়। কিন্তু “UB কখনো ঘটে না” — এই একটি অনুমান থেকে সে এমন সিদ্ধান্ত নিতে পারে, যা মানুষের চোখে অবিশ্বাস্য। সবচেয়ে বিখ্যাত উদাহরণটি ধাপে ধাপে দেখুন। একজন প্রোগ্রামার bKash-এর মতো একটি wallet-এর জন্য overflow যাচাই লিখেছেন:

int will_overflow(int x) {
    return x + 1 < x;    /* x+1 ছোট হলে overflow? */
}

if (will_overflow(balance)) {
    reject();                 /* লেনদেন বাতিল */
}

/* x হলো int (signed).                       */
/* signed overflow হলে প্রোগ্রাম অবৈধ।      */
/* অতএব বৈধ প্রোগ্রামে x + 1 কখনো উপচায় না */
/* অর্থাৎ x + 1 সবসময় গাণিতিক x + 1          */

    x + 1 < x
⇔  (দুই পাশ থেকে x বাদ)
    1 < 0
⇔  সবসময় false

int will_overflow(int x) {
    return 0;
}

/* if (0) { reject(); }  — পুরো অংশ বাদ */

int will_overflow(int x) {
    return x == INT_MAX;   /* UB ছাড়াই */
}
/* অথবা: __builtin_add_overflow(x, 1, &r) */

আরও তিনটি পরিচিত ধরন

১. আগে ব্যবহার, পরে null-check. ২০০৯ সালে Linux kernel-এর tun নেটওয়ার্ক ড্রাইভারে এমন একটি কোড পাওয়া যায়, যার ধাঁচ মোটামুটি এরকম:

struct sock *sk = tun->sk;     /* আগে tun ব্যবহার হলো */
if (!tun)                      /* তারপর null যাচাই   */
    return POLLERR;

Compiler-এর যুক্তি: “tun->sk পড়া হয়ে গেছে। tun null হলে সেটিই UB হতো। তাই এখানে tun null নয়, আর যাচাইটি অপ্রয়োজনীয়।” GCC যাচাইটি মুছে দিল। সাধারণ অবস্থায় null ঠিকানায় পড়লে প্রোগ্রাম থেমে যায়, কিন্তু সেই সময়ের কিছু সিস্টেমে ঠিকানা ০-তে মেমরি বসানোর সুযোগ ছিল। নিরাপত্তা গবেষকেরা দেখান, এভাবে kernel-এর নিয়ন্ত্রণ নেওয়া সম্ভব। এরপর Linux kernel নিজের build-এ -fno-delete-null-pointer-checks flag যোগ করে, যাতে compiler এমন যাচাই আর না মোছে।

২. অসীম লুপের অনুমান। C11 থেকে নিয়ম বলে: যে লুপের শর্ত একটি ধ্রুবক (constant) নয়, এবং যার ভেতরে কোনো I/O, volatile বা atomic কাজ নেই, compiler ধরে নিতে পারে সেটি একসময় শেষ হবে। তাই “কিছু না করে অপেক্ষা” ধরনের লুপ optimizer পুরোপুরি মুছে দিতে পারে। while (1)-এর শর্ত ধ্রুবক, তাই সেটি এই নিয়মের বাইরে।

৩. “সময় ভ্রমণ” করা UB. সবচেয়ে অদ্ভুত ধারণাটি এটি। UB কোনো একটি লাইনে আটকে থাকে না — স্ট্যান্ডার্ডের ভাষায়, UB-ওয়ালা পুরো চলাটাই অনির্দিষ্ট। তাই প্রোগ্রাম যদি নিশ্চিতভাবে সামনে কোথাও UB-তে পৌঁছায়, compiler তার আগের কোডকেও বদলে দিতে পারে। যেমন একটি ফাংশন শেষে সবসময় একটি pointer পড়ে — optimizer চাইলে ধরে নিতে পারে pointer কখনো null নয়, এবং আগে null-এর জন্য রাখা যাচাই বা শাখাও বাদ দিতে পারে। (বাস্তবে compiler সাধারণত log লেখার মতো বাইরের কাজ সরায় না, কিন্তু UB-এর আগের হিসাব আর শাখা বদলে যাওয়ার ঘটনা দেখা যায়।) Debug করার সময় তাই “এই লাইন পর্যন্ত তো ঠিক ছিল” — এই যুক্তিও UB-এর সামনে টেকে না।

৫ · নিরাপত্তার চোখে — মেমরির ভুল কেন সবচেয়ে বড় ঝুঁকি

এতক্ষণ UB-কে আমরা “ভুল ফল” বা “অদ্ভুত আচরণ” হিসেবে দেখেছি। কিন্তু নিরাপত্তার কাজে যাঁরা আছেন, তাঁদের চোখে প্রতিটি মেমরির ভুল একটি সম্ভাব্য vulnerability — এমন একটি দুর্বলতা, যা কাজে লাগিয়ে বাইরের কেউ প্রোগ্রামের ডেটা চুরি করতে পারে, প্রোগ্রাম বন্ধ করে দিতে পারে, বা সবচেয়ে খারাপ ক্ষেত্রে প্রোগ্রামকে নিজের ইচ্ছামতো চালাতে পারে। সাধারণ বাগ শুধু ভুল করে; নিরাপত্তার বাগকে কেউ ইচ্ছা করে খুঁজে বের করে ব্যবহার করে।

সংখ্যাটির উৎস খেয়াল করুন। Microsoft-এর নিরাপত্তা দল ২০১৯ সালে জানায়, বছরের পর বছর তাদের সফটওয়্যারে যে নিরাপত্তা-ত্রুটি সারানো হয়, তার প্রায় ৭০% মেমরি-নিরাপত্তার সমস্যা। ২০২০ সালে Chromium (Google Chrome-এর ভিত্তি) প্রজেক্টও তাদের উচ্চ ও গুরুতর মাত্রার নিরাপত্তা-বাগ গুনে প্রায় একই অনুপাত পায়। দুটিই বড় C ও C++ কোডবেস। এটি সব সফটওয়্যারের একটি সার্বজনীন সূত্র নয়, কিন্তু দুটি আলাদা প্রতিষ্ঠানের আলাদা হিসাব একই দিকে ইঙ্গিত করছে — এটাই চিন্তার বিষয়।

Stack-এ buffer overflow — পাশের ঘরে কী থাকে

পর্ব ১৩-তে দেখেছেন, প্রতিটি ফাংশন ডাকলে stack-এ একটি stack frame তৈরি হয়। তার ভেতরে local ভ্যারিয়েবল, আর তার কাছেই থাকে return address — ফাংশন শেষে CPU কোথায় ফিরে যাবে। ব্যবহারকারীর ডেটা আর প্রোগ্রামের নিজের হিসাবের তথ্য পাশাপাশি রাখা — সমস্যার মূল এখানেই। নিচে একটি সাধারণ x86-64 Linux সিস্টেমের সরল ছবি:

  উঁচু ঠিকানা
  +-----------------------+
  | return address        |   ফাংশন শেষে CPU কোথায় ফিরবে
  +-----------------------+
  | saved frame pointer   |   আগের ফাংশনের frame-এর তথ্য
  +-----------------------+
  | stack canary          |   গোপন মান; বদলে গেলে প্রোগ্রাম থামে
  +-----------------------+
  | char name[16]         |   ইনপুট এখানে লেখা হয়
  |   ^ লেখা এগোয় ওপরে    |
  +-----------------------+
  নিচু ঠিকানা

name মাত্র ১৬ বাইট। কেউ যদি gets বা যাচাইহীন strcpy দিয়ে এর চেয়ে লম্বা ইনপুট লেখে, বাড়তি বাইটগুলো থেমে থাকে না — সেগুলো পাশের ঘরগুলোর ওপর দিয়ে লেখা হয়ে যায়: অন্য local ভ্যারিয়েবল, saved frame pointer, এমনকি return address. ফাংশন শেষে CPU সেই নষ্ট হয়ে যাওয়া ঠিকানায় ফিরতে চায়। সবচেয়ে ভালো ক্ষেত্রে প্রোগ্রাম crash করে; খারাপ ক্ষেত্রে ফেরার ঠিকানা এমন কিছু হয়ে যায়, যা ইনপুট যে পাঠিয়েছে সে-ই ঠিক করে দিয়েছে। এই কারণেই একটি সাধারণ “বেশি লম্বা নাম” বাগ নিরাপত্তার ভাষায় হয়ে যায় “প্রোগ্রামের নিয়ন্ত্রণ হারানো”।

এই একটি ঝুঁকি ঠেকাতেই কয়েক দশক ধরে নানা প্রতিরক্ষা তৈরি হয়েছে: bounds checking (লেখার আগে সীমা যাচাই), stack canary (return address-এর আগে একটি গোপন মান বসিয়ে ফাংশন শেষে মিলিয়ে দেখা), NX (stack-এর মেমরিকে “চালানো যাবে না” চিহ্ন দেওয়া), আর ASLR (প্রতিবার প্রোগ্রাম খোলার সময় মেমরির ঠিকানাগুলো এলোমেলো করা)। পর্ব ১৯-এ string নিয়ে কাজ করার সময় buffer overflow আর canary-র সাথে আপনার প্রথম পরিচয় হয়েছিল; অংশ ৮-এ দেখব এরা কীভাবে একসাথে স্তর তৈরি করে।

মেমরি-নিরাপত্তার বাগের প্রধান পরিবার

শেষ সারিটি একটু আলাদা, তাই আলাদা করে বলি। TOCTOU মানে “time of check to time of use” — যাচাইয়ের সময় আর ব্যবহারের সময়ের ফাঁক। ধরুন একটি প্রোগ্রাম আগে access() দিয়ে দেখে নিল, ব্যবহারকারী /tmp/report.txt ফাইলে লিখতে পারেন কি না। তারপর কয়েক মাইক্রোসেকেন্ড পরে fopen() দিয়ে ফাইলটি খুলল। এই ফাঁকে অন্য কেউ যদি ঐ নামের জায়গায় একটি গুরুত্বপূর্ণ সিস্টেম-ফাইলের link বসিয়ে দেয়, তাহলে যাচাই হয়েছিল এক ফাইলের, লেখা হচ্ছে আরেক ফাইলে। এটি মেমরির বাগ নয়, কিন্তু একই মানসিকতার ভুল — “একটু আগে যা সত্য ছিল, এখনো সত্য” ধরে নেওয়া। সমাধানও একই ধাঁচের: যাচাই আর কাজ আলাদা ধাপে না করে একসাথে করা — যেমন সরাসরি খোলার চেষ্টা করে ফল দেখা, আর খোলা ফাইলের ওপরেই (নামের ওপর নয়) পরের যাচাইগুলো করা।

৬ · Integer overflow — হিসাবের ভুল থেকে মেমরির ভুল

অংশ ৩-এ বলেছিলাম, unsigned সংখ্যার wraparound সম্পূর্ণ বৈধ, UB নয়। এখন দেখবেন, বৈধ হলেই নিরাপদ নয়। সবচেয়ে বিপজ্জনক জায়গা হলো মেমরির আকার হিসাব করা — malloc(count * size). count যদি বাইরে থেকে আসে (একটি ফাইলের header, network packet, ব্যবহারকারীর ইনপুট), তাহলে গুণফল উপচে পড়তে পারে। পুরোনো ৩২-বিট কম্পিউটার ও ফোন, আর অনেক microcontroller-এ size_t এখনো ৩২-বিট — সর্বোচ্চ মান 4294967295. নিচের ডায়াগ্রামে ঠিক সেই অবস্থা দেখুন:

1size_t count = read_u32(pkt); /* from file or network */2size_t bytes = count * sizeof(int);3int *a = malloc(bytes);4for (size_t i = 0; i < count; i++)5    a[i] = 0;6/* fix: if (count > SIZE_MAX / sizeof(int)) fail */

এই ছকটি — “বাইরে থেকে আসা সংখ্যা → আকার হিসাব → ছোট buffer → বড় লেখা” — এতই সাধারণ যে নিরাপত্তা-বিশেষজ্ঞরা কোড পড়ার সময় প্রথমেই malloc-এর ভেতরের প্রতিটি গুণ-যোগ খোঁজেন। এখন হাতে-কলমে দেখুন কীভাবে আকার আর টাকার হিসাব দুটোই নিরাপদে করা যায়। GCC আর Clang দুটোতেই compiler builtin হিসেবে __builtin_mul_overflow আর __builtin_add_overflow আছে — এরা হিসাবটি করে, আর ফল জায়গায় না আঁটলে true ফেরত দেয়। একে বলে checked arithmetic.

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
static void *alloc_array(size_t count, size_t size) {
    size_t total;
    if (__builtin_mul_overflow(count, size, &total)) {   /* আগে যাচাই */
        printf("rejected: %zu * %zu overflows\n", count, size);
        return NULL;
    }
    printf("allocating %zu bytes\n", total);
    return malloc(total);
}
int main(void) {
    free(alloc_array(1000, sizeof(int)));
    free(alloc_array(SIZE_MAX / 2, sizeof(int)));
    int64_t balance = INT64_MAX - 100, sum;               /* পয়সায় হিসাব */
    if (__builtin_add_overflow(balance, 500, &sum)) printf("deposit rejected\n");
    else printf("new balance %lld\n", (long long)sum);
    return 0;
}

size_t আর signed সংখ্যার মিশ্রণ

আরেকটি নীরব ফাঁদ হলো signed আর unsigned মেশানো। ধরুন একটি ফাংশন দৈর্ঘ্য নেয় int len হিসেবে, আর ভেতরে ডাকে memcpy(dst, src, len). কেউ len = -1 পাঠালে memcpy-এর size_t parameter-এ সেটি রূপান্তরিত হয়ে যায় সবচেয়ে বড় সংখ্যায় — SIZE_MAX. আবার if (len < sizeof buf) যাচাইয়েও পর্ব ০৮-এর usual arithmetic conversions মেনে -1 unsigned হয়ে বিশাল সংখ্যা হয়, অথবা উল্টো দিকে কোনো যাচাই ঋণাত্মক সংখ্যাকে “ছোট, তাই ঠিক আছে” ভেবে পার করে দেয়। নিয়মটি সহজ: আকার, দৈর্ঘ্য আর index-এর জন্য সবসময় size_t, আর বাইরে থেকে আসা signed সংখ্যাকে আগে ঋণাত্মক কি না দেখে, তারপর রূপান্তর করুন। -Wsign-compare আর -Wsign-conversion warning এমন অনেক জায়গা দেখিয়ে দেয়।

৭ · নিরাপদ কোডের অভ্যাস — প্রথম দেয়াল আপনি নিজে

পরের অংশে compiler, sanitizer আর OS-এর প্রতিরক্ষা দেখব। কিন্তু সেগুলো সবই দ্বিতীয় সারির খেলোয়াড়। প্রথম দেয়াল হলো কোড লেখার অভ্যাস। ক্রিকেটে উইকেটকিপার আর স্লিপ ফিল্ডার থাকলেও ব্যাটসম্যান নিজে বাজে শট খেলেন না — এখানেও তেমন। নিচের অভ্যাসগুলো একবার রপ্ত করলে উপরের তালিকার বেশিরভাগ বাগ জন্মই নেয় না।

শেষ অভ্যাসটি কোডের বাইরের মনে হলেও আসলে খুব গুরুত্বপূর্ণ। কোনো বাগ যদি থেকেও যায়, ক্ষতি কতটা হবে তা নির্ভর করে প্রোগ্রামটির হাতে কতটা ক্ষমতা ছিল তার ওপর। একটি ছবি ছোট করার প্রোগ্রামের ব্যাংকের ডেটাবেস ছোঁয়ার অনুমতি থাকার কোনো কারণ নেই। পর্ব ৪৮-এ process-এর অনুমতি আর বিচ্ছিন্নতা নিয়ে আরও দেখবেন।

snprintf — শুধু ব্যবহার নয়, ফেরত মানটিও পড়ুন

অনেকে sprintf-এর জায়গায় snprintf বসিয়েই নিশ্চিন্ত হয়ে যান। হ্যাঁ, snprintf কখনো buffer-এর সীমা পেরিয়ে লেখে না। কিন্তু লেখা কেটে ছোট হয়ে গেলে (truncation) সেটিও একটি বাগ হতে পারে — অর্ধেক ফাইলের নাম, অর্ধেক SMS, অর্ধেক SQL query. snprintf-এর ফেরত মান বলে দেয়, পুরো লেখাটির জন্য কত অক্ষর লাগত। সেটি দেখেই truncation ধরা যায়:

1char sms[16];2int n = snprintf(sms, sizeof sms, "Hi %s", name);3if (n < 0 || (size_t)n >= sizeof sms) {4    /* truncated: reject, or grow */5}6char *full = malloc((size_t)n + 1);7snprintf(full, (size_t)n + 1, "Hi %s", name);

এবার একটি পূর্ণ, চালানো যায় এমন উদাহরণ। ফাংশনটি একটি bKash-ধাঁচের লেনদেনের SMS তৈরি করে, আর লেখা না আঁটলে সেটি স্পষ্টভাবে জানায়:

#include <stdio.h>
#include <string.h>
/* 0 = ok, -1 = না আঁটলে (out-এ তবুও \0-সহ নিরাপদ অংশ থাকে) */
static int format_sms(char *out, size_t cap, const char *name, long taka) {
    int n = snprintf(out, cap, "Dear %s, you received %ld Tk.", name, taka);
    if (n < 0) return -1;                    /* encoding error */
    if ((size_t)n >= cap) {                  /* কাটা পড়েছে */
        printf("needed %d bytes, have %zu\n", n + 1, cap);
        return -1;
    }
    return 0;
}
int main(void) {
    char sms[40];
    const char *names[] = { "Rahim", "Mohammad Abdullah Al Mamun" };
    for (int i = 0; i < 2; i++) {
        int rc = format_sms(sms, sizeof sms, names[i], 500);
        printf("%s: [%s] len=%zu\n", rc == 0 ? "ok" : "TRUNCATED", sms, strnlen(sms, sizeof sms));
    }
    return 0;
}

৮ · প্রতিরক্ষার স্তর — একটি দেয়ালে ভরসা নয়

নিরাপত্তার জগতে একটি পুরোনো নীতি আছে: defence in depth — স্তরে স্তরে প্রতিরক্ষা। ঢাকার কোনো অফিস ভবনের কথা ভাবুন: গেটে দারোয়ান, লিফটের সামনে কার্ড, প্রতিটি ফ্লোরে CCTV, গুরুত্বপূর্ণ ঘরে আলাদা তালা। কোনো একটি স্তর ব্যর্থ হলেও পরের স্তর আছে। C কোডের নিরাপত্তাও এভাবে সাজানো হয়। একটি বাগ কোন স্তরে কীভাবে ধরা পড়ে, ধাপে ধাপে দেখুন:

void save_name(const char *in) {
    char buf[32];
    strcpy(buf, in);      /* in কত লম্বা? কেউ জানে না */
    store(buf);
}

/* ইনপুটের দৈর্ঘ্য compile-এর সময় জানা থাকলে: */
warning: 'strcpy' writing 41 bytes into a region of size 32
         overflows the destination [-Wstringop-overflow=]
/* কিন্তু in যদি network থেকে আসে, compiler কিছুই জানে না */
-- কোনো warning নেই --

/* fuzzer লক্ষ লক্ষ এলোমেলো ইনপুট পাঠায়, একটিতে ৪০ অক্ষর */
==4242==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 41 ...
    #0 in strcpy
    #1 in save_name order.c:3
/* ঠিক কোন লাইন, কত বাইট — release-এর আগেই ধরা */

/* -D_FORTIFY_SOURCE=2: strcpy-এর জায়গায় যাচাইসহ সংস্করণ */
*** buffer overflow detected ***: terminated
/* অথবা -fstack-protector-strong: canary বদলে গেছে */
*** stack smashing detected ***: terminated
ফল: নিয়ন্ত্রণ হারানোর বদলে নিয়ন্ত্রিত crash

int save_name(const char *in) {
    char buf[32];
    int n = snprintf(buf, sizeof buf, "%s", in);
    if (n < 0 || (size_t)n >= sizeof buf) return -1;
    store(buf);
    return 0;
}
/* + ৪০ বাইটের ইনপুট দিয়ে regression test, CI-তে fuzzing */

Compiler flag — বিনা খরচের বীমা

GCC বা Clang-এ সাধারণ একটি নিরাপদ build দেখতে মোটামুটি এরকম। টেস্টের জন্য আর release-এর জন্য দুটি আলাদা কমান্ড রাখা ভালো অভ্যাস:

# টেস্ট ও ডেভেলপমেন্ট: বাগ খোঁজা
gcc -std=c17 -Wall -Wextra -Werror -g -O1 \
    -fsanitize=address,undefined -fno-omit-frame-pointer app.c -o app_test

# release: hardening
gcc -std=c17 -Wall -Wextra -Werror -O2 -D_FORTIFY_SOURCE=2 \
    -fstack-protector-strong -fPIE -pie app.c -o app

OS-এর সুরক্ষা — কেন ঝুঁকি কমায়, শূন্য করে না

আজকের Linux, Windows, macOS, Android — সবাই কয়েকটি mitigation একসাথে ব্যবহার করে। NX (Windows-এ নাম DEP) ডেটা রাখার মেমরিকে “এখানে কোড চালানো যাবে না” চিহ্ন দেয়, তাই stack-এ ঢোকানো বাইট কোড হিসেবে চলে না। ASLR প্রতিবার প্রোগ্রাম খোলার সময় stack, heap, library-র ঠিকানা এলোমেলো করে, তাই আক্রমণকারী জানে না কোথায় কী আছে। Canary return address-এর আগের পাহারাদার।

কিন্তু এদের প্রতিটিই কোনো একটি নির্দিষ্ট পথ বন্ধ করে, বাগটি নয়। Canary শুধু return address-এর আশেপাশের লেখা ধরে; পাশের অন্য ভ্যারিয়েবল বা heap-এর ডেটা নষ্ট হলে সে কিছুই জানে না। ASLR-এর এলোমেলো ঠিকানা কোনো তথ্য ফাঁসের বাগে বেরিয়ে গেলে তার সুরক্ষাও দুর্বল হয়ে যায় — আর ৩২-বিট সিস্টেমে এলোমেলো করার জায়গাই কম। NX কোড ঢোকানো ঠেকায়, কিন্তু প্রোগ্রামের ভেতরে আগে থেকে থাকা কোডের অপব্যবহার পুরোপুরি ঠেকাতে পারে না; এজন্যই নতুন CPU-তে shadow stack আর control-flow integrity-র মতো আরও স্তর আসছে। আর Heartbleed-এর মতো out-of-bounds read-এ এদের কোনোটিই কাজে আসেনি। তাই এগুলোকে ভাবুন সিটবেল্টের মতো — দুর্ঘটনার ক্ষতি কমায়, কিন্তু সিটবেল্ট আছে বলে বেপরোয়া গাড়ি চালানোর লাইসেন্স দেয় না।

Coding standard — অন্যের ভুল থেকে শেখা নিয়ম

৯ · মেমরি-নিরাপত্তার বিতর্ক — C কি বিদায় নিচ্ছে?

“প্রায় ৭০%” সংখ্যাটি প্রকাশের পর সফটওয়্যার শিল্পে একটি বড় প্রশ্ন উঠেছে: নতুন কোড কি আদৌ C-তে লেখা উচিত? এখানে দুই পক্ষের কথাই শোনা দরকার।

পরিবর্তনের দিক

• Rust আর বড় প্রজেক্ট: Rust একটি memory-safe language — compiler নিজেই ownership আর borrowing-এর নিয়ম দিয়ে use-after-free, data race আর সীমার বাইরে প্রবেশ ঠেকায়, আর সেটি garbage collector ছাড়াই। Linux kernel ২০২২ সালের শেষে (সংস্করণ ৬.১) প্রথমবার Rust কোডের প্রাথমিক সমর্থন যোগ করে; এরপর ধীরে ধীরে Rust-এ লেখা driver আসতে শুরু করেছে। Google Android-এ নতুন সিস্টেম-কোডের একটি অংশ Rust-এ লিখছে, আর জানিয়েছে যে এরপর Android-এ মেমরি-নিরাপত্তার ত্রুটির অনুপাত কয়েক বছরে উল্লেখযোগ্যভাবে কমেছে।
• সরকারি নির্দেশনা: ২০২২ থেকে ২০২৪ সালের মধ্যে যুক্তরাষ্ট্রের NSA, CISA ও অন্যান্য সরকারি সংস্থা একাধিক নির্দেশিকা প্রকাশ করে, যেখানে সফটওয়্যার নির্মাতাদের memory-safe ভাষার দিকে যাওয়ার পরিকল্পনা করতে উৎসাহ দেওয়া হয়। অন্য কয়েকটি দেশের নিরাপত্তা সংস্থাও এর কিছু নির্দেশিকায় যুক্ত হয়।

C কেন থেকে যাচ্ছে

• বিদ্যমান কোড: OS kernel, database, network stack, ভাষার interpreter — কয়েক বিলিয়ন লাইনের পরীক্ষিত C কোড চলছে। সব নতুন করে লেখা ঝুঁকিপূর্ণ ও ব্যয়বহুল; নতুন করে লেখা কোডেও নতুন বাগ আসে।
• Embedded জগৎ: অনেক ছোট microcontroller-এর জন্য ভালো compiler, টুল আর নিরাপত্তা-সার্টিফিকেশন মূলত C-তেই আছে।
• গতি ও নিয়ন্ত্রণ: কোথায় কোন বাইট, কখন বরাদ্দ — C-তে সবকিছু প্রোগ্রামারের হাতে।
• সার্বজনীন সংযোগ: প্রায় সব ভাষা অন্য ভাষার সাথে কথা বলে C-এর ABI দিয়ে। Rust, Python, Go — সবাই C ফাংশন ডাকতে পারে, C-এর মতো ফাংশন প্রকাশ করতে পারে।

বাস্তব চিত্রটি তাই “C না Rust” নয়, বরং “দুটোই, দায়িত্বের সাথে”। নতুন, ইনপুট-নির্ভর ও ঝুঁকিপূর্ণ অংশ ধীরে ধীরে memory-safe ভাষায় যাচ্ছে; বিদ্যমান C কোডে চলছে কড়া flag, sanitizer, fuzzing আর coding standard. একজন ভালো C প্রোগ্রামারের কাজ এই পর্বের অভ্যাসগুলোকে স্বভাবে পরিণত করা — তাহলে আপনি যে ভাষাতেই যান, মেমরি নিয়ে আপনার চিন্তা পরিষ্কার থাকবে।

১০ · AI-এর যুগে — AI-এর লেখা C কোডের নিরাপত্তা-যাচাই

AI দিয়ে লেখা C কোড সাধারণত compile হয়, সাধারণ ইনপুটে ঠিক চলে, দেখতেও পরিপাটি। সমস্যা হলো, AI শিখেছে ইন্টারনেটের বিশাল পরিমাণ পুরোনো কোড থেকে — যার অনেকটাই strcpy, sprintf, যাচাইহীন malloc দিয়ে লেখা। ফলে AI-এর কোডে প্রায়ই সূক্ষ্ম মেমরি-নিরাপত্তা ও UB-এর সমস্যা থাকে, যা সাধারণ টেস্টে ধরা পড়ে না। নিরাপত্তার বাগ ধরা পড়ে অস্বাভাবিক ইনপুটে — আর সেটি পরীক্ষা করার দায়িত্ব আপনার।

AI-এর কোডে যেসব ভুল প্রায়ই দেখা যায়

AI-এর লেখা C কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কোথাও gets, strcpy, strcat, sprintf নেই; থাকলে প্রতিটির পাশে সীমা প্রমাণিত
• প্রতিটি snprintf-এর ফেরত মান যাচাই হয়েছে
• malloc-এর প্রতিটি আকার-হিসাব উপচানোর আগে যাচাই হয়, আর প্রতিটি বরাদ্দের NULL-check আছে
• আকার ও index-এ size_t; বাইরে থেকে আসা প্রতিটি সংখ্যার পরিসর যাচাই
• -Wall -Wextra -Werror-এ পরিষ্কার compile, আর -fsanitize=address,undefined দিয়ে লম্বা, ফাঁকা ও অদ্ভুত ইনপুটে চালিয়ে দেখেছি
• প্রতিটি বরাদ্দের মালিক স্পষ্ট; error পথেও ঠিক একবার free