স্ট্রিং — অক্ষরের সারি আর শেষের অদৃশ্য শূন্য

১ · স্ট্রিং আসলে কী — char-এর সারি আর শেষের শূন্য

আপনার ফোনে bKash থেকে একটি SMS এলো: “You have received Tk 500”. আপনার চোখে এটি একটি বাক্য। কিন্তু মেমরিতে এটি শুধু পাশাপাশি রাখা কিছু বাইট — প্রতিটি অক্ষরের জন্য একটি নম্বর (পর্ব ০৫-এ দেখেছেন, 'Y'-এর ASCII নম্বর ৮৯)। প্রোগ্রামিংয়ে এমন লেখাকে বলে string.

Python বা Java-তে string একটি আলাদা টাইপ — সে নিজেই জানে সে কত লম্বা। C-তে এমন কিছু নেই। C-এর স্ট্রিং মানে স্রেফ char-এর একটি array (পর্ব ১৬), আর একটি চুক্তি: লেখা যেখানে শেষ, তার ঠিক পরের বাইটে থাকবে শূন্য। এই শূন্য বাইটটির নাম null terminator, কোডে লেখা হয় '\0'.

নিচের ঘোষণাটি দেখুন: char city[8] = "Dhaka";. এখানে ৮টি বাইটের জায়গা নেওয়া হলো, কিন্তু লেখা মাত্র ৫ অক্ষরের। মেমরিতে আসলে কী আছে, আর strlen কীভাবে দৈর্ঘ্য বের করে — ধাপে ধাপে দেখুন:

শূন্য-সংক্রান্ত চারটি জিনিস নতুনরা প্রায়ই গুলিয়ে ফেলেন। এগুলোর পার্থক্য একবার পরিষ্কার করে নিই:

২ · কেন এমন নকশা — ১৯৭০-এর দশকের হিসাব আর আজকের দাম

“দৈর্ঘ্যটা কোথাও লিখে রাখলেই তো হতো!” — প্রশ্নটি যৌক্তিক। আসলে বিকল্প নকশাটি তখনও ছিল। লেখার শুরুতে একটি ঘরে দৈর্ঘ্য রাখা, তারপর অক্ষরগুলো — একে বলে length-prefixed string. C-এর পূর্বসূরি ভাষা BCPL ঠিক এটাই করত, আর Pascal-এর অনেক পুরোনো রূপও।

প্রথম দামটি একটু হিসাব করে দেখি। strlen-এর কাজ লেখার দৈর্ঘ্যের সমানুপাতিক — ১০ অক্ষরে ১০ ধাপ, ১০ লক্ষ অক্ষরে ১০ লক্ষ ধাপ। Time complexity-র ভাষায় এটি O(n). Python-এ len(s) সাথে সাথে উত্তর দেয়, কারণ দৈর্ঘ্য আগে থেকেই লেখা থাকে।

এর একটি মজার পরিণতি আছে। ধরুন আপনি একটি লুপে বারবার strcat দিয়ে লেখার শেষে নতুন শব্দ জুড়ছেন। প্রতিবার strcat-কে আগে শুরু থেকে হেঁটে শেষটা খুঁজতে হয়। লেখা যত বড় হয়, প্রতিটি জোড়া তত ধীর হয়। প্রোগ্রামার Joel Spolsky ২০০১ সালে এর নাম দেন “Shlemiel the painter's algorithm” — এক রংমিস্ত্রির গল্প থেকে, যে রাস্তায় দাগ টানে কিন্তু রঙের কৌটা রেখে আসে শুরুর জায়গায় — তাই প্রতিদিন তাকে আরও বেশি হাঁটতে হয়।

৩ · দুই রকম ঘোষণা — char s[] বনাম char *p

কোডে দুটি সোজা ডাবল কোটের মাঝে সরাসরি লেখা টেক্সট — যেমন "Dhaka" — হলো একটি string literal. Compiler এই লেখাটি প্রোগ্রাম ফাইলের ভেতরে একটি বিশেষ অংশে রেখে দেয়, যেটি প্রোগ্রাম চলার সময় সাধারণত read-only memory হিসেবে চিহ্নিত থাকে — পড়া যায়, বদলানো যায় না। এবার দেখুন, একই literal দিয়ে দুই রকম ঘোষণার মধ্যে কত বড় পার্থক্য:

char s[] = "Dhaka";    // নিজের array — literal থেকে ৬ বাইট কপি
s[0] = 'd';            // ঠিক আছে: s এখন "dhaka"

char *p = "Dhaka";     // p শুধু literal-এর ঠিকানা রাখে, কপি নয়
p[0] = 'd';            // undefined behavior — প্রায়ই Segmentation fault

