Signed-off-by: Serge Gautherie winehq-git_serge_180711@gautherie.fr --- "...\info.c(1461) : error C4133: 'function' : incompatible types - from 'WICPixelFormatNumericRepresentation *' to 'DWORD *'"
ReactOS-Bug: https://jira.reactos.org/browse/CORE-7538 --- dlls/windowscodecs/info.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/dlls/windowscodecs/info.c b/dlls/windowscodecs/info.c index e131107..21b9c5d 100644 --- a/dlls/windowscodecs/info.c +++ b/dlls/windowscodecs/info.c @@ -1450,11 +1450,16 @@ static HRESULT WINAPI PixelFormatInfo_SupportsTransparency(IWICPixelFormatInfo2 static HRESULT WINAPI PixelFormatInfo_GetNumericRepresentation(IWICPixelFormatInfo2 *iface, WICPixelFormatNumericRepresentation *pNumericRepresentation) { + HRESULT hr; + DWORD numrep; + PixelFormatInfo *This = impl_from_IWICPixelFormatInfo2(iface);
TRACE("(%p,%p)\n", iface, pNumericRepresentation);
- return ComponentInfo_GetDWORDValue(This->classkey, numericrepresentation_valuename, pNumericRepresentation); + hr = ComponentInfo_GetDWORDValue(This->classkey, numericrepresentation_valuename, &numrep); + *pNumericRepresentation = numrep; + return hr; }
static const IWICPixelFormatInfo2Vtbl PixelFormatInfo_Vtbl = {
This fails the tests because it eliminates the NULL check for pNumericRepresentation which was handled in ComponentInfo_GetDWORDValue. It should probably also not be assigned if ComponentInfo_GetDWORDValue fails.
BTW, WICPixelFormatNumericRepresentation is DWORD-sized (and if not we have a binary compatibility problem), so it should be OK to cast the pointer.
On 26/07/2018 22:32, Vincent Povirk wrote:
BTW, WICPixelFormatNumericRepresentation is DWORD-sized (and if not we have a binary compatibility problem), so it should be OK to cast the pointer.
According to WikiPedia, "C exposes the integer representation of enumeration values ...". As in enum type is somewhat obscure. https://en.wikipedia.org/wiki/Enumerated_type#C
To be on the extra-safe/explicit side, I would use an intermediate DWORD.
If the enum is for some reason not DWORD-sized, an intermediate variable would get us the wrong behavior for binary compatibility. We'd be assigning a different sized value to the caller's DWORD-sized variable. Of course, casting would break if Wine or winelib calls the function internally.
It seems to me that neither approach is really safer, but casting allows for better code sharing.
On 26/07/2018 22:30, Vincent Povirk wrote:
This fails the tests because it eliminates the NULL check for pNumericRepresentation which was handled in ComponentInfo_GetDWORDValue. It should probably also not be assigned if ComponentInfo_GetDWORDValue fails.
I concur. Sorry for not having paid enough attention.
-
Serge Gautherie -
Vincent Povirk