> Correct me if I'm wrong but I think there will still be major
> incompatibilities. If one developer creates a Win64 DLL using MSVC and
> another developer tries to link it with an .exe built using mingw64 then
> may or may not fail at runtime depending on what types they use.
> such a DLL with the following header file:
> int foo(long long x);
> void bar(long *p);
> When the .exe calls foo() it will pass 16 bytes but the DLL will be
> expecting 8 bytes. When the .exe calls bar() the DLL will only access
> lower 32-bits of the 64-bit long.
Yes, that true, but the major problem is the ISO definition of the pointer
difference, which lead to a long type. What implicit means, that a long
needs to have the same size as a pointer itself. Even MS reflect this by
defining intptr_t to an __int64 type.
The example would be still proper if we recomment, that users are using
the windows type definitions as LONG, or LONGLONG instead of using ISO-C
types. Because these types can be handled by header definitions. Eg. The
header would than look like:
int foo(LONGLONG x);
void bar(LONG *p);
If we change the ISO-C type "long", it means that programmer needs to
learn that pointer differences are "__int64" not "long", which for my
opinion looks more worse.
The "long long" type now introduced also by MS, has the definition to be
bigger than the largest architecture interger. Of course, we can define it
as a 8 byte word, but again it looks for me as an ISO violation.
> Some people won't need to call third party DLLs (or static libraries)
> use ISO C types but I think *many* will, and it is unreasonable to
> them to hack the header files. For these reasons I think that mingw64
> to keep compatibility with MSVC (including providing a 128-bit integer
Even MS mentioned for there type size definitions the reason, that it is
more a period issue to avoid problems on porting to the new architecture
and a lot of standard methods will move in future versions to 64-bit typed
arguments and return values. This will inflict to many coders the need to
rewrite and rethink there usage of types, too. If we make a "long" 4
bytes, a "long long" 8 bytes, we have to define a new type for the 16 byte
type "__int128" ("long long long" ?:) ) and do the integer arithmetics and
optimizations in gcc for it. Also I assume that it is getting hardly
introduced into the mainline of gcc, but may I am wrong.
i.A. Kai Tietz