const char *q = "Dhaka";   // সঠিক অভ্যাস: const লিখে দিন
q[0] = 'd';                // এবার compiler নিজেই error দেবে

কেন C ভাষা literal বদলানোকে বৈধ রাখেনি? কারণ compiler একই লেখার একাধিক literal-কে একটিমাত্র কপিতে মিলিয়ে দিতে পারে। আপনার কোডে দশ জায়গায় "Dhaka" থাকলে মেমরিতে হয়তো একটিই আছে। একজন সেটি বদলালে বাকি নয় জায়গাও নিঃশব্দে বদলে যেত! তাই নিয়ম সহজ: literal-এর ঠিকানা রাখলে সবসময় const char * লিখুন। তাহলে ভুলটি প্রোগ্রাম চলার সময় নয়, compile করার সময়ই ধরা পড়বে।

৪ · string.h — প্রতিদিনের যন্ত্রপাতি আর == কেন কাজ করে না

স্ট্রিং নিয়ে কাজের ফাংশনগুলো থাকে standard library-র string.h header-এ। এদের সবার ভেতরে একটি লুপ আছে, যা '\0' খোঁজে — ঠিক যেমন strlen-এ দেখলেন। মুখস্থ করার দরকার নেই; চিনে রাখুন কোনটির কী কাজ, আর কোনটির গায়ে লাল পতাকা:

লেখা মেলাতে == কেন ভুল

পর্ব ১৮-তে দেখেছেন, array-র নাম বেশিরভাগ জায়গায় তার প্রথম ঘরের ঠিকানায় পরিণত হয় — একে বলে array decay. তাই if (answer == "yes") লিখলে C জিজ্ঞেস করে, “answer-এর ঠিকানা আর এই literal-এর ঠিকানা কি এক?” — প্রায় কখনোই এক নয়, যদিও দুটিতেই হুবহু “yes” লেখা। এটি দুটি বাড়ির ঠিকানা মিলিয়ে দেখার মতো, ভেতরে একই আসবাব আছে কি না নয়। ভাগ্য ভালো হলে compiler সতর্ক করে: comparison with string literal results in unspecified behavior.

লেখা মেলানোর সঠিক যন্ত্র strcmp. এটি দুটি লেখা বাঁ থেকে একসাথে হাঁটে, প্রথম যেখানে অমিল পায় সেখানে থামে। দেখুন "Dhaka" আর "Dhanmondi"-র তুলনা:

এবার এই পর্যন্ত যা দেখলেন, একটি প্রোগ্রামে মিলিয়ে নিন। এখানে sizeof বনাম strlen, == বনাম strcmp, আর মাপ মেনে লেখা তৈরির snprintf — তিনটিই আছে:

#include <stdio.h>
#include <string.h>

int main(void) {
    char city[8] = "Dhaka";
    char copy[8] = "Dhaka";
    const char *p = city, *q = copy;
    char msg[16];

    printf("sizeof = %zu, strlen = %zu\n", sizeof city, strlen(city));
    printf("p == q       -> %d (compares addresses)\n", p == q);
    printf("strcmp(p, q) -> %d (compares letters)\n", strcmp(p, q));
    printf("Dhaka before Dhanmondi? %d\n", strcmp(city, "Dhanmondi") < 0);

    int need = snprintf(msg, sizeof msg, "Hi %s, welcome to ABCL TECH", city);
    if (need >= (int)sizeof msg)
        printf("cut! needed %d, kept \"%s\"\n", need, msg);
    return 0;
}

৫ · বিপদ: strcpy, strcat আর buffer overflow

strcpy একটি খুব বিশ্বস্ত কর্মচারী — এতটাই বিশ্বস্ত যে সে কোনো প্রশ্ন করে না। তাকে বলা হয় “src থেকে dst-এ কপি করো”, আর সে '\0' না পাওয়া পর্যন্ত কপি করতেই থাকে। dst-এ কত জায়গা আছে, সেটি জানার কোনো উপায়ই তার নেই — কারণ C-এর স্ট্রিংয়ের সাথে মাপ থাকে না। strcat-এরও একই অবস্থা।

নিচের ডায়াগ্রামে একটি লগইন প্রোগ্রামের অংশ দেখুন। ধরা যাক মেমরিতে name-এর ঠিক পরেই role বসেছে। (বাস্তবে কোন ভ্যারিয়েবল কোথায় বসবে, তা compiler ঠিক করে — তাই এটি “যা ঘটতে পারে” তার একটি উদাহরণ, নিশ্চিত ফল নয়।)

