Re: Microsoft's obfuscated typedefs considered harmful

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

   LONG e_lfanew

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.

-- 
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