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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.