[PATCH 1/1] include/basetsd.h: fix bad casting

David Laight david at l8s.co.uk
Sat Oct 13 05:09:54 CDT 2012


On Sat, Oct 13, 2012 at 10:49:49AM +0900, Dmitry Timoshkov wrote:
> Max TenEyck Woodbury <max at mtew.isa-geek.net> wrote:
> 
> > >> -#define IntToPtr(i)             ((void *)(INT_PTR)((INT)i))
> > >> -#define UIntToPtr(ui)           ((void *)(UINT_PTR)((UINT)ui))
> > >> -#define LongToPtr(l)            ((void *)(LONG_PTR)((LONG)l))
> > >> -#define ULongToPtr(ul)          ((void *)(ULONG_PTR)((ULONG)ul))
> > >> +#define IntToPtr(i)             ((void *)(INT_PTR)(i))
> > >> +#define UIntToPtr(ui)           ((void *)(UINT_PTR)(ui))
> > >> +#define LongToPtr(l)            ((void *)(LONG_PTR)(l))
> > >> +#define ULongToPtr(ul)          ((void *)(ULONG_PTR)(ul))
> > > 
> > > You forgot to explain what's bad with it.
> > > 
> > 
> > The original applied the extra conversion to ONLY THE FIRST
> > component of the expression, not to the WHOLE expression.  That
> > can (although it's not likely to) cause hard to diagnose problems.
> 
> What 'the first component' are you talking about? This code is win32 only.

This example is a bit bogus but shows what he means:
with:
    struct foo { int a[2] } bar;
expand:
    IntToPtr(bar + 4)

I can't actually remember what all the perverted type names above
actually are! I had a feeling that INT_PTR had something do do with
an integer that is big enough to hold the value of a pointer rather
than being a pointer to an INT, but that means that having both
INT_PTR and LONG_PTR is silly.

Having an extra typedef for 'foo *' is really silly, amongst other 
things you can't convert it to 'const foo *' (only to 'foo * const').

	David

-- 
David Laight: david at l8s.co.uk



More information about the wine-devel mailing list