Microsoft's obfuscated typedefs considered harmful

I've never much liked Microsoft's obfuscated typedefs; some on the 
grounds of ugliness, some because they are just plain pointless; all 
because they evade standards conforming clarity of purpose, and hinder 
portability of code.

Here's one I'd previously considered to be in the pointless category:

   typedef long LONG;

However, while building pexports as a cross-tool, to be hosted on my 
64-bit Debian box, I discover that the reality is worse; this turd is 
actually used in contexts which may actually result in segmentation 
faults, and consequent program crashes!  The explanation is that, in 
pexports.h I see a declaration, duplicated from our winnt.h, of the 
IMAGE_DOS_HEADER structure, in which the e_lfanew member is declared as 
being of type LONG; (it needs to be an explicit int32_t).  The problem 
is: on 64-bit Linux, GCC interprets long as equivalent to int64_t, and 
offsets computed on the basis of a 64-bit e_lfanew, in which the most 
significant 32-bits are garbage pulled in from the following field, (of 
a following structural data entity within the PE file image), are very 
likely to be out-of-bounds.

I can easily fix this for pexports, but we may wish to consider the 
potential impact for winnt.h, and other API headers, in which the scope 
of the potential problem may be wider reaching; (it certainly affects 
more than just the IMAGE_DOS_HEADER structure).

Thoughts?

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may