[RFC PATCH] gdi32: allow passing BITMAPINFO with bmiHeader.biSizeImage == 0 for EMF DC.

Jinoh Kang jinoh.kang.kr at gmail.com
Wed Oct 13 23:15:39 CDT 2021


On 10/14/21 02:57, Jacek Caban wrote:
> Hi Jinoh,
> 
> On 10/12/21 8:31 PM, Jinoh Kang wrote:
>> I performed a test going roughly as follows on Windows 10, build 2108:

>>
>> These behaviours closely resemble bitmapinfoheader_from_user_bitmapinfo _sans_ in-line mutation of biSizeImage.
>> Perhaps we can write the calculated size to a separate pass-by-ref variable, and change the original usage as follows:
>>
>>      -bitmapinfoheader_from_user_bitmapinfo(&dst->bmiHeader, &info->bmiHeader);
>>      +bitmapinfoheader_from_user_bitmapinfo(&dst->bmiHeader, &info->bmiHeader, &dst->bmiHeader.biSizeImage);
>>
>> Alternatively, we should factor it out into a separate function.
> 
> 
> Thanks for testing it. The problem with using a function like above is that it depends on the order values of &dst->bmiHeader and &dst->bmiHeader.biSizeImage are set in bitmapinfoheader_from_user_bitmapinfo.

Yes, aliasing arguments doesn't help. My idea was that we could fold the "modify the biSizeImage in place" case into the helper function, with just one extra instruction to set the 3rd parameter to `&biSizeImage`. This way no special casing is needed. Maybe it was too clever to be maintainable, though.

> In this case I'd say that skipping size calculation in the helper that sanitizes the header and doing that in a separate helper seems better.

I guess if we're going to copy the helper from Unix side to PE side _and_ modify it, it would be a good idea to either 1) change the new helper's name or 2) synchronize the modified helper code to PE side and refactor accordingly, to avoid confusion. Any suggestions on this part are welcome.

I think I'll be working on v2 patch this weekend.

> 
> 
> Thanks,
> 
> Jacek
> 

-- 
Sincerely,
Jinoh Kang




More information about the wine-devel mailing list