On 28/05/13 13:10, Earnie Boyd wrote:
> On Tue, May 28, 2013 at 6:49 AM, Keith Marshall wrote:
>> However, a more serious issue arose at runtime; the use of 'LONG' to
>> specify the type of the 'e_lfanew' field in the 'IMAGE_DOS_HEADER'
>> struct; since 'LONG' is
>> typedef long LONG
>> and 'long' is 64 bits on my 64-bit Debian box, the compiler interpreted
>> this as a 64-bit 'e_lfanew' field, (which is wrong -- it *must* be an
>> *explicit* 32-bit field), and the application blew up with a segment
>> violation fault at runtime, as soon as it tried to parse the DLL image
>> content, as referenced by the improperly sized e_lfanew offset value.
> But why did your compiler DTWT?
My compiler did *not* DTWT; it did precisely TRT.
> I am assuming you're using a cross compiler targeting MinGW?
Nope; wrong assumption. I'm building a Linux hosted cross-pexports, to
run natively on my 64-bit Debian box, as a complement to my existing
(self-built) 64-bit Debian hosted mingw32-gcc cross-compiler.
> If so, then long should be 32 bits.
If I were using the cross-mingw32-gcc, then of course that's exactly
what it would be, (and is). I'm not using that compiler; I'm using the
native Debian 64-bit gcc, in which 'long' is (correctly) 64 bits.
TWT is in the declaration of IMAGE_DOS_HEADER, (in MinGW headers), where
the 'e_lfanew' field is declared as
The file layout, which that IMAGE_DOS_HEADER structure represents,
requires an unambiguous field width of *exactly* 32 bits for e_lfanew,
but the declaration uses an *ambiguous* type (32 bits *or* *more*).
>> In summary: I'm not suggesting that we drop support for these Microsoft
>> obfuscated typedefs; rather, we have an opportunity to engineer them
>> better, (perhaps even better than Microsoft do themselves), and that we
>> should maybe consider doing so.
> I don't disagree with the idea, I'm hesitant because I fear that the
> community expects them to be defined as they are by MS.
How many members of that community care, to the extent that they prefer
consistency with Microsoft ambiguity over technical accuracy? Who's to
say that, in a year or two's time, Microsoft won't introduce a new
64-bit version of MSVC, which promotes 'long' to 64 bits? When they do,
it's a fair bet that they'll also concoct some _USE_32BIT_LONG kludge,
and you'll be embroiled in the sizeof(long) counterpart of the
_USE_32BIT_TIME_T debacle all over again.