Hvers vegna gamall WinINet milliþjónshjálpari brotnar í 64-bita smíð

Einn cast getur breytt virðist venjulegum hjálpara fyrir milliþjónsstillingar í bilun sem fer eftir arkitektúr:

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

Sá kóði þrengir innfædd vistfang í 32-bita heiltölu áður en stærð næsta mannvirkis er bætt við. 64-bita ferli getur geymt vistföng sem passa ekki. Eftir umbreytingunni og gildinu getur niðurstaðan verið yfirfallsumfráning eða ógilt vistfang. Að færa smíðina aftur í x86 getur falið mistökin, en skilur interop-framkvæmdina eftir háða þeirri vinnulögn.

Haltu vistföngum í stærð bendils. Til dæmis má nota eftirfarandi til að fara í gegnum þegar úthlutað fylki:

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

Hliðrunin er áfram heiltala; vistfangið sjálft er ekki þrýst í gegnum eina. Úthlutunarstærðin og vísitalan verða samt að vera gild.

Skoðaðu síðan yfirlýsingarnar í kring

Stillingar WinINet fyrir hverja tengingu innihalda sameiningu þar sem meðlimir eru DWORD, strengjabendill og FILETIME. Bendilsreitir þurfa IntPtr; DWORD-reitir vera áfram 32-bita. Innfædd röðun skiptir máli, þannig að að skipta hverri heiltölu út fyrir 64-bita heiltölu eða þvinga pökkuðu útliti er ekki heilbrigð viðgerð.

Notaðu stærð mannvirkisins eftir marshaling þegar þú ferð í gegnum fylkið, samræmdu ANSI- eða Unicode-yfirlýsinguna á samkvæman hátt og fylgstu með hverri úthlutun sérstaklega. Að losa blokk valmöguleikamannvirkjanna losar ekki sjálfkrafa strengi sem eru úthlutaðir annars staðar og þessi mannvirki vísa til.

Að lokum, hafðu spurninguna um umfang stillinganna aðskilda frá minnisréttmæti. Að gera við cast sannar ekki að valin WinINet-stilling hjálpara hafi aðeins áhrif á eitt stýritæki, eitt ferli eða stillingar núverandi notanda. Athugaðu þessa API-hegðun áður en þú tekur við restinni af gömlu dæmi. Ef það sendir líka endurnýjunartilkynningar, veldu þær fyrir fyrirhugað umfang.