আজকের compiler আর অপারেটিং সিস্টেম কিছু পাহারা বসিয়েছে। যেমন অনেক Linux সিস্টেমে GCC ডিফল্টভাবে stack-এ একটি গোপন মান রাখে — একে বলে stack canary, খনির খাঁচার সেই ক্যানারি পাখির নামে, যে বিষাক্ত গ্যাসে সবার আগে মারা যেত। ফাংশন শেষে মানটি বদলে গেছে দেখলে প্রোগ্রাম সাথে সাথে বন্ধ হয়ে যায়, আর দেখায় *** stack smashing detected ***. কিন্তু এগুলো শেষ রক্ষা, সমাধান নয় — সব ক্ষেত্রে কাজ করে না। আসল সমাধান হলো overflow হতে না দেওয়া।

strncpy-এর ফাঁদ — নাম শুনে নিরাপদ, আসলে নয়

অনেকে ভাবেন, strcpy-এর নিরাপদ রূপ হলো strncpy, কারণ সে একটি মাপ নেয়। কিন্তু এর আচরণ অদ্ভুত। লেখা যদি জায়গার সমান বা বড় হয়, strncpy ঠিক n বাইট কপি করে থেমে যায় — '\0' বসায় না। আবার লেখা ছোট হলে বাকি সব ঘর শূন্য দিয়ে ভরে, অকারণে সময় খরচ করে।

char team[6];
strncpy(team, "Bangladesh", sizeof team);   // কপি হলো "Bangla" — ৬টি অক্ষর
printf("%s\n", team);                       // '\0' নেই! পাশের আবর্জনাও ছাপা হতে পারে

strncpy(team, "Bangladesh", sizeof team - 1);
team[sizeof team - 1] = '\0';               // নিজের হাতে শেষ-চিহ্ন বসাতে হয়

এই অদ্ভুত আচরণের কারণ ঐতিহাসিক। strncpy মূলত তৈরি হয়েছিল পুরোনো Unix-এর নির্দিষ্ট মাপের ঘরের জন্য (যেমন ফাইলের নামের ১৪ বাইটের ঘর), যেখানে নাম পুরো ঘর জুড়ে থাকলে শেষ-চিহ্নের দরকারই ছিল না। সাধারণ স্ট্রিং কপির জন্য এটি কখনো বানানো হয়নি। তাই এর চেয়ে snprintf সহজ ও নির্ভরযোগ্য।

৬ · নিরাপদ অভ্যাস — সবসময় মাপ জেনে লিখুন

Buffer overflow ঠেকানোর মূল কথা একটাই: যে ফাংশন লিখবে, তাকে জায়গার মাপ জানাতে হবে। নিচের অভ্যাসগুলো পেশাদার C কোডে প্রতিদিনের নিয়ম:

অনেক বড় প্রতিষ্ঠান এই নিয়মগুলো লিখিত নীতিতে পরিণত করেছে। যেমন Microsoft-এর Security Development Lifecycle-এ strcpy, strcat, gets-এর মতো ফাংশন “নিষিদ্ধ” তালিকায় আছে; Git প্রজেক্টের কোডেও একটি banned.h ফাইল আছে, যা strcpy, strcat-এর মতো ফাংশন ব্যবহার করলেই compile আটকে দেয়। আর সন্দেহ হলে পর্ব ০৩-এর sanitizer চালান: gcc -fsanitize=address দিয়ে compile করলে প্রথম overflow-এর মুহূর্তেই প্রোগ্রাম থেমে দেখিয়ে দেয় কোন লাইনে, কত বাইট পেরিয়েছে।

৭ · লাইন পড়া — fgets আর শেষের newline

পর্ব ১০-এ শিখেছেন, ব্যবহারকারীর ইনপুট পড়ার নিরাপদ পথ হলো fgets — পুরো একটি লাইন, নির্দিষ্ট সীমার মধ্যে। কিন্তু একটি ছোট ঝামেলা আছে: fgets ব্যবহারকারীর চাপা Enter-টিও, অর্থাৎ '\n', লেখার শেষে রেখে দেয়। ফলে “Dhaka” টাইপ করলে buffer-এ আসে "Dhaka\n" — আর strcmp(buf, "Dhaka") আর 0 দেয় না!

সমাধানটি এক লাইনের, এবং এখন আপনি এর প্রতিটি অংশ বুঝবেন:

buf[strcspn(buf, "\r\n")] = '\0';

strcspn(buf, "\r\n") বলে, “buf-এর কোন ঘরে প্রথম '\r' বা '\n' আছে?” সেই ঘরে '\0' বসালেই লেখা সেখানে শেষ। কোনো newline না থাকলে strcspn লেখার দৈর্ঘ্যই ফেরত দেয় — তখন আগে থেকে থাকা '\0'-এর ওপরই আবার '\0' বসে, কোনো ক্ষতি নেই। '\r' রাখা হয়েছে কারণ Windows-এ তৈরি ফাইলে লাইনের শেষে থাকে "\r\n" — দুটিই মুছতে হয়।

