[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