एक सुरक्षित प्रोग्रामिंग भाषा क्या है?

55

सुरक्षित प्रोग्रामिंग भाषाएँ (PL) लोकप्रियता प्राप्त कर रही हैं। मुझे आश्चर्य है कि सुरक्षित पीएल की औपचारिक परिभाषा क्या है । उदाहरण के लिए, सी सुरक्षित नहीं है, लेकिन जावा सुरक्षित है। मुझे संदेह है कि संपत्ति "सुरक्षित" को पीएल के बजाय पीएल कार्यान्वयन पर लागू किया जाना चाहिए। यदि हां, तो आइए सुरक्षित पीएल कार्यान्वयन की परिभाषा पर चर्चा करें। इस धारणा को औपचारिक रूप देने के लिए मेरे स्वयं के प्रयासों ने एक अजीब परिणाम दिया, इसलिए मैं अन्य राय सुनना चाहूंगा। कृपया, यह न कहें कि हर PL में असुरक्षित कमांड हैं। हम हमेशा एक सुरक्षित सबसेट ले सकते हैं।

programming-languages

— beroal
स्रोत

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— गिल्स एसओ- बुराई को रोकना '

"हम हमेशा एक सुरक्षित सबसेट ले सकते हैं" आप यह कैसे सुनिश्चित कर सकते हैं कि परिणामी भाषा अभी भी ट्यूरिंग-पूर्ण है? (जो कि आमतौर पर "प्रोग्रामिंग लैंग्वेज" से

— अभिप्राय है

"संपत्ति" सुरक्षित "को पीएल के बजाय पीएल कार्यान्वयन के लिए लागू किया जाना चाहिए" - आप पीएल को कॉल कर सकते हैं यदि इसका सुरक्षित कार्यान्वयन मौजूद है।

— दिमित्री ग्रिगोरीव

17

जब हम किसी भाषा को कुछ मामलों में "सुरक्षित" कहते हैं , तो औपचारिक रूप से इसका अर्थ है कि इस बात का प्रमाण है कि भाषा में कोई भी अच्छी तरह से गठित कार्यक्रम कुछ ऐसा नहीं कर सकता है जिसे हम खतरनाक मानते हैं। शब्द "सुरक्षित" का भी औपचारिक रूप से कम उपयोग किया जाता है, लेकिन यही लोग यहां आपके प्रश्न का मतलब समझते हैं। गुणों की कई अलग-अलग परिभाषाएँ हैं जिन्हें हम "सुरक्षित" भाषा चाहते हैं।

कुछ महत्वपूर्ण हैं:

एंड्रयू राइट और मैथियास फेलेसेन की परिभाषा "टाइप साउंडनेस" की परिभाषा है , जिसे कई प्रकारों में उद्धृत किया गया है (विकिपीडिया सहित) "स्वीकृत सुरक्षा" की स्वीकृत परिभाषा के रूप में, और उनके 1994 का प्रमाण है कि एमएल का एक सबसेट इससे मिलता है।
माइकल हिक्स यहाँ "स्मृति सुरक्षा" की कई परिभाषाओं को सूचीबद्ध करता है । कुछ त्रुटियों के प्रकारों की सूची है जो नहीं हो सकती हैं, और कुछ क्षमता के रूप में संकेतकर्ताओं के उपचार पर आधारित हैं। जावा गारंटी देता है कि उन सभी में से कोई भी त्रुटि संभव नहीं है (जब तक कि आप स्पष्ट रूप से चिह्नित सुविधा का उपयोग नहीं करते हैं) तब तक unsafeकचरा संग्रहकर्ता सभी आवंटन और सौदे का प्रबंधन करता है। रस्ट एक ही गारंटी देता है (फिर से, जब तक कि आप स्पष्ट रूप से कोड के रूप में चिह्नित नहीं करते हैं unsafe), इसके affine प्रकार प्रणाली के माध्यम से, जिसे एक बार उपयोग किए जाने से पहले एक चर की आवश्यकता होती है।
इसी तरह, थ्रेड-सुरक्षित कोड को आमतौर पर कोड के रूप में परिभाषित किया जाता है जो कुछ प्रकार के बग को थ्रेड और साझा मेमोरी को शामिल नहीं कर सकता है, जिसमें डेटा रेस और गतिरोध शामिल हैं। इन गुणों को अक्सर भाषा के स्तर पर लागू किया जाता है: जंग गारंटी देती है कि डेटा प्रकार अपने सिस्टम में नहीं हो सकता है, C ++ गारंटी देता है कि std::shared_ptrएक ही ऑब्जेक्ट के कई थ्रेड्स में उसके स्मार्ट पॉइंटर्स किसी ऑब्जेक्ट को समय से पहले नहीं हटाएंगे या अंतिम संदर्भ में इसे हटाने में विफल रहेंगे इसे नष्ट कर दिया जाता है, C और C ++ में अतिरिक्त रूप atomicसे भाषा में निर्मित चर होते हैं, जिनके सही प्रकार से उपयोग किए जाने पर कुछ प्रकार की मेमोरी-संगति लागू करने के लिए परमाणु संचालन की गारंटी दी जाती है। MPI स्पष्ट संदेशों के लिए इंटरप्रोसेस संचार को प्रतिबंधित करता है, और ओपनएमपी का सिंटैक्स है यह सुनिश्चित करने के लिए कि विभिन्न थ्रेड्स से चर तक पहुंच सुरक्षित है।
जिस प्रॉपर्टी की मेमोरी कभी लीक नहीं होगी, उसे अक्सर सेफ-फॉर-स्पेस कहा जाता है। यह सुनिश्चित करने के लिए स्वचालित कचरा संग्रह एक भाषा सुविधा है।
कई भाषाओं की गारंटी है कि इसके संचालन में अच्छी तरह से परिभाषित परिणाम होंगे और इसके कार्यक्रमों को अच्छी तरह से व्यवहार किया जाएगा। जैसा कि सुपरकैट ने ऊपर का एक उदाहरण दिया है, सी अहस्ताक्षरित अंकगणित (सुरक्षित रूप से चारों ओर लपेटने की गारंटी) के लिए करता है, लेकिन हस्ताक्षरित अंकगणित नहीं (जहां अतिप्रवाह मनमाने ढंग से कीड़े पैदा करने की अनुमति है, क्योंकि सी को सीपीयू का समर्थन करने की आवश्यकता है जो अंकगणित पर बेतहाशा अलग-अलग काम करते हैं। ओवरफ्लो), लेकिन फिर भाषा कभी-कभी चुपचाप हस्ताक्षरित लोगों को अहस्ताक्षरित मात्रा में परिवर्तित कर देती है।
कार्यात्मक भाषाओं की एक बड़ी संख्या है कि किसी भी अच्छी तरह से बनाए गए कार्यक्रम को बनाए रखने की गारंटी दी जाती है, उदाहरण के लिए, शुद्ध कार्य दुष्प्रभाव पैदा नहीं कर सकते हैं। इन्हें "सुरक्षित" के रूप में वर्णित किया जा सकता है या नहीं भी किया जा सकता है।
कुछ भाषाएं, जैसे स्पार्क या ओकेएमएल, प्रोग्राम की शुद्धता साबित करने के लिए डिज़ाइन की गई हैं। यह बग से "सुरक्षित" के रूप में वर्णित किया जा सकता है या नहीं।
सबूत है कि एक प्रणाली एक औपचारिक सुरक्षा मॉडल का उल्लंघन नहीं कर सकती है (इसलिए क्विप, "कोई भी प्रणाली जो संभवतः सुरक्षित है, शायद नहीं है")।

— Davislor
स्रोत

1

यह बग से "सुरक्षित" के रूप में वर्णित किया जा सकता है या नहीं। क्या आप कृपया इसे थोड़ा विस्तृत करेंगे? "कीड़े से" आपका क्या मतलब है?

— स्काउहू

2

@scaaahu यहां एक वेबसाइट का उदाहरण है, जो औपचारिक रूप से सही साबित होने वाले सॉफ़्टवेयर को "सही मायने में सुरक्षित" के रूप में संदर्भित करता है। इस संदर्भ में, यह विमान को टकराने से रोकने के लिए सॉफ़्टवेयर का संदर्भ दे रहा है, इसलिए इसका अर्थ टकरावों से सुरक्षित है।

— डेविसोर

1

मैं इस उत्तर को स्वीकार कर रहा हूं क्योंकि यह सुरक्षा के प्रकारों को सूचीबद्ध करता है। मेरे दिमाग में जो प्रकार था वह है मेमोरी सेफ्टी।

— बिराल

हालांकि यह उत्तर कुछ सहायक लिंक और बहुत सारे उदाहरणों को सूचीबद्ध करता है, लेकिन उनमें से अधिकांश पूरी तरह से गड़बड़ हैं। कचरा संग्रह यह सुनिश्चित करता है कि मेमोरी कभी भी "असुरक्षित" ब्लॉकों का उपयोग नहीं करेगी या नहीं होगी, यह स्वचालित रूप से आपको सुरक्षा प्रदान करता है या हस्ताक्षरित अतिप्रवाह होने के कारण अपरिभाषित व्यवहार करता है क्योंकि С संकलक को कुछ अजीब सीपीयू का समर्थन करने की आवश्यकता है, गंभीरता से? और अडा / स्पार्क के लिए एक संक्षिप्त शब्द जो उल्लेखित भाषाओं में से केवल एक है जो सुरक्षा को गंभीरता से लेता है।

— वीटीटी

94

"सुरक्षित प्रोग्रामिंग भाषा" की कोई औपचारिक परिभाषा नहीं है; यह एक अनौपचारिक धारणा है। बल्कि, ऐसी भाषाएँ जो सुरक्षा प्रदान करने का दावा करती हैं, आमतौर पर एक सटीक औपचारिक विवरण प्रदान करती हैं कि किस प्रकार की सुरक्षा का दावा / गारंटी / प्रदान किया जा रहा है। उदाहरण के लिए, भाषा प्रकार सुरक्षा, स्मृति सुरक्षा, या कुछ अन्य समान गारंटी प्रदान कर सकती है।

— DW
स्रोत

13

एक परिशिष्ट के रूप में, अगर हम ओ बनाम पोस्ट की तरह सी बनाम जावा के बारे में बात करते हैं: यह मेमोरी सुरक्षा है जो जावा में गारंटी है और सी में नहीं है। टाइप सुरक्षा दोनों में अपने तरीके से प्रदान की जाती है। (यह पढ़ने वाले बहुत सारे लोग पहले से ही जानते हैं, लेकिन शायद कुछ नहीं)।

— वालफ्रैट

17

@Walfrat इसका हिस्सा है। जावा का कोई अपरिभाषित व्यवहार भी नहीं है, जो कि हम एक ऐसी भाषा से उम्मीद करते हैं जो खुद को 'सुरक्षित' कहती है। टाइप सिस्टम के लिए, मुझे नहीं लगता कि एक मजबूत स्टेटिक टाइप सिस्टम है जो लोग 'सुरक्षित' से मतलब रखते हैं। डायनामिक रूप से टाइप की गई भाषाएं जैसे पायथन आमतौर पर 'सुरक्षित' हैं।

— मैक्स बैरक्लोफ

2

प्रकार की सुरक्षा की मेरी परिभाषा संकलन जांच है जो संभालती है। वह औपचारिक परिभाषा नहीं हो सकती है। ध्यान दें कि मैंने "सुरक्षा" टाइप किया, "सुरक्षित" नहीं। मेरे लिए "सुरक्षित" भाषा "प्रकार और स्मृति सुरक्षा" की "मेरी" परिभाषा को संदर्भित करती है और मुझे लगता है कि यह सबसे व्यापक हो सकती है। बेशक, मैं सी में प्रतिबिंब / शून्य सूचक की तरह कुछ नुकसान की बात नहीं कर रहा हूं कि संकलन संभाल नहीं सकता है। सेफ़ की एक और संभावित परिभाषा ऐसे प्रोग्राम हैं जो सी में यूनिटाइज्ड पॉइंटर की तरह सेगमेंट फॉल्ट से क्रैश नहीं होते हैं। ऐसी चीजें जो आमतौर पर पायथन और जावा में दी जाती हैं।

— वालफ्रैट

7

@Walfrat वह सब जो आपको मिलता है हालांकि एक ऐसी भाषा है जहाँ वाक्य रचना अच्छी तरह से परिभाषित है। यह गारंटी नहीं देता है कि निष्पादन अच्छी तरह से परिभाषित है - और एक जेआरई दुर्घटना को मैंने कितनी बार देखा है, मैं आपको फ्लैट से बाहर बता सकता हूं कि एक प्रणाली के रूप में यह "सुरक्षित" नहीं है। दूसरी ओर C में, MISRA ने भाषा के एक सुरक्षित उप-स्तर को प्राप्त करने के लिए अपरिभाषित व्यवहार से बचने के लिए काम किया है, और C में असेंबलर का संकलन बहुत बेहतर परिभाषित किया गया है। तो यह इस बात पर निर्भर करता है कि आप "सुरक्षित" क्या मानते हैं।

— ग्राहम

5

@MaxBarraclough - "Java का कोई अपरिभाषित व्यवहार भी नहीं है" - भाषा परिभाषा में C विशिष्टताओं में प्रयुक्त अर्थ में Java का कोई अपरिभाषित व्यवहार नहीं है (हालाँकि यह कुछ कोडों को उन मानों को उत्पन्न करने की अनुमति देता है जिनमें एक भी पूर्वनिर्धारित मूल्य नहीं है, जैसे कि एक्सेस करना एक वैरिएबल जिसे दूसरे थ्रेड में संशोधित किया जा रहा है, या एक्सेस करते समय doubleया longकिसी अन्य थ्रेड में संशोधित किया जा रहा है, जो किसी दूसरे के आधे के साथ कुछ अनिर्दिष्ट तरीके से मिश्रित एक मूल्य का आधा उत्पादन नहीं करने की गारंटी नहीं है) लेकिन एपीआई विनिर्देश हालांकि कुछ मामलों में अपरिभाषित व्यवहार किया गया है।

— जूल्स

42

यदि आप अपने हाथों को बेंजामिन पियर्स के प्रकारों और प्रोग्रामिंग भाषाओं की एक प्रति पर प्राप्त कर सकते हैं , तो परिचय में, उनके पास "सुरक्षित भाषा" शब्द पर विभिन्न दृष्टिकोणों पर एक अच्छा अवलोकन है।

शब्द की एक प्रस्तावित व्याख्या जो आपको दिलचस्प लग सकती है:

"एक सुरक्षित भाषा पूरी तरह से अपने प्रोग्रामर के मैनुअल द्वारा परिभाषित की जाती है।" भाषा की परिभाषा को उन चीजों के सेट होने दें, जिन्हें प्रोग्रामर को भाषा में हर प्रोग्राम के व्यवहार की भविष्यवाणी करने के लिए समझने की आवश्यकता होती है। तब सी जैसी भाषा के लिए मैनुअल की परिभाषा नहीं होती है, क्योंकि कुछ कार्यक्रमों के व्यवहार (जैसे, अनियंत्रित सरणी एक्सेस या पॉइंटर अंकगणित वाले) को किसी विशेष सी कंपाइलर मेमोरी में संरचनाओं को बाहर निकालने के विवरण के बिना भविष्यवाणी नहीं की जा सकती है। , आदि, और एक ही कार्यक्रम में अलग-अलग संकलक द्वारा निष्पादित किए जाने पर काफी भिन्न व्यवहार हो सकते हैं।

इसलिए, मुझे प्रोग्रामिंग भाषा के कार्यान्वयन को संदर्भित करने के लिए "असुरक्षित" शब्द का उपयोग करने में संकोच होगा। यदि किसी भाषा में एक अपरिभाषित शब्द अलग-अलग कार्यान्वयन में भिन्न व्यवहार का उत्पादन करता है, तो कार्यान्वयन में से एक उत्पाद व्यवहार हो सकता है जो अधिक अपेक्षित हो, लेकिन मैं इसे "सुरक्षित" नहीं कहूंगा।

— मार्टिन
स्रोत

7

हाल्टिंग प्रॉब्लम ऑफ़ कोर्स का कहना है कि भाषा कोई भी हो, हमेशा ऐसे कार्यक्रम होंगे जिनका व्यवहार भाषा की परिभाषा से अनुमानित नहीं है। तो कोई भी परिभाषा जो "भाषा में हर कार्यक्रम के व्यवहार की भविष्यवाणी" पर टिका है, किसी भी ट्यूरिंग-पूर्ण भाषा के लिए मौलिक रूप से त्रुटिपूर्ण है।

— एमएसलटर्स

15

@MSalters यह हॉल्टिंग समस्या की एक लोकप्रिय गलतफहमी है। हॉल्टिंग समस्या की अनिर्वायता का अर्थ है कि ट्यूरिंग-पूर्ण भाषा में एक मनमाना कार्यक्रम के व्यवहार को यंत्रवत् रूप से प्राप्त करना असंभव है । लेकिन यह संभव है कि किसी भी कार्यक्रम के लिए, व्यवहार पूर्वानुमान योग्य हो। यह सिर्फ इतना है कि आप एक कंप्यूटर प्रोग्राम नहीं बना सकते हैं जो यह भविष्यवाणी करता है।

— गिलेस एसओ- बुराई को रोकना '

7

@ गिल्स: ऐसी बात नहीं है। मान लीजिए कि हर गैर-समाप्ति कार्यक्रम के लिए गैर-समाप्ति का प्रमाण मौजूद है। फिर आप किसी दिए गए प्रोग्राम को रोक सकते हैं या नहीं, यह जानने के लिए गैर-समाप्ति के प्रमाणों की गणना कर सकते हैं। तो रुकने की समस्या विकट है। अंतर्विरोध। इस प्रकार कुछ नॉन-टर्मिनेटिंग प्रोग्राम्स नॉन-टर्मिनेटिंग नहीं हैं।

— केविन

9

@ गिल्स: मैं इस तथ्य से पूरी तरह से वाकिफ हूं कि कई कार्यक्रम तुच्छ साबित होते हैं या नहीं। लेकिन यहां बयान शाब्दिक रूप से हर कार्यक्रम के व्यवहार के बारे में है । हाल्टिंग प्रमेय का प्रमाण दिखाता है कि कम से कम एक कार्यक्रम मौजूद है जिसके लिए यह सच नहीं है। यह सिर्फ एक गैर-रचनात्मक प्रमाण है, यह आपको नहीं बताएगा कि कौन सा कार्यक्रम अनिर्दिष्ट है।

— मसलक

8

@ मायर्स मुझे लगता है कि निहित बिट यह है कि बयान कार्यक्रम के छोटे पैमाने पर व्यवहार के बारे में है, बजाय बड़े पैमाने पर, आकस्मिक व्यवहार के। उदाहरण के लिए, Collatz अनुमान को लें । एल्गोरिथ्म के व्यक्तिगत चरण सरल और अच्छी तरह से परिभाषित हैं, लेकिन आकस्मिक व्यवहार (रुकने तक कितने पुनरावृत्तियों, और यदि यह बिल्कुल भी होता है), लेकिन कुछ भी है। - "भविष्यवाणी" यहाँ अनौपचारिक रूप से उपयोग की जा रही है। यह बेहतर लिखा जा सकता है "किसी अनियंत्रित कार्यक्रम में किसी भी दिए गए कथन को कैसे निष्पादित किया जाएगा, यह जान लें।"

— आरएम

18

सुरक्षित बाइनरी नहीं है, यह एक निरंतरता है ।

अनौपचारिक रूप से कहा जाए, तो सुरक्षा का मतलब बग के विरोध से है, 2 सबसे अधिक बार उल्लेख किया जा रहा है:

मेमोरी सेफ्टी: भाषा और इसके कार्यान्वयन में मेमोरी संबंधित त्रुटियों की एक किस्म जैसे कि उपयोग-बाद में मुफ्त, डबल-फ्री, आउट-ऑफ-बाउंड्स एक्सेस, ...
टाइप सेफ्टी: भाषा और इसके कार्यान्वयन से विभिन्न प्रकार की संबंधित त्रुटियों जैसे अनियंत्रित जातियों, ...

उन बगों का एकमात्र वर्ग नहीं है जिन्हें भाषाएं रोकती हैं, डेटा-रेस स्वतंत्रता या गतिरोध स्वतंत्रता बल्कि वांछनीय है, शुद्धता के प्रमाण बहुत मीठे हैं, आदि ...

सीधे शब्दों में गलत कार्यक्रमों को शायद ही कभी माना जाता है "असुरक्षित" तथापि (केवल गाड़ी), और अवधि सुरक्षा आम तौर पर करने की क्षमता को प्रभावित करने की गारंटी देता है के लिए आरक्षित है कारण एक कार्यक्रम के बारे में। इस प्रकार, C, C ++ या Go, अनिर्धारित व्यवहार होने के कारण असुरक्षित हैं।

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

— मैथ्यू एम।
स्रोत

7

मैं कहूंगा कि यह एक जाली है।

— पट जूल

1

अधिकांश प्रोग्रामिंग भाषाओं के कार्यान्वयन में असुरक्षित विशेषताएं हैं (जैसे Obj.magicOcaml में)। और व्यवहार में, इनकी वास्तव में आवश्यकता होती है

— बेसिल स्टैरिनेविच

4

@ बैसिलिस्टारिनकेविच: वास्तव में। मुझे लगता है कि एफएफआई के साथ किसी भी भाषा में आवश्यक रूप से असुरक्षित के कुछ स्तर होते हैं, क्योंकि सी फ़ंक्शन को कॉल करने के लिए "पाइनिंग" जीसी'एड वस्तुओं की आवश्यकता होगी और मैन्युअल रूप से यह सुनिश्चित करना होगा कि दोनों तरफ के हस्ताक्षर मेल खाते हैं।

— मैथ्यू एम।

15

जबकि मैं डीडब्ल्यू के जवाब से असहमत नहीं हूं, मुझे लगता है कि यह "सुरक्षित" के एक हिस्से को बिना सोचे समझे छोड़ देता है।

जैसा कि कहा गया है, कई प्रकार की सुरक्षा को बढ़ावा दिया जाता है। मेरा मानना है कि यह समझना अच्छा है कि कई धारणाएँ क्यों हैं। प्रत्येक धारणा इस विचार से जुड़ी हुई है कि कार्यक्रम विशेष रूप से बगों के एक निश्चित वर्ग से पीड़ित हैं, और यदि प्रोग्रामर ने प्रोग्रामर को ऐसा करने से रोका तो यह विशिष्ट प्रकार के बग को बनाने में असमर्थ होगा।

यह ध्यान दिया जाना चाहिए कि इन विभिन्न धारणाओं में कीड़े के विभिन्न वर्ग हैं, और ये वर्ग परस्पर अनन्य नहीं हैं और न ही ये वर्ग सभी प्रकार के बगों को कवर करते हैं। बस DW के 2 उदाहरण लेने के लिए, यह सवाल कि क्या एक निश्चित मेमोरी लोकेशन एक निश्चित ऑब्जेक्ट है, दोनों प्रकार की सुरक्षा और मेमोरी सुरक्षा का प्रश्न है।

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

— MSalters
स्रोत

10

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

— गिल्स एसओ- बुराई को रोकना '

3

मैं इस पर MSalters के साथ हूँ। - "सुरक्षित भाषाएं आपको लाइब्रेरी लेखक से अधिक गारंटी देती हैं और आपको अधिक आश्वासन देती हैं कि आप उनका सही उपयोग कर रहे हैं।" यह सभी व्यावहारिक उद्देश्यों के लिए एक गैर क्रम है।

— कप्तान जिराफ

9

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

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

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

 uint32_t test(uint16_t x)
 {
   if (x < 50000) foo(x);
   return x*x; // Note x will promote to "int" if that type is >16 bits.
 }

एक "आधुनिक" सी कंपाइलर जैसा कुछ ऊपर दिया गया है, यह निष्कर्ष निकाल सकता है कि चूंकि x * x की गणना अतिप्रवाह है यदि x 46340 से अधिक है, तो यह बिना शर्त के "foo" कॉल कर सकता है। ध्यान दें कि यहां तक कि अगर x के दायरे से बाहर होने पर किसी प्रोग्राम को असामान्य रूप से समाप्त करना स्वीकार्य होगा, या ऐसे मामलों में फ़ंक्शन का कोई भी मूल्य वापस आ सकता है, तो आउट-ऑफ-रेंज x के साथ फू () कॉलिंग से नुकसान हो सकता है। या तो उन संभावनाओं के। पारंपरिक सी प्रोग्रामर और अंतर्निहित प्लेटफॉर्म की आपूर्ति से परे कोई सुरक्षा गियर प्रदान नहीं करेगा, लेकिन सुरक्षा गियर को अप्रत्याशित परिस्थितियों से नुकसान को सीमित करने की अनुमति देगा। आधुनिक सी किसी भी सुरक्षा गियर को बाईपास करेगा जो सब कुछ नियंत्रण में रखने पर 100% प्रभावी नहीं है।

— supercat
स्रोत

3

@ डैडीथॉर्नले: शायद मेरा उदाहरण बहुत सूक्ष्म था। यदि int32 बिट्स है, तो xहस्ताक्षरित को बढ़ावा मिलेगा int। औचित्य को देखते हुए, मानक के लेखकों ने उम्मीद की कि गैर-अजीब कार्यान्वयन कुछ विशिष्ट मामलों के बाहर समकक्ष और अहस्ताक्षरित प्रकारों के साथ व्यवहार करेंगे, लेकिन कभी-कभी उन तरीकों से "अनुकूलन" करते हैं जो टूट जाते हैं यदि एक परिणाम से कई गुना बढ़ uint16_tजाता uint16_tहै। यहां तक कि जब परिणाम को एक अहस्ताक्षरित मूल्य के रूप में इस्तेमाल किया जा रहा हो।

— Supercat

4

अच्छा उदाहरण। यह एक कारण है कि हमें हमेशा (जीसीसी या क्लैंग पर) संकलन क्यों करना चाहिए -Wconversion।

— डेविसोर

2

@ डेविड: आह, मैंने अभी देखा कि गॉडबोल्ट ने उस क्रम को उलट दिया जिसमें संकलक संस्करण सूचीबद्ध हैं, इसलिए सूची में जीसीसी के अंतिम संस्करण का चयन करने से जल्द से जल्द नवीनतम पैदावार मिलती है। मुझे नहीं लगता कि चेतावनी विशेष रूप से उपयोगी है क्योंकि इसमें बहुत सारी स्थितियों को चिह्नित करने की संभावना है, जैसे return x+1;कि समस्यात्मक नहीं होना चाहिए, और परिणाम को कास्टिंग करने के लिए uint32_t समस्या को ठीक किए बिना संदेश को रोक देगा।

— सुपरकैट

2

यदि परीक्षण करने वाले को अलग स्थान पर वापस रखना आवश्यक हो तो @supercat परीक्षण समाप्त करना व्यर्थ है।

— user253751

3

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

— सुपरकैट

7

एक भाषा में शुद्धता की कई परतें होती हैं। बढ़ते अमूर्त के क्रम में:

कुछ प्रोग्राम त्रुटि मुक्त होते हैं (केवल जिनके लिए शुद्धता साबित की जा सकती है)। दूसरों ने पहले ही उल्लेख किया कि त्रुटि रोकथाम इसलिए सबसे ठोस सुरक्षा पहलू है। जावा और .net जैसी वर्चुअल मशीन में चलने वाली भाषाएँ आम तौर पर इस संबंध में अधिक सुरक्षित होती हैं: प्रोग्राम की त्रुटियों को आम तौर पर एक परिभाषित तरीके से इंटरसेप्ट और हैंडल किया जाता है। ¹
अगले स्तर पर, रन टाइम के बजाय संकलन समय पर पाई गई त्रुटियां भाषा को सुरक्षित बनाती हैं। एक सिंटैक्टिकली सही प्रोग्राम भी शब्दार्थ रूप से यथासंभव सही होना चाहिए। बेशक संकलक बड़ी तस्वीर को नहीं जान सकता है, इसलिए यह विस्तार स्तर की चिंता करता है। मजबूत और स्पष्ट डेटा प्रकार इस स्तर पर सुरक्षा का एक पहलू है। कोई कह सकता है कि भाषा को कुछ विशेष प्रकार की त्रुटियां करने के लिए कठिन बनाना चाहिए(टाइप त्रुटियां, आउट-ऑफ बाउंड एक्सेस, अनइंस्टाल्यूटेड वैरिएबल आदि)। रन-टाइम प्रकार की जानकारी जैसे सरणियाँ जो लंबाई की जानकारी लेती हैं, त्रुटियों से बचती हैं। मैंने Ada 83 को कॉलेज में क्रमादेशित किया और पाया कि एक आकर्षक Ada कार्यक्रम में आमतौर पर संबंधित C प्रोग्राम की तुलना में कम त्रुटियों का परिमाण होता है। बस उपयोगकर्ता के परिभाषित पूर्णांक प्रकारों के लिए एडा की क्षमता को लें जो कि स्पष्ट रूपांतरण के बिना असाइन करने योग्य नहीं हैं: पूरे अंतरिक्ष जहाज दुर्घटनाग्रस्त हो गए हैं क्योंकि पैर और मीटर भ्रमित थे, जिसे कोई भी एडीए के साथ तुच्छता से बच सकता है।
अगले स्तर पर, भाषा को बॉयलरप्लेट कोड से बचने के लिए साधन प्रदान करना चाहिए। यदि आपको अपने स्वयं के कंटेनर, या उनकी छँटाई, या उनके संगति को लिखना है, या यदि आपको अपना स्वयं का लिखना है तो आप string::trim()गलतियाँ करेंगे। चूंकि अमूर्त स्तर बढ़ जाता है, इस मानदंड में भाषा के साथ-साथ भाषा का मानक पुस्तकालय भी शामिल होता है।
इन दिनों भाषा को भाषा के स्तर पर समवर्ती प्रोग्रामिंग के लिए साधन उपलब्ध कराने चाहिए। भाषा के समर्थन के बिना सही और सही तरीके से करना असंभव है।
भाषा को संशोधन और सहयोग के लिए साधन उपलब्ध कराने चाहिए। उपर्युक्त मदद से मजबूत, विस्तृत, उपयोगकर्ता-परिभाषित प्रकार, एक्सप्रेसिव एपीआई बनाने में मदद करते हैं।

कुछ हद तक रूढ़िवादी रूप से भाषा की परिभाषा समझदार होनी चाहिए; भाषा और पुस्तकालयों को अच्छी तरह से प्रलेखित किया जाना चाहिए। खराब या गुम प्रलेखन खराब और गलत कार्यक्रमों की ओर जाता है।

_{¹ लेकिन क्योंकि आमतौर पर आभासी मशीन की शुद्धता साबित नहीं की जा सकती है ऐसी भाषाएं कुछ हद तक विरोधाभासी रूप से बहुत सख्त सुरक्षा आवश्यकताओं के लिए उपयुक्त नहीं हो सकती हैं।}

— पीटर - मोनिका को बहाल करें
स्रोत

1

+1 परत स्पष्टीकरण द्वारा स्पष्ट परत के लिए। आपके लिए एक प्रश्न, पूरे अंतरिक्ष जहाज दुर्घटनाग्रस्त हो गए हैं क्योंकि पैर और मीटर उलझन में थे, जिसे कोई भी आद्या के साथ तुच्छता से बच सकता था। क्या आप सरल गणित त्रुटि के कारण मार्स प्रोब लॉस्ट के बारे में बात कर रहे हैं ? क्या आप उस स्पेस शिप के लिए जिस भाषा का इस्तेमाल कर रहे थे, क्या आप जानते हैं

— स्काउहू

2

@scaaahu हां, मुझे लगता है कि मैं उस का जिक्र कर रहा था। नहीं, मैं भाषा नहीं जानता। दरअसल, रिपोर्ट को पढ़ते हुए, ऐसा लगता है कि जांच द्वारा भेजे गए डेटा को पृथ्वी पर सॉफ्टवेयर द्वारा संसाधित किया गया था जो एक डेटा फ़ाइल का निर्माण करता था जो तब थ्रेशोल्ड स्तर निर्धारित करने के लिए उपयोग किया जाता था। इस परिदृश्य में सरल भाषा टाइपिंग लागू नहीं है। Btw।, उनके पास ग्राउंड सॉफ्टवेयर और डेटा फ़ाइल प्रारूप के साथ कई मुद्दे थे, एक भ्रम जो समस्या का जल्द पता लगाने से रोकता था। इसलिए कहानी मजबूत टाइपिंग के लिए एक सीधा तर्क नहीं है, लेकिन फिर भी एक सतर्क कहानी है।

— पीटर -

1

कृपया, यह न कहें कि हर PL में असुरक्षित कमांड हैं। हम हमेशा एक सुरक्षित सबसेट ले सकते हैं।

हर भाषा जो मुझे पता है कि अवैध कार्यक्रम लिखने के तरीके हैं (संकलित और चलाए जा सकते हैं)। और मुझे पता है कि हर भाषा एक सुरक्षित सबसेट है। तो, वास्तव में आपका सवाल क्या है?

सुरक्षा बहुआयामी और व्यक्तिपरक है।

कुछ भाषाओं में बहुत सारे ऑपरेशन हैं जो "असुरक्षित" हैं। दूसरों के पास इस तरह के ऑपरेशन कम होते हैं। कुछ भाषाओं में, कुछ करने का डिफ़ॉल्ट तरीका स्वाभाविक रूप से असुरक्षित होता है। दूसरों में, डिफ़ॉल्ट तरीका सुरक्षित है। कुछ भाषाओं में, एक स्पष्ट "असुरक्षित" सबसेट है। अन्य भाषाओं में, ऐसा कोई सबसेट नहीं है।

कुछ भाषाओं में, "सुरक्षा" विशेष रूप से स्मृति सुरक्षा को संदर्भित करता है - मानक पुस्तकालय और / या रनटाइम द्वारा प्रदान की जाने वाली सेवा जहां मेमोरी एक्सेस उल्लंघन को मुश्किल या असंभव बना दिया जाता है। अन्य भाषाओं में, "सुरक्षा" में स्पष्ट रूप से थ्रेड सुरक्षा शामिल है। अन्य भाषाओं में, "सुरक्षा" गारंटी को संदर्भित करता है कि एक कार्यक्रम दुर्घटनाग्रस्त नहीं होगा (एक आवश्यकता जिसमें किसी भी प्रकार के अपवाद नहीं छोड़ना शामिल है)। अंत में, कई भाषाओं में "सुरक्षा" प्रकार की सुरक्षा को संदर्भित करता है - यदि प्रकार प्रणाली कुछ मायनों में सुसंगत है, तो इसे "ध्वनि" कहा जाता है (संयोग से, जावा और सी # में पूरी तरह से ध्वनि प्रकार प्रणाली नहीं है)।

और कुछ भाषाओं में, "सुरक्षा" के सभी अलग-अलग अर्थों को प्रकार की सुरक्षा का सबसेट माना जाता है (जैसे कि जंग और टट्टू प्रकार प्रणाली के गुणों के माध्यम से धागा सुरक्षा प्राप्त करते हैं)।

— थियोडोरोस चट्जिगियानकिस
स्रोत

-1

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

— अधिकतम शक्ति
स्रोत