ULONG_PTR (and possibly other) values not always inited properly for various bitness (32,64) target builds

There are fields defined various places as ULONG_PTR (seach for KAffinity, see psdk\basetsd.h) and initialized with 0xffffffff.

In 64bit builds, ULONG_PTR is supposed to become a 64bit entity
(see
http://stackoverflow.com/questions/1271748/dword-ptr-int-ptr-long-ptr-uint-ptr-ulong-ptr-when-how-and-why#1272382
http://stackoverflow.com/questions/1271748/dword-ptr-int-ptr-long-ptr-uint-ptr-ulong-ptr-when-how-and-why
https://msdn.microsoft.com/en-us/library/aa383751%28VS.85%29.aspx
)
and then it seems that initialization is likely no longer correct.

Some other means of initializing these entities that is target platform bitness agnostic should be chosen and used instead. With gcc, it appears use of -1 is likely promoted properly for -1 (0xffffffff in 32bit, 0xffffffffffffffff in 64bit).

KAffinity is one such entity defined as ULONG_PTR, but ULONG_PTR may be used elsewhere as well.

It appears that DWORD_PTR, INT_PTR, LONG_PTR, PULONG_PTR, SIZE_T, UINT_PTR usage may have similar issues, as they all seem to be affected by 32bit/64bit targets.

It appears the POINTER_64 may be Ok, but someone else should probably consider.

SSIZE_T might be OK, but I'm not sure I trust that its actually defined as simply LONG_PTR, in psdk\include\intsafe.h it seems to be defined as "long long" in some circumstances, while LONG_PTR in psdk\basetsd.h in reactos headers, which would seem to also be problematic. (Is the long long definition in 64bit correct?)