एक ही फाइल डिस्क्रिप्टर के लिए अच्छी तरह से परिभाषित के लिए दो FILEs बना रहा है?

Question

POSIX एक fdopen फ़ंक्शन निर्दिष्ट करता है जो फ़ाइल वर्णनकर्ता के लिए FILE बनाता है। POSIX भी fileno फ़ंक्शन निर्दिष्ट करता है जो FILE के लिए फ़ाइल डिस्क्रिप्टर देता है।

FILE *secondfile(FILE *f, const char *mode) 
{ 
    int fd = fileno(f); 

    return fd >= 0 ? fdopen(fd, mode) : NULL; 
} 

इस POSIX के तहत एक अच्छी तरह से परिभाषित आपरेशन है: साथ में, इन दो एक दूसरे FILE किसी मौजूदा फ़ाइल के समान ही अंतर्निहित फ़ाइल वर्णनकर्ता तक पहुँचने बनाने के लिए इस्तेमाल किया जा सकता है? क्या होता है जब मैं मूल फ़ाइल FILE और दूसरा FILE दोनों को उसी फ़ाइल डिस्क्रिप्टर के लिए उपयोग करता हूं? क्या बातचीत निर्दिष्ट है? यदि हां, तो कैसे?

ऐतिहासिक रूप से, यूनिसेज ने 20 फाइलों के लिए FILE संरचनाओं की एक निश्चित तालिका का उपयोग किया था। fdopen() को एक फ़ाइल डिस्क्रिप्टर पर कॉल करना जो पहले से ही FILE से जुड़ा हुआ है, इस प्रकार मौजूदा फ़ाइल को दूषित कर देगा और अपरिभाषित व्यवहार उत्पन्न करेगा। मुझे यकीन नहीं है कि stdio के इस तरह के कार्यान्वयन को अभी भी POSIX द्वारा अनुमति है, इसलिए मैं इस सवाल से पूछ रहा हूं।

Answer 1

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

POSIX अपरिभाषित व्यवहार से बचने के लिए constraints on how two handles on the same open file description may be used परिभाषित करता है। यह यहां प्रासंगिक है कि उन बाधाओं को वास्तव में हैंडल के लिए कुछ हैं जो फाइल डिस्क्रिप्टर हैं; उनमें से लगभग सभी धाराओं पर लागू होते हैं, और वे मुख्य रूप से बफरिंग से संबंधित स्थितियों के आसपास व्यवस्थित होते हैं। अपवाद स्थिति से संबंधित हैं।

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

Answer 2

एक सामान्य यूनिक्स कार्यान्वयन को देखते हुए, एक फ़ाइल डेटास्क्रिप्टर जिसमें से पढ़ने के लिए फ़ाइल डिस्क्रिप्टर होता है, और बफर के आकार के लिए बफर, और यदि आप बफर के आकार को जानते हैं, और इसे भरने की नीति (जब डेटा की आवश्यकता होती है, बफर खाली होने पर तत्काल नहीं), मैं कहूंगा कि आप निर्धारित कर सकते हैं कि क्या होगा। लेकिन मुझे नहीं पता कि पॉज़िक्स मानक क्या कहता है, और मैं जानता हूं कि किसी प्रोग्राम में उपयोग करना मुश्किल होगा। ("ठीक है, इसलिए मैंने डिस्क पर फ़ाइल से पहले 4096 बाइट्स को में FILE में पढ़ा है, और अगले 4096 बाइट में FILE, और फ़ाइल से तीसरा 4096-बाइट हिस्सा पढ़ा जाएगा FILE जो पहले अपने बफर के अंत तक पहुंचता है और उसे और पढ़ने की जरूरत है ... ")

(मैंने कभी जानबूझकर ऐसा कुछ नहीं किया है, लेकिन मुझे डीबगिंग कोड से ऐसे लक्षण याद आते हैं जिन्हें FILEs और फ़ाइल डिस्क्रिप्टर मिलते हैं मिश्रित।)

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