2011/5/16 Stefan Dösinger <stefandoesin...@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