Earnie Boyd wrote:
> Others opinion please? I may forward to the users list for their opinion
> as well.
While you state you have found another solution, for the record, I would
prefer that these sort of compatibility macros be used sparingly.
The goals of the mingw-runtime, if I understand correctly, are standard
compliance for corresponding languages supported by GCC (C, C++, etc),
MSVC compatibility, and limited support for other functions that quality
implementations are expected to provide (alloca() is in this catagory).
With regards to MSVC compatibility, most of these names correspond with
semantics primarily specified by POSIX. It makes a lot of sense to
implement the POSIX semantics for these functions, even where such
functionality is an extension on what MSVC documentation specifies.
This is helpful because it means implementations of POSIX based in part
on MinGW need not re-implement these functions.
On the other hand, providing additional POSIX names beyond what MSVC
documentation specifies may be problematic:
-They may be in violation with ISO 9899 and similar, if they are visible
as a result of including a standard header, creating unnecessary
-They will cause conflicts with code that assumes, for whatever reason,
that these names are not reserved, which may be reasonable.
-They may cause difficultities for library writers attempting to
implement POSIX, or cause them to rely on undocumented interfaces.
-For C++, the presense of arbitrary macros is significantly more likely
to cause trouble than C.
Furthermore, as Danny points out, the workarounds are typically simple.
In C, autoconf or similar can be used to provide missing functions, and
the preprocessor can provide missing macros. In C++, not even autoconf
is necessary in most cases, as the presense of names in the global
namespace can be detected at compile-time.
Aaron W. LaFramboise