On 18/01/2022 18:00, Giovanni Mascellani wrote:
Hi,
Il 18/01/22 01:48, Mohamad Al-Jaf ha scritto:
ok(cur <= ret && (char*)ret < ((char*)ret + 0x100), "Address %p not in function starting at %p.\n", ret, cur);
Is it okay to cast it like this?
Does the compiler emit any warning?
Remember that if it makes your life easier, you can directly define cur and ret of type char*.
> My interpretation of that page is that calling > __builtin_return_address(0) is always fine, it is for higher frames that > it is not necessarily reliable. Still, it is a GCC-specific thing, so > alternatives should be provided for other compilers.
I see, so would it be best to just use the assembly code?
It seems plausible.
Regarding the unit test, is it okay to declare the function directly in the test itself? Doing this, the compiler doesn't issue a warning, but it seems suboptimal to me. A header seems like the correct way to go. But I don't know if it's acceptable to write a header file for just 1 function.
If you or the Wine team thinks a header file is required, should I submit 2 patches instead of one? First for the function implementation and the second for the test, including the header file.
I am not able to answer about this.
Giovanni.
Well, I think you can just probably just declare it in the source, either in the test function or outside of it. There's some examples of that in existing tests, see e.g:
gdiplus/tests/brush.c -> extern BOOL color_match(...); imagehlp/tests/testdll.c -> extern DWORD WINAPI StrCmpCA(...); windowscodecs/tests/converter.c -> extern HRESULT STDMETHODCALLTYPE IWICBitmapFrameEncode_WriteSource_Proxy(...);
It wouldn't even be more "correct" to declare it in a private header to the test since it's technically an imported function from the Win32 API, not part of the test's functions, so I would say it's pointless, but that's just my opinion, not authoritative.
Best is to just send it and see what response it gets about it, if any.