जुना WinINet प्रॉक्सी हेल्पर 64-बिट बिल्डमध्ये का तुटतो

एक कास्ट सामान्य वाटणाऱ्या प्रॉक्सी-सेटिंग्ज हेल्परला आर्किटेक्चर-अवलंबून अपयशात बदलू शकतो:

current = (IntPtr)((int)current + optionSize);

ती कोड पुढील रचनेचा आकार जोडण्यापूर्वी मूळ पत्ता 32-बिट पूर्णांकात आकुंचित करते. 64-बिट प्रक्रिया न बसणारे पत्ते ठेवू शकते. रूपांतरण आणि मूल्यानुसार निकाल ओव्हरफ्लो अपवाद किंवा अवैध पत्ता असू शकतो. बिल्ड x86 वर परत आणल्यास चूक लपू शकते, पण इंटरऑप अंमलबजावणी त्या उपायावर अवलंबून राहते.

पत्ते पॉइंटर-आकारात ठेवा. उदाहरणार्थ, आधीच वाटप केलेल्या अ‍ॅरेमधून पुढे जाण्यासाठी हे वापरता येते:

IntPtr item = IntPtr.Add(buffer, checked(index * optionSize));

ऑफसेट पूर्णांक राहतो; पत्ता स्वतः त्यातून दाबला जात नाही. वाटपाचा आकार आणि निर्देशांक अजूनही वैध असणे आवश्यक आहे.

मग आसपासच्या घोषणा तपासा

WinINet च्या प्रति-कनेक्शन पर्यायांमध्ये एक युनियन आहे ज्याच्या सदस्यांमध्ये DWORD, स्ट्रिंग पॉइंटर आणि FILETIME समाविष्ट आहेत. पॉइंटर फील्डला IntPtr आवश्यक आहे; DWORD फील्ड 32-बिट राहतात. मूळ संरेखन महत्त्वाचे आहे, म्हणून प्रत्येक पूर्णांक 64-बिट पूर्णांकाने बदलणे किंवा पॅक केलेला लेआउट लादणे ही योग्य दुरुस्ती नाही.

अ‍ॅरेमधून जाताना marshaling नंतरचा रचना आकार वापरा, ANSI किंवा Unicode घोषणा सातत्याने जुळवा आणि प्रत्येक वाटप स्वतंत्रपणे मागोवा घ्या. पर्याय रचनांचा ब्लॉक मुक्त केल्याने इतरत्र वाटप केलेल्या आणि त्या रचनांनी संदर्भित स्ट्रिंग स्वयंचलितपणे मुक्त होत नाहीत.

शेवटी, सेटिंग्जच्या व्याप्तीचा प्रश्न मेमरी अचूकतेपासून वेगळा ठेवा. कास्ट दुरुस्त केल्याने हे सिद्ध होत नाही की हेल्परने निवडलेला WinINet पर्याय केवळ एका नियंत्रणावर, एका प्रक्रियेवर किंवा सध्याच्या वापरकर्त्याच्या सेटिंग्जवर परिणाम करतो. जुन्या नमुन्याचा उर्वरित भाग स्वीकारण्यापूर्वी त्या API वर्तनाची तपासणी करा. जर तो रिफ्रेश सूचना देखील पाठवत असेल, तर त्या इच्छित व्याप्तीसाठी निवडा.