Miért törik el egy régi WinINet-proxysegéd 64 bites buildben

Egyetlen cast architektúrafüggő hibává tehet egy látszólag hétköznapi proxybeállítás-segédet:

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

Ez a kód 32 bites egésszé szűkíti a natív címet, mielőtt hozzáadná a következő struktúra méretét. Egy 64 bites folyamat olyan címeket is tárolhat, amelyek nem férnek bele. Az átalakítástól és az értéktől függően az eredmény túlcsordulási kivétel vagy érvénytelen cím lehet. A build x86-ra való visszaállítása elrejtheti a hibát, de az interop-megvalósítást ettől a kerülőmegoldástól teszi függővé.

Tartsa a címeket mutatóméretű formában. Például egy már lefoglalt tömbön való végighaladáshoz ez használható:

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

Az eltolás egész szám marad; maga a cím nem préselődik át egyen. A foglalás méretének és az indexnek továbbra is érvényesnek kell lennie.

Ezután vizsgálja meg a környező deklarációkat

A WinINet kapcsolatonkénti beállításai olyan uniót tartalmaznak, amelynek tagjai között DWORD, karakterlánc-mutató és FILETIME szerepel. A mutatómezőknek IntPtr kell; a DWORD-mezők 32 bitesek maradnak. A natív igazítás számít, ezért nem jó javítás minden egészet 64 bites egésszé alakítani vagy csomagolt elrendezést kényszeríteni.

A tömbön való végighaladáskor a marshaling utáni struktúraméretet használja, következetesen egyeztesse az ANSI- vagy Unicode-deklarációt, és minden foglalást külön kövessen. A beállításstruktúrák blokkjának felszabadítása nem szabadítja fel automatikusan a máshol lefoglalt, ezek által hivatkozott karakterláncokat.

Végül válassza külön a beállítások hatókörének kérdését a memóriahibáktól. Egy cast javítása nem bizonyítja, hogy a segéd által választott WinINet-beállítás csak egy vezérlőre, egy folyamatra vagy az aktuális felhasználó beállításaira hat. Ellenőrizze ezt az API-viselkedést, mielőtt egy régi minta többi részét átvenné. Ha frissítési értesítéseket is küld, a tervezett hatókörhöz válassza ki őket.