2013-06-04 6 views
14

सी प्रोग्राम में शून्य से डिवीजन के परिणामस्वरूप त्रुटि संदेश Floating point exception (core dumped) के साथ असामान्य समाप्ति में परिणाम मिलता है। यह फ़्लोटिंग पॉइंट डिवीजन के लिए असुरक्षित है, लेकिन यह क्यों कहता है जब शून्य द्वारा पूर्णांक विभाजन होता है? क्या पूर्णांक विभाजन वास्तव में हुड के तहत एफपीयू का उपयोग करता है?शून्य द्वारा पूर्णांक विभाजन क्यों एक फ्लोटिंग पॉइंट अपवाद में परिणाम देता है?

(यह सभी लिनक्स पर 86 के तहत जिस तरह से है।)

+1

यह ध्यान देने योग्य है कि अन्य गैर-पॉज़िक्स ऑपरेटिंग सिस्टम (जैसे विंडोज) और x86 हार्डवेयर रिपोर्ट पूर्णांक और फ्लोटिंग-पॉइंट विभाजित शून्य के लिए अलग अपवाद हैं। – Crashworks

+0

संबंधित: [किस प्लेटफॉर्म पर शून्य द्वारा पूर्णांक विभाजित करता है एक फ्लोटिंग पॉइंट अपवाद ट्रिगर करता है?] (Https://stackoverflow.com/questions/37262572/on-which-platforms-does-integer-divide-by-zero-trigger- एक-फ्लोटिंग प्वाइंट-exceptio)। टीएल: डीआर: अगर सिग्नल है तो पीओएसआईक्स को एसआईजीएफपीई होने की आवश्यकता है। –

उत्तर

22

पूर्णांक विभाजन वास्तव में हुड के नीचे एफपीयू उपयोग करता है?

नहीं, लिनक्स सिर्फ इस मामले में एसआईजीएफपीई उत्पन्न करता है (यह एक विरासत नाम है जिसका उपयोग अब बढ़ाया गया है)। दरअसल, एकल यूनिक्स विशिष्टता defines SIGFPE "त्रुटिपूर्ण अंकगणितीय ऑपरेशन" के रूप में।

3

man signal का उल्लेख है:

पूर्णांक शून्य से भाग परिणाम अपरिभाषित है। कुछ आर्किटेक्चर पर यह एक एसआईजीएफपीई सिग्नल उत्पन्न करेगा। इस के लिए एक ऐतिहासिक विवरण में (इसके अलावा -1 से सबसे नकारात्मक पूर्णांक विभाजित SIGFPE उत्पन्न हो सकता है।)

1

मेरा अनुमान होगा कि मूल यूनिक्स हार्डवेयर शून्य से पूर्णांक विभाजन पर एक जाल उत्पन्न नहीं किया, इसलिए नाम SIGFPE समझ में आया। (पीडीपी असेंबली प्रोग्रामर, पुष्टि करें?) बाद में जब सिस्टम को एक पूर्णांक डिवीजन-बाय-शून्य जाल के साथ हार्डवेयर में पोर्ट किया गया था (या लिनक्स के मामले में, पुन: कार्यान्वित), तो इसे एक नया सिग्नल नंबर जोड़ने के लिए सार्थक नहीं माना गया था, इसलिए पुराने व्यक्ति ने एक नया अर्थ हासिल किया और अब थोड़ा उलझन वाला नाम है।

0

इसके लिए कई अलग-अलग कार्यान्वयन-विशिष्ट कारण हो सकते हैं।

उदाहरण के लिए, x86 प्लेटफ़ॉर्म पर एफपीयू इकाई तर्क पढ़ने और परिणामों को पढ़ने के लिए फ़्लोटिंग पॉइंट और पूर्णांक प्रारूप दोनों का समर्थन करती है। वापस जब मंच स्वयं 16-बिट था, कुछ कंपेलरों ने 32-बिट पूर्णांक ऑपरेटरों के साथ विभाजन करने के लिए एफपीयू का उपयोग किया (क्योंकि 32-बिट विस्तृत डेटा के लिए कोई सटीक हानि नहीं है)। ऐसी परिस्थितियों में अमान्य 32-बिट पूर्णांक विभाजन के लिए वास्तविक FPU त्रुटि प्राप्त करने में असामान्य कुछ भी नहीं होगा।

+0

एफपी अपवाद सामान्य रूप से मुखौटा होते हैं, इसलिए आपको अपवाद के बजाय एक NaN या +/- Inf परिणाम मिलता है। मुझे आश्चर्य है कि क्या पूर्णांक विभाजन अपवादों के लिए SIGFPE एक्स 86 से पहले शुरू हुआ सम्मेलन/परंपरा? यूनिक्स को x86 तक 386 (संरक्षित मोड) तक ठीक से पोर्ट नहीं किया जा सका, लेकिन कुछ यूनिक्स जैसी वातावरण वास्तविक स्मृति सुरक्षा के बिना मौजूद थीं, मुझे लगता है। –

संबंधित मुद्दे