d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang)

Frédéric Delanoy frederic.delanoy at gmail.com
Mon May 16 02:39:26 CDT 2011


2011/5/16 Stefan Dösinger <stefandoesinger at 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



More information about the wine-devel mailing list