-DSTRICT warning fixes

[Patrik Stridvall]

> Patrik Stridvall <ps at leissner.se> writes:
> 
> > However for the debugging output I disagree. I orginally thought
> > as Francois (and you it seems) that handles are pointers and should
> > be treated as such. But then I realized that when we 
> implement Win32 on
> > 64-bit platforms we can't have handles as pointers even 
> internally if
> > we wan't to support x86 emulation and even exposing a 64-bit
> > handle to Winelib application can only cause trouble since they
> > might store it is a 32-bit memory location. Sure we will probably be
> > able to handle 64-bit pointers truncated to 32-bit by storing all
> > objects in the lower 32-bit part of memory, but fear it might
> > cause trouble all the same.
> 
> Handles are pointers in the Windows API, and they should be pointers
> inside of Wine. On a 64-bit platforms pointers will be 64-bit, and so
> will handles.

Does the Windows API really define exactly what a handle is?
It is just a identifier for an object that can be passed to
various APIs but should not be used directly.

> If you want to run 32-bit code on such a platform you
> need a conversion for pointers anyway, 
> so you might as well use the
> same conversion for handles.
> Not to mention that some handles are
> actually pointers (like HMODULE).

That is an internal Wine/Winelib problem and shouldn't need to
concern porters of Winelib applications.

> So no, there is absolutely no reason
> to force handles to be 32 bits.

Handles are some sort of values as for as whether they are integers or
pointers any Winelib application that cares are IMHO broken.
I guess you agree on that point.

However your suggestion that any Winelib application that cares whether
they are 32-bit or 64-bit are broken is a far too strict IMHO and I see
no reason to require porters to fix such things.

Note that it might no be so easy to fix it either. Perhaps the application
uses some external lib that provides storage of some user defined 32-bit
data and use it to store the handles. Now it will suddenly not work anymore,
and fixing it is not trival. Hint you are on a 64-bit platform that requires
64-bit pointers and you have 32-bit storage. The obvious solution an index
of an array might not always work so well because of memory management
requirements and beside the maintainer of the project might not accept
a special patch for the 64-bit version.

Anyway, never mind. See below instead.

Sure pointer face in some meaning the same problems,
but that sort of problems is more obvious and there is
no reason to add more to the burden.

> > The real reason that we should support compiling Wine with -DSTRICT
> > is not because handles becomes pointers but because callbacks gets
> > the correct prototype.
> 
> No, it's because handles become pointers; you cannot do the -DSTRICT
> typechecking with integers anyway. 

True, you can't do typechecking with integers but since Wine is
primarily compiled 32-bit platform that will use 32-bit pointers,
we will get the benefit of typechecking at the platform, which
happends the only one Wine currently works on.

Sure future developers on 64-bit will not find the errors then they
compile, but everybody else compiling for a 32-bit platform will,
so I don't see the problem.

> Callbacks are a very minor issue;
> the real point is to fix all incorrect handle manipulations, like
> implicit 16-bit handle conversions or arithmetic on handle values.

The ones of the above that can be found automatically will be fixed
by the 32-bit developers. So the actual problem is what?

Anyway, this discusion is getting a little carried away (mostly my fault).

While I do not currenly agree that we really should use 64-bit
handles on 64-bit platforms, your objections have made me think
some more and made me come to the following conclusions.

In order to not "close the door to the future" whether this
is Win32 on 64-bit or Win64, the Wine code shouldn't internally
not care (give errors or warnings or be semantically wrong)
whether the header files:
1. Defines handles as integers or pointers
2. Defines handles as 32-bit or 64-bit
   (regardless of whether we have 32-bit or 64-bit pointers)

This is not so a for the normal (non-debugging) code.
OK, we might have to force memory allocation of
objects for the lower 32-bit of memory if we have
64-bit pointers but that is probably not so large
problem. After all the Winelib application itself can
allocate memory on the full 64-bit memory range
and Winelib itself are not likely to need more that
4Gb memory for objects.

However, I see no really good solution for the debug output.
Neither mine nor your previously suggested solution have
the above properties.

However the solution below have, I think
TRACE("(%p)", (LPVOID) handle);
eventhough it might display unnessary information
on 64-bit platforms, but perhaps we should worry
about that in the future, if it indeed is a problem
at all. After all it is only a few more bytes in 
the debug output.

So therefor I suggest that we should do the following
TRACE("(%p)", (LPVOID) handle);

It will fix the problem that Francois speaks of in bug report #90.
< * Ignore gcc's warnings saying '%x format, pointer argument'. Fixing the
format
< at this stage would only introduce tons of warnings for the developpers
not
< participating in the switch (i.e. compiling with STRICT off).

It will allow us to fix the debug output one by one (or at least
seperately per type) since it will allow us compile without related
warnings even without -DSTRICT as well as to prepare us for a possible
future where handles might be 32-bit integers on 64-bit.