-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ralf Wildenhues wrote:
> * John Calcote wrote on Mon, Jun 23, 2008 at 10:02:30PM CEST:
>> 3. The code was particular to MS Windows. In these situations, it's
>> pretty clear that MS doesn't care about portable code.
>
> But what about w64? Haven't they, at least as an afterthought,
> introduced typedefs that are correct to use in either case?
No, I was making a relative judgment here. Compared to the care that has
apparently been taken in the Unix world with respect to processor
portability, MS seems to be a bit behind. They do good things too. But,
for example...
>> [Win] - - - - - - - - - - - - - - - -
>>
>> #ifdef FLM_64BIT
>> DWORD64 udDisplacement;
>> #else
>> DWORD udDisplacement;
>> #endif
This bit of code is part of a larger chunk of code that fills in a
Microsoft OS structure for walking the stack:
#ifdef FLM_64BIT
DWORD64 udDisplacement;
#else
DWORD udDisplacement;
#endif
pImgHlpSymbol->SizeOfStruct = sizeof(IMAGEHLP_SYMBOL);
pImgHlpSymbol->Address = *puiStack;
pImgHlpSymbol->MaxNameLength = 100;
if (SymGetSymFromAddr(gv_hMemProcess,
*puiStack, &udDisplacement, pImgHlpSymbol))
...
As you can see here, the OS function SymGetSymFromAddr expects to be
passed a 64-bit quantity (DWORD64) on 64-bit platforms, and a 32-bit
quantity (DWORD) on 32-bit platforms. Why didn't they define this
parameter to use an opaque type, like size_t, for instance?
Who knows, but regardless, the usual way to handle this scenario in
Windows code (at least in my experience) is to use the compiler supplied
pre-processor definition, _WIN64 to differentiate between the two code
paths. You can use _WIN32 (which ironically, is defined on ALL Windows
platforms) to distinguish between Windows and non-Windows code.
I usually don't try to make the user indicate whether or not he/she is
building 32 or 64 bit code. Rather, I try to self-determine within the
code using such predefined preprocessor symbols. They almost always
exist, and they're (as you said) accurate, regardless of the compiler
flags given by the user.
My biggest problem here is that I neglected to study the code I was
porting to see whether or not it was well-written before assuming that I
needed the FLM_64BIT definition. I simply assumed that the authors were
as particular as I would have been myself.
It's a little embarrassing to me - I try not to ask questions until I've
figured out as much as I can by myself. I do appreciate your input
however, as I've learned some things: For instance, you used the -m32/64
flag as part of the compiler variable, not the flags variable. This
would not have occurred to me, but it makes complete sense in hind
sight. The -mxx flag changes the compiler in a very fundamental way, so
it's best applied to the $CXX variable.
Regards,
John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIYRfpdcgqmRY/OH8RAgdCAJ4jsSgr4h1PX7pNKIiGgjCEci1TZQCfV6cM
3WgVn0IBeybLE9ByIDJfPnw=
=p5DY
-----END PGP SIGNATURE-----
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
