Re: Trouble with alloca.h
Keith Marshall <[email protected]>
| Newsgroups | gmane.comp.gnu.mingw.user |
|---|---|
| Organization | MinGW.org Project |
| Message-ID | <5C6B1E62.8040205__41123.6965375551$1550524134$gmane$org@users.osdn.me> |
On 18/02/19 03:31, Eli Zaretskii wrote:
>> it should simply, and unilaterally, override the endemic
>> brain damage in packages such as Gnulib, and just #undef any
>> pre-existing, conflicting macro definition.
>
> That should also work, but it might mean part of the offending package
> is compiled with "the other" definition of alloca, which could cause
> some subtle problem?
That should make no difference whatsoever; in either case the same
compiler intrinsic should be expanded in-line, yielding identically the
same object code for both. The problem with the pre-emptive definition
of alloca as a macro:
#define alloca __builtin_alloca
means the the subsequent in-line function definition would become:
__CRT_ALIAS void *__builtin_alloca( size_t __n )
{ return __builtin_alloc( __n ); }
which, if it were allowed, would recurse ad-infinitum, at the point of
expansion. Of course, it isn't allowed, because recursive functions are
not capable of in-line expansion, and __builtin_alloca() *must* be so
expanded. Even if this disallowed expansion weren't sufficient to
prevent successful compilation, it is also questionable whether the
redefinition of the compiler intrinsic would be permitted.
--
Regards,
Keith.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
_______________________________________________
MinGW-Users mailing list
[email protected]
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe
signature.asc
(application/pgp-signature, 836 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJcax5iAAoJEMCtNsY0flo/SCcP/1hsuK+/vQ+F8yCeOwIEmpzB CePuXEDAH8oyqcMWG2mHpfpIKSLm5BXtrSrSM5QAiHaW2QQRUm8szGjU3T0H16iH XVJNVRE+h/hKYvScvY4HwsBdeG+c9AIFVAPhWzzuXIqGpdXPmPv1Q7C6MomhqC/g 8d/5zXU82N+E9XoqJXhnP2//QcBTbsNB0GpQKddvmb45l+ePAiAMJ5jIYFbaowjx zTpq1R72UqiPd57EqrdfeTb3qhX5Y/E6KE/s04LYOx5GwTmS+0rWVRzNKgKHtKof jC6EpjZ2BD40+vAG5bpi0aTsei5bq7VD9m4ZueBHA/GzMG6ui1Pk0Cvw6XyWzoH9 5iF8cQ2dLG8DnrLHcYXGg2VsT4VAJ6lDAdtU1cT6nzWO6sMcImdxSHx56PxbzYCT 3RHrmgDi+fgbShfqcERON/e6A53jRRaAMT30LrYr0t/0iJFbkVKTHECkueG4Fyxd +nZOGH/f/nPVacbM2bTixPopptdWviAJSjhW9AAlrLXNa8UixOecaw+qVjNyYVsI UGFypfv+Rsl0v0FjsUWtrHETNFcRPawBYjICUUpxzwM6cbombjUMa+6oL4U1cqvQ z+IimADRXR+faLOGLSI2Jxr4YyeM3Gic/+Tz4TkPfd3rxD3Qjnek32rOf8CkFozB kF9bSKsOq46cGitETJqB =GTpz -----END PGP SIGNATURE-----