Re: d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang)
On Friday 13 May 2011 15:03:35 Frédéric Delanoy wrote:
Adding d3dpool_from_wined3dpool and wined3dpool_from_d3dpool conversion functions instead of direct casts seems overkill for such straightforward conversions. I'm not quite sure about that patch. I sent a bunch of patches to add float<- integer casts myself to silence some msvc warnings. WINED3DPOOL in the way it currently is will go away sooner or later when we transition to a d3d10-style resource model. Still the problem will remain with other structures and types.
2011/5/16 Stefan Dösinger <stefandoesinger(a)gmx.at>:
I'm not quite sure about that patch. I sent a bunch of patches to add float<-
integer casts myself to silence some msvc warnings. WINED3DPOOL in the way it currently is will go away sooner or later when we transition to a d3d10-style resource model.
Well there's no loss of precision/type change in this patch. Those are still plain (integer) enums. However, I can understand casting may be risky if one of the enum structures changes, but again it's not like there was some kind of "value validity checking" earlier.
Still the problem will remain with other structures and types.
Indeed. I'm checking a couple of other automatic non-checked enum conversions, and those can be problematic; e.g. D3DRESOURCETYPE and WINED3DRESOURCETYPE are not identical but are autoconverted without any kind of check. Say you have enum A { A_FOO, A_BAR, A_BAZ } and enum B { B_FOO, B_BAR } How are you supposed to convert 'enum A' BAZ to 'enum B'? Probably issueing a fixme in the default clause, but then what would be a default return value? enum B B_from_A(elem) { switch( case A_FOO: return B_FOO; case A_BAR: return B_BAR; default: FIXME("Unhandled elem type %#x.\n", elem); return ??? } } Some enums, like D3DFORMAT specify a D3DFMT_UNKNOWN as first (0 valued) first enum value, which is returned in the "default" cause as well. Is this the way it should be done? a standard in wine coding? i.e. should previous example be changed to: enum A { A_UNKNOWN, A_FOO, A_BAR, A_BAZ } enum B { B_UNKNOWN, B_FOO, B_BAR } enum B B_from_A(elem) { switch( case A_FOO: return B_FOO; case A_BAR: return B_BAR; default: FIXME("Unhandled elem type %#x.\n", elem); return B_UNKNOWN; } } If it isn't a standard in wine, would that be a viable solution? Frédéric
2011/5/16 Frédéric Delanoy <frederic.delanoy(a)gmail.com>:
Indeed. I'm checking a couple of other automatic non-checked enum conversions, and those can be problematic; e.g. D3DRESOURCETYPE and WINED3DRESOURCETYPE are not identical but are autoconverted without any kind of check.
The resource type handling in e.g. d3d9 is really ugly, but should be safe in practice. IDirect3DCubeTexture9Impl_GetType() should only ever return D3DRTYPE_CUBETEXTURE for example.
2011/5/16 Henri Verbeet <hverbeet(a)gmail.com>:
2011/5/16 Frédéric Delanoy <frederic.delanoy(a)gmail.com>:
Indeed. I'm checking a couple of other automatic non-checked enum conversions, and those can be problematic; e.g. D3DRESOURCETYPE and WINED3DRESOURCETYPE are not identical but are autoconverted without any kind of check.
The resource type handling in e.g. d3d9 is really ugly, but should be safe in practice. IDirect3DCubeTexture9Impl_GetType() should only ever return D3DRTYPE_CUBETEXTURE for example.
Is there in that case no point in getting rid of those warnings by adding conversion functions between those related-but-not-identical enums? Couldn't this help detect invalid enum values quicker instead of passing them around unchecked? Frédéric Delanoy
2011/5/16 Frédéric Delanoy <frederic.delanoy(a)gmail.com>:
Is there in that case no point in getting rid of those warnings by adding conversion functions between those related-but-not-identical enums?
Well, in case of something like IDirect3DCubeTexture9Impl_GetType() there's no point in asking wined3d at all, the implementation should just be "return D3DRTYPE_CUBETEXTURE;". In case of something like IDirect3D9Impl_CheckDeviceFormat() we should have a conversion function.
participants (3)
-
Frédéric Delanoy -
Henri Verbeet -
Stefan Dösinger