ForkOn 17/02/19 17:17, Eli Zaretskii wrote:
> The new header alloca.h defines 'alloca' unconditionally as (AFAIU) an
> inline function:
>
> __CRT_ALIAS void *alloca( size_t __n )
> { return __builtin_alloca( __n ); }
Yes, that's an inline function, which is *always* expanded in-line;
according to GCC's info, this makes it equivalent to a macro, in terms
of both speed, and code size. However, it also has advantages over a
macro, in terms of type safety, (maybe not so important in this case,
because __builtin_alloca() should be type safe anyway), but rather more
importantly here, it also supports C++ namespace qualification, (which a
macro does not), should any user wish to so qualify it.
> This caused me trouble while building a GNU package, because Gnulib's
> alloca.h makes 'alloca' a macro:
>
> #ifndef alloca
> # ifdef __GNUC__
> # define alloca __builtin_alloca
So, yet another endemic Gnulib bug.
> I'm not yet sure why Gnulib decides that it needs to use its own
> alloca.h,
It should not do so; it should defer to the host platform's own
implementation, when one is provided.
> but I know that many packages do the above regardless, when
> the compiler is GCC.
And such packages are similarly broken.
> Should MinGW's alloca.h perhaps be more defensive,
It could be, but...
> and only define its
> own version if 'alloca' is not already defined as a macro?
this isn't the way; it should simply, and unilaterally, override the
endemic brain damage in packages such as Gnulib, and just #undef any
pre-existing, conflicting macro definition.
--
Regards,
Keith.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20190217/8af2862e/attachment.sig>