Re: include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

[Michael Stefaniuc]

Dmitry,

afair the fix is to disable the int truncation warnings in MSVC. For
whatever reason they seem to enable those bogus warnings.

bye
    michael

On 06/28/2012 12:12 PM, Dmitry Timoshkov wrote:
> include/basetsd.h | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/include/basetsd.h b/include/basetsd.h
> index 698dd5c..4a59897 100644
> --- a/include/basetsd.h
> +++ b/include/basetsd.h
> @@ -153,12 +153,12 @@ typedef unsigned int UHALF_PTR, *PUHALF_PTR;
>
> static inline ULONG32 HandleToULong(const void *h)
>  {
> - return (ULONG_PTR)h;
> - return (ULONG32)(ULONG_PTR)h;
>
> }
>
> static inline LONG32 HandleToLong(const void *h)
>  {
> - return (LONG_PTR)h;
> - return (LONG32)(LONG_PTR)h;
>
> }
>
> static inline void *ULongToHandle(ULONG32 ul)
> @@ -173,32 +173,32 @@ static inline void *LongToHandle(LONG32 l)
>
> static inline ULONG32 PtrToUlong(const void *p)
>  {
> - return (ULONG_PTR)p;
> - return (ULONG32)(ULONG_PTR)p;
>
> }
>
> static inline LONG32 PtrToLong(const void *p)
>  {
> - return (LONG_PTR)p;
> - return (LONG32)(LONG_PTR)p;
>
> }
>
> static inline UINT32 PtrToUint(const void *p)
>  {
> - return (UINT_PTR)p;
> - return (UINT32)(UINT_PTR)p;
>
> }
>
> static inline INT32 PtrToInt(const void *p)
>  {
> - return (INT_PTR)p;
> - return (INT32)(INT_PTR)p;
>
> }
>
> static inline UINT16 PtrToUshort(const void *p)
>  {
> - return (ULONG_PTR)p;
> - return (UINT16)(ULONG_PTR)p;
>
> }
>
> static inline INT16 PtrToShort(const void *p)
>  {
> - return (LONG_PTR)p;
> - return (INT16)(LONG_PTR)p;
>
> }
>
> static inline void *IntToPtr(INT32 i)

include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

[Dmitry Timoshkov]

Michael Stefaniuc  wrote:
> afair the fix is to disable the int truncation warnings in MSVC. For
> whatever reason they seem to enable those bogus warnings.

The warnings are not bogus, the PSDK compiler also emits a warning when
truncating from double to float while gcc keeps silence for instance.
Anyway, the patch shouldn't hurt, PSDK headers have similar casts. This
patch also helps to pay more attention to warnings: when there are lots
of existing ones, it's hard to recognize new and possibly real problems
in the code.

include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

[Michael Stefaniuc]

On 06/28/2012 01:00 PM, Dmitry Timoshkov wrote:
> Michael Stefaniuc  wrote:
> > afair the fix is to disable the int truncation warnings in MSVC. For
> > whatever reason they seem to enable those bogus warnings.
>
> The warnings are not bogus, the PSDK compiler also emits a warning when

They are bogus as the C standard explicitly allows conversion between
integer types.
> truncating from double to float while gcc keeps silence for instance.

I never looked at that but I assume the same holds true as above.
> Anyway, the patch shouldn't hurt, PSDK headers have similar casts. This

In this specific case it doesn't. Start littering the code with casts to
get rid of all those warnings and it will majorly hurt. Unneeded casts
are *BAD*; worse then ignoring bogus warnings from a compiler.
> patch also helps to pay more attention to warnings: when there are lots
> of existing ones, it's hard to recognize new and possibly real problems
> in the code.

bye
    michael

include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

[Dmitry Timoshkov]

Michael Stefaniuc  wrote:
> > truncating from double to float while gcc keeps silence for instance.
>
> I never looked at that but I assume the same holds true as above.

The following thread has some interesting details:
http://www.daniweb.com/software-development/c/threads/114052/warning-c4305-t...
> > Anyway, the patch shouldn't hurt, PSDK headers have similar casts. This
>
> In this specific case it doesn't. Start littering the code with casts to
> get rid of all those warnings and it will majorly hurt. Unneeded casts
> are *BAD*; worse then ignoring bogus warnings from a compiler.

Obviosuly I'm not planning to add the casts everywhere, but the inline
constructs which specifically targeting the pointer to integer conversions
that imply truncation should compile without warnings IMHO.

include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

[Michael Stefaniuc]

On 06/28/2012 01:50 PM, Dmitry Timoshkov wrote:
> Michael Stefaniuc  wrote:
> > > truncating from double to float while gcc keeps silence for instance.
> >
> > I never looked at that but I assume the same holds true as above.
>
> The following thread has some interesting details:
> http://www.daniweb.com/software-development/c/threads/114052/warning-c4305-t...

WOW, that's pretty stupid. "0.1" has no type, it is a numeric literal.
Type is inferred from the context and only if that isn't possible it
will fall back to the intrinsic type. You can even say "int i = 0.1;"
and that is correct C.

gcc -Wall -Wextra does not complain about the examples in the thread you
quoted as that is the correct C behavior. MSVC is a C++ compiler beaten
into submission to do C. And C++ perverted C.

bye
    michael

include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

[Stefan Dösinger]

Am Donnerstag, 28. Juni 2012, 20:50:15 schrieb Dmitry Timoshkov:
> Obviosuly I'm not planning to add the casts everywhere, but the inline
> constructs which specifically targeting the pointer to integer conversions
> that imply truncation should compile without warnings IMHO.

Fwiw, I fixed a number of double-to-float conversion warnings in MSVC in 
wined3d, d3d8 and d3d9 a while ago, as well as some similar integer issues. I 
fixed most of those warnings by using the proper data types and explicitly 
using float literals. I added a handful of casts in places where the API 
differences forced me to(d3d vs GL clipplanes if I remember correctly).
> From my experience with wined3d the majority warnings(~90 %) from msvc made

sense and pointed out potential bugs in the code. The rest were cases like the 
one Dmitry wants to patch where the API definitions force a conversion with 
potential data loss.