ढेर नीचे की ओर क्यों बढ़ता है?

मैं यह मान रहा हूं कि इसका एक इतिहास है, लेकिन स्टैक नीचे की ओर क्यों बढ़ता है?

यह मुझे लगता है कि अगर बफर ऊपर की ओर बढ़े तो शोषण करने के लिए बफर बहुत अधिक कठिन होगा ...

cpu stack

— mehrdad
स्रोत

stackoverflow.com/questions/1677415/… ध्यान दें कि स्टैक या तो कुछ हद तक बढ़ सकता है।

— जेबी किंग

इस तरह एक सवाल है: stackoverflow.com/questions/2035568/… । : Factly का मामला वहाँ एक बहुत अच्छा सवाल और यहां इस जवाब है stackoverflow.com/questions/664744/...

— कार्लसन

जुड़ा हुआ सवाल बफर ओवरफ्लो समस्या को काफी कवर नहीं करता है।

— deadalnix

क्योंकि ढेर ऊपर की तरफ बढ़ता है।

— 18

स्मृति स्थान 0 ऊपर या नीचे है?

जवाबों:

मेरा मानना है कि यह कंप्यूटिंग के शुरुआती दिनों से आता है, जब मेमोरी बहुत सीमित थी, और स्टैक द्वारा विशेष उपयोग के लिए मेमोरी का एक बड़ा हिस्सा पूर्व-आवंटित करना बुद्धिमान नहीं था। तो, पता शून्य से ऊपर की ओर ढेर मेमोरी आवंटित करके, और मेमोरी को मेमोरी के अंत से नीचे की ओर स्टैक करें, तो आप ढेर और स्टैक दोनों को मेमोरी का एक ही क्षेत्र साझा कर सकते हैं।

यदि आपको कुछ अधिक हीप की आवश्यकता है, तो आप अपने स्टैक के उपयोग से सावधान रह सकते हैं; यदि आपको अधिक स्टैक की आवश्यकता है, तो आप कुछ ढेर मेमोरी को मुक्त करने का प्रयास कर सकते हैं। परिणाम, निश्चित रूप से, ज्यादातर, शानदार दुर्घटनाएं थीं, क्योंकि स्टैक कभी-कभी ढेर और इसके विपरीत को अधिलेखित कर देगा।

उन दिनों में इंटरवेब नहीं थे, इसलिए बफर ओवररन शोषण का कोई मुद्दा नहीं था। (या कम से कम इस हद तक कि इंटरवेब मौजूद था, यह सभी संयुक्त राज्य रक्षा विभाग की उच्च सुरक्षा सुविधाओं के भीतर था, इसलिए दुर्भावनापूर्ण डेटा की संभावना को बहुत अधिक विचार करने की आवश्यकता नहीं थी।)

उसके बाद, अधिकांश आर्किटेक्चर के साथ यह एक ही वास्तुकला के पिछले संस्करणों के साथ संगतता बनाए रखने का मामला था। इसीलिए आज भी उल्टा-सीधा ढेर हमारे साथ है।

— माइक नाकिस
स्रोत

इतिहास में आगे जाएं और कोई ढेर नहीं था, आज भी, कई 8 और 16 बिट माइक्रो नियंत्रकों में एक ढेर नहीं है। स्टैक बड़ा हो गया इसलिए प्रोग्राम को कम मेमोरी पते में स्थापित किया जा सकता है, और स्टैक शेष मेमोरी था। स्टैक इनिशियलाइज़ेशन को प्रोग्राम लोड करने, कार्यक्रमों को सरल बनाने से पहले किया जा सकता है।

— मटन

अधिकांश छोटे माइक्रोकंट्रोलर्स के पास एक ढेर होता है, बस एक ढेर नहीं होता है जो बढ़ता है। जब आपके पास काम करने के लिए रैम (<1Kbytes) की थोड़ी मात्रा हो, तो ढेर पर गतिशील मेमोरी आवंटन का उपयोग करना उचित होगा। आमतौर पर एकमात्र मेमोरी सेक्शन का आकार जो बदलता है वह स्टैक है।

— तेहनीत

कार्यक्रम मेमोरी पारंपरिक रूप से स्थापित की जाती है

code
constants
heap (growing up)
...
stack (growing down)

ढेर और ढेर का आदान-प्रदान किया जा सकता है

लेकिन बफर ओवरफ्लो का अभी भी शोषण किया जा सकता है अगर स्टैक दूसरे तरीके से चला गया

strcpyएक उदाहरण के रूप में क्लासिक ले रहा है

foo(char* in){
char[100] buff;
strcpy(buff,in);
}

स्टैक मेमोरी के रूप में

ret foo
arg in
buff array
ret strcpy
buf pointer
in

इसका मतलब यह होगा कि जब कॉपी करने के लिए रिटर्न एड्रेस किया strcpyजाता है तो बफर के बाद ( foo'रिटर्न एड्रेस' के बजाय ) और जो कुछ भी है उसे ओवरराइट किया जा सकता है।in

— शाफ़्ट सनकी
स्रोत

कुछ हार्डवेयर में उच्च स्मृति पर शुरू होने वाले ढेर होते हैं, नीचे बढ़ते हैं, जबकि स्टैक कम मेमोरी में बढ़ते हुए शुरू होता है।

एचपी का पीए-आरआईएससी हार्डवेयर, दूसरों के बीच, यह करता है: http://www.embeddedrelated.com/usenet/embedded/show/68749-1.php

आदरणीय मल्टिक्स ऑपरेटिंग सिस्टम हार्डवेयर पर चलता था जिसमें (संभवतः कई में से एक) ढेर हो रहा था: http://www.acsac.org/2002/papers/classic-multics.pdf देखें , जो धारा 2.3.2 का अंत है:

तीसरा, मल्टिक्स प्रोसेसर पर स्टैक पॉजिटिव डायरेक्शन में बढ़ा, बजाय नेगेटिव डायरेक्शन के। इसका मतलब यह था कि यदि आप वास्तव में एक बफर अतिप्रवाह को पूरा करते हैं, तो आप अपने स्वयं के रिटर्न पॉइंटर के बजाय अप्रयुक्त स्टैक फ्रेम को ओवरराइट कर देंगे, शोषण को और अधिक कठिन बना देगा।

यह एक दिलचस्प बयान है। क्या केवल "प्रथागत" प्रक्रिया-कॉल-स्टैक-फ्रेम व्यवस्था के कारण बफर ओवरफ्लो इतनी बड़ी समस्या बन गई? इसके अलावा, पूरी तरह से अतुलनीय के रूप में मल्टीिक्स की प्रतिष्ठा कितनी सिर्फ हार्डवेयर डिजाइन की एक झलक थी?

— ब्रूस एडिगर
स्रोत

ठीक है, निष्पादन योग्य स्टैक नहीं होने से संभवतया मल्टीक्स को केवल बुद्धिमान स्टैक दिशा के रूप में मदद मिली, और निश्चित रूप से पीएल / 1 में लिखे गए कई कार्यक्रमों के साथ, स्ट्रिंग ओवरफ्लो भी वास्तव में एक समस्या नहीं थी।

— ग्रेग ए। वुड्स