From: Keith M. <kei...@us...> - 2013-05-27 19:54:07
|
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. |