Waarom 'n ou WinINet-proxyhelper in 'n 64-bis-bou breek

Een cast kan 'n oënskynlik gewone proxy-instellingshelper in 'n argitektuur-afhanklike fout verander:

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

Daardie kode vernou 'n native adres na 'n 32-bis heelgetal voordat dit die volgende struktuur se grootte bytel. 'n 64-bis proses kan adresse hou wat nie pas nie. Afhangend van die omskakeling en waarde kan die resultaat 'n oorloopuitsondering of 'n ongeldige adres wees. Om die bou terug te skakel na x86 kan die fout verberg, maar dit laat die interop-implementering van daardie workaround afhanklik.

Hou adresse in wysergrootte vorm. Om byvoorbeeld deur 'n reeds toegewysde skikking te beweeg, kan dit gebruik:

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

Die offset bly 'n heelgetal; die adres self word nie deur een gepers nie. Die toewysingsgrootte en indeks moet steeds geldig wees.

Ondersoek dan die omliggende verklarings

WinINet se per-verbinding-opsies bevat 'n union waarvan die lede 'n DWORD, 'n stringwyser en 'n FILETIME insluit. Wyservelde benodig IntPtr; DWORD-velde bly 32-bis. Native belyning maak saak, so om elke heelgetal met 'n 64-bis heelgetal te vervang of 'n gepakte uitleg af te dwing, is nie 'n gesonde herstelling nie.

Gebruik die gemarshalde struktuurgrootte wanneer jy deur die skikking stap, pas die ANSI- of Unicode-verklaring konsekwent, en hou elke toewysing afsonderlik dop. Om die blok opsiestrukture vry te maak, stel nie outomaties stringe vry wat elders toegewys is en deur daardie strukture verwys word nie.

Laastens, hou die vraag oor instellingsomvang apart van geheuekorrektheid. Om 'n cast te herstel bewys nie dat 'n helper se gekose WinINet-opsie slegs een beheer, een proses of die huidige gebruiker se instellings raak nie. Kontroleer daardie API-gedrag voordat jy die res van 'n ou voorbeeld aanvaar. As dit ook herlaai-kennisgewings stuur, kies hulle vir die beoogde omvang.