New dlls/ddraw/device.c warnings

[Gerald Pfeifer]

After the recent sets of changes, I found that GCC 3.4 issues the
following warnings (on FreeBSD 5.4.

I checked and depending on how a compiler implements assert(), the 
warnings are valid, insofar as the compiler doesn't have a way to
automatically determine that all code paths are covered:

device.c: In function `Thunk_IDirect3DDeviceImpl_2_Begin':
  device.c:1826: warning: 'FVF' might be used uninitialized in this function
  device.c: In function `Thunk_IDirect3DDeviceImpl_2_BeginIndexed':
  device.c:1886: warning: 'FVF' might be used uninitialized in this function
  device.c: In function `Thunk_IDirect3DDeviceImpl_2_DrawPrimitive':
  device.c:2752: warning: 'FVF' might be used uninitialized in this function
  device.c: In function `Thunk_IDirect3DDeviceImpl_2_DrawIndexedPrimitive':
  device.c:2891: warning: 'FVF' might be used uninitialized in this function

Could you have a look into this, Stefan?  If someone has a hint on 
the preferred approach to address this, I can give it a try as well.

Thanks,
Gerald

[Stefan Dösinger]

Am Montag 26 Juni 2006 19:13 schrieben Sie:
> After the recent sets of changes, I found that GCC 3.4 issues the
> following warnings (on FreeBSD 5.4.
>
> I checked and depending on how a compiler implements assert(), the
> warnings are valid, insofar as the compiler doesn't have a way to
> automatically determine that all code paths are covered:
>
> device.c: In function `Thunk_IDirect3DDeviceImpl_2_Begin':
>   device.c:1826: warning: 'FVF' might be used uninitialized in this
> function device.c: In function `Thunk_IDirect3DDeviceImpl_2_BeginIndexed':
> device.c:1886: warning: 'FVF' might be used uninitialized in this function
> device.c: In function `Thunk_IDirect3DDeviceImpl_2_DrawPrimitive':
> device.c:2752: warning: 'FVF' might be used uninitialized in this function
> device.c: In function `Thunk_IDirect3DDeviceImpl_2_DrawIndexedPrimitive':
> device.c:2891: warning: 'FVF' might be used uninitialized in this function
>
> Could you have a look into this, Stefan?  If someone has a hint on
> the preferred approach to address this, I can give it a try as well.

This seems to be a clear case of 'stupid compiler'. The assert(0) in the 
default case of the switch statement will terminate the app, but it the 
compiler thinks that the call below will be called. I sent a fix which 
replaces the assertions by an ERR log and an error return to wine-patches

Thanks for the hint
Stefan