https://bugs.winehq.org/show_bug.cgi?id=44405
Richard Yao ryao@gentoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #62204|0 |1 is obsolete| |
--- Comment #22 from Richard Yao ryao@gentoo.org --- Created attachment 62210 --> https://bugs.winehq.org/attachment.cgi?id=62210 A slightly better fix
I think I at least partially figured it out. Microsoft's documentation for CryptBinaryToStringW() states that if pszString is NULL, then the function calculates the length and returns it via pcchString:
https://docs.microsoft.com/en-us/windows/desktop/api/wincrypt/nf-wincrypt-cr...
Presumably, if pszString is NULL, then we should never read *pcchString because it is allowed to be undefined, but the code does this anyway. This is wrong. It is still not 100% clear how we are not bailing (partly because attaching winedbg with /tmp/proton_winedbg_run fails), but it is clear to me that we are supposed to unconditionally bail early when given a NULL pointer, which we are not doing.
As for test cases, the Microsoft documentation is unclear enough on other aspects of this function that I have nothing that I could use as a reference for what a correct test case should be. The right way here could be to pick some inputs, run them against the original DLL and then hard code the outputs as the test cases. However, this might require another person do that in order for it to count as clean room engineering rather than reverse engineering. I live in the United States where reverse engineering is legally problematic. The best that I could do here is rely on the code comments, Microsoft's incomplete documentation and whether this stops things from crashing to design test cases, which doesn't seem right to me.