নিচের প্রোগ্রামটি দুটি লাইন পড়ে — একটি ইংরেজি “Dhaka”, একটি বাংলা “ঢাকা” (পাতায় চালালে ইনপুট আগে থেকেই দেওয়া আছে)। প্রতিটি লাইনের newline সরানোর আগে ও পরে দৈর্ঘ্য, আর ভেতরের প্রতিটি বাইট hex-এ দেখায়:

#include <stdio.h>
#include <string.h>

int main(void) {
    char line[32];

    while (fgets(line, sizeof line, stdin) != NULL) {
        size_t before = strlen(line);
        line[strcspn(line, "\r\n")] = '\0';

        printf("%zu -> %zu bytes:", before, strlen(line));
        for (size_t i = 0; line[i] != '\0'; i++)
            printf(" %02X", (unsigned char)line[i]);
        printf("\n");
    }
    return 0;
}

৮ · বাংলা লেখা — বাইট, code point আর চোখের অক্ষর

পর্ব ০৫-এ দেখেছেন, UTF-8-এ ইংরেজি অক্ষর ১ বাইট, কিন্তু বাংলা অক্ষর ৩ বাইট — 'অ' মানে E0 A6 85. C-এর স্ট্রিং ফাংশনগুলো এসব কিছুই জানে না। তাদের কাছে স্ট্রিং মানে শুধু বাইটের সারি, শেষে একটি শূন্য। তাই বাংলা লেখায় “দৈর্ঘ্য” শব্দটির অন্তত তিনটি আলাদা অর্থ দাঁড়ায়:

চোখে দেখা একটি “অক্ষর” — যেমন “কা” বা যুক্তাক্ষর “ক্ষ” — Unicode-এর ভাষায় একটি grapheme cluster, যা একাধিক code point নিয়ে গঠিত হতে পারে। এবার দেখুন, কেউ যদি ইংরেজির মতো করে বাংলা লেখা উল্টাতে চান, তাহলে কী হয়:

এই জ্ঞান কাজে লাগে প্রতিদিনের সফটওয়্যারে। ডেটাবেসে নামের ঘর ২০ বাইটের হলে একটি বাংলা নাম মাঝখান থেকে কাটা পড়ে শেষে ভাঙা অক্ষর থেকে যেতে পারে — পরে সেটি পর্ব ০৫-এর mojibake হয়ে দেখা দেয়। মোবাইলে SMS-এর হিসাবও এর একটি পরিচিত উদাহরণ: শুধু ইংরেজি অক্ষরের একটি SMS-এ ১৬০টি অক্ষর ধরে, কিন্তু বাংলা থাকলে ফোনকে অন্য encoding ব্যবহার করতে হয়, আর এক SMS-এ ধরে মাত্র ৭০টি।

৯ · AI-এর যুগে স্ট্রিং — যেখানে AI সবচেয়ে বেশি ভুল করে

AI-কে “C-তে নাম জোড়ার একটা ফাংশন লেখো” বললে কয়েক সেকেন্ডে কোড আসবে, আর সেটি সাধারণ ইনপুটে চলবেও। সমস্যা হলো, AI শিখেছে কয়েক দশকের পুরোনো কোড থেকে — বই, ফোরাম, টিউটোরিয়াল — যেখানে strcpy আর strcat ছিল প্রতিদিনের জিনিস। স্ট্রিংয়ের ভুল প্রায় কখনো সাধারণ পরীক্ষায় ধরা পড়ে না; ধরা পড়ে লম্বা নাম, খালি ইনপুট বা বাংলা লেখায়।

AI-এর স্ট্রিং-কোডে যেসব ভুল বারবার দেখা যায়

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

• কোডে strcpy, strcat, sprintf, gets খুঁজে দেখেছি — থাকলে মাপসহ বিকল্পে বদলেছি
• প্রতিটি buffer-এর মাপ গুনেছি: সবচেয়ে লম্বা সম্ভাব্য লেখা + ১ বাইট আঁটে কি না
• লেখা তুলনার প্রতিটি জায়গায় == নয়, strcmp(...) == 0 আছে
• খালি ইনপুট, জায়গার চেয়ে ঠিক ১ অক্ষর বড় ইনপুট আর বাংলা ইনপুট দিয়ে চালিয়েছি
• gcc -Wall -Wextra -fsanitize=address দিয়ে compile করে চালিয়েছি — কোনো warning বা sanitizer রিপোর্ট নেই