क्या मेरी लाइब्रेरी खराब सूचक इनपुट पर SIGSEGV को संभालना चाहिए?

Question

मैं एक छोटी पुस्तकालय लिख रहा हूं जो इनपुट के रूप में एक FILE * सूचक लेता है।

यदि मैं तुरंत इस फ़ाइल * सूचक की जांच करता हूं और पाते हैं कि यह एक सेगफॉल्ट की ओर जाता है, तो सिग्नल को संभालने, इरनो सेट करने और गहराई से बाहर निकलने के लिए यह सही है; या कुछ भी करने के लिए और कॉलर के स्थापित सिग्नल हैंडलर का उपयोग करें, अगर उसके पास कोई है?

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

क्या आप इस विश्लेषण से सहमत होंगे, या आप इस स्थिति में SIGSEGV को संभालने के लिए कुछ अनिवार्य कारण देखते हैं?

Answer 1

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

Answer 2

प्रचलित ज्ञान "पुस्तकालयों को कभी भी दुर्घटना नहीं होनी चाहिए।"

मुझे नहीं पता कि आपको यह कहां से मिला - यदि वे एक अवैध सूचक पास करते हैं, तो आपको क्रैश करना चाहिए। कोई पुस्तकालय होगा।

Answer 3

यह एक व्यक्तिपरक सवाल है, और संभवतः एसओ के लिए फिट नहीं है, लेकिन मैं अपनी राय पेश करेंगे:

इस तरह से इसके बारे में सोचो: यदि आप एक समारोह है कि एक नुल-समाप्त char * स्ट्रिंग लेता है और प्रलेखित है है, तो जैसे, और कॉलर नल टर्मिनेटर के बिना एक स्ट्रिंग पास करता है, क्या आपको सिग्नल पकड़ना चाहिए और कलाई पर कॉलर को थप्पड़ मारना चाहिए? या क्या आप इसे दुर्घटनाग्रस्त होने दें और अपने एपीआई का उपयोग करके खराब प्रोग्रामर को अपना कोड ठीक कर दें?

अपने कोड एक FILE * सूचक लेता है, और अपने प्रलेखन कहते हैं, "किसी भी खुले FILE * पारित", और वे एक बंद पास या FILE * वस्तु अवैध, वे अनुबंध टूट गए हैं। इस मामले की जांच करने से उन लोगों के कोड को धीमा कर दिया जाएगा जो आपकी लाइब्रेरी का उचित उपयोग करने वाले लोगों को समायोजित करने के लिए उपयोग करते हैं, जबकि इसे दुर्घटनाग्रस्त होने से दस्तावेज़ को पढ़ने वाले लोगों के लिए जितना तेज़ हो सके कोड और अच्छे कोड लिखते हैं।

क्या आप किसी ऐसे व्यक्ति की अपेक्षा करते हैं जो किसी त्रुटि को सही ढंग से संभालने और सही तरीके से संभालने के लिए FILE * पॉइंटर पास करता है? या क्या वे अंधेरे से आगे बढ़ने की अधिक संभावना रखते हैं, जिसके बाद एक और दुर्घटना हो जाती है, इस मामले में इस दुर्घटना को संभालने में समस्या सिर्फ छिप सकती है?

Answer 4

मैं NULL पॉइंटर के विशेष मामले की जांच करना उचित मानता हूं। लेकिन इससे परे, अगर वे जंक पास करते हैं, तो उन्होंने समारोह के अनुबंध का उल्लंघन किया और उन्हें एक दुर्घटना हो गई।

Answer 5

कर्नेल क्रैश नहीं होना चाहिए यदि आप उन्हें एक खराब सूचक खिलाते हैं, लेकिन पुस्तकालयों को शायद चाहिए। इसका मतलब यह नहीं है कि आपको कोई त्रुटि जांच नहीं करनी चाहिए; एक अच्छा कार्यक्रम अनावश्यक रूप से खराब डेटा के सामने तुरंत मर जाता है। मैं न केवल पॉइंटर पर ट्रंडल करने और अंततः dereference करने के बजाय जोर से एक पुस्तकालय कॉल जमानत (एफ! = एनयूएलएल) के साथ होगा।

Answer 6

क्षमा करें, लेकिन जो लोग लाइब्रेरी कहते हैं उन्हें दुर्घटनाग्रस्त होना चाहिए, शायद आलसी हो (शायद समय के साथ-साथ विकास के प्रयासों में)। पुस्तकालय कार्यों का संग्रह हैं। लाइब्रेरी कोड को आपके सॉफ़्टवेयर में अन्य कार्यों के मुकाबले "बस क्रैश" नहीं करना चाहिए "बस क्रैश" होना चाहिए।

दी, पुस्तकालयों, कैसे एपीआई सीमा पार त्रुटियों पारित करने के लिए चारों ओर कुछ मुद्दों हो सकता है अगर एक से अधिक भाषाओं या (अपेक्षाकृत) अपवाद की तरह विदेशी भाषा सुविधाओं को आम तौर पर शामिल किया जाएगा, लेकिन वहाँ कुछ भी नहीं भी उस के बारे में विशेष है। असल में, यह पुस्तकालय लिखने के बोझ का हिस्सा है, क्योंकि इन-एप्लिकेशन कोड के विपरीत।

छोड़कर जहाँ आप वास्तव में भूमि के ऊपर का औचित्य साबित नहीं कर सकते, प्रणालियों के बीच हर इंटरफ़ेस सुरक्षा के मुद्दों, और साथ ही कीड़े को रोकने के लिए अनुबंध द्वारा विवेक की जाँच, या बेहतर, डिजाइन को लागू करना चाहिए,।

तरीके इस संभाल करने की एक संख्या हैं, तो आप शायद क्या करना चाहिए, वरीयता के क्रम में, में से एक है:

1. एक भाषा है कि अपवाद का समर्थन करता है का उपयोग करें (या बेहतर, अनुबंध द्वारा डिजाइन) पुस्तकालयों के भीतर, और एक अपवाद फेंक या अनुबंध विफल होने की अनुमति दें।

2. एक त्रुटि हैंडलिंग सिग्नल/स्लॉट या हुक/कॉलबैक तंत्र प्रदान करें, और किसी भी पंजीकृत हैंडलर को कॉल करें। इसकी आवश्यकता है, जब आपकी लाइब्रेरी प्रारंभ की जाती है, तो कम से कम एक त्रुटि हैंडलर पंजीकृत होता है।

3. किसी भी कारण से संभवतः विफल होने वाले प्रत्येक फ़ंक्शन में कुछ त्रुटि कोड लौटने में सहायता। लेकिन यह सी से चीजों को करने का पुराना, अपेक्षाकृत पागल तरीका है (सी ++ के विपरीत) दिन।

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