This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: __has_include__ is problematic

From: Nathan Sidwell <nathan at acm dot org>
To: Jakub Jelinek <jakub at redhat dot com>, Florian Weimer <fweimer at redhat dot com>
Cc: gcc at gcc dot gnu dot org
Date: Mon, 14 Jan 2019 16:40:28 -0500
Subject: Re: __has_include__ is problematic
References: <87ef9kk304.fsf@oldenburg2.str.redhat.com> <20190110143230.GX30353@tucnak>

On 1/10/19 9:32 AM, Jakub Jelinek wrote:

On Thu, Jan 10, 2019 at 03:20:59PM +0100, Florian Weimer wrote:

Can we remove __has_include__?

No.

Its availability results in code which is needlessly non-portable
because for some reason, people write __has_include__ instead of
__has_include.  (I don't think there is any difference.)


__has_include needs to be a macro, while __has_include__ is a weirdo
builtin that does all the magic.  But one needs to be able to
#ifdef __has_include
etc.

Why not give the wierdo __has_include__ an unspellable name?('builtin<SPACE>has<SPACE>include') and take care constructing the__has_include macro expansion to have a token with exactly that spelling?


nathan

--
Nathan Sidwell

Follow-Ups:
- Re: __has_include__ is problematic
  - From: Florian Weimer

References:
- __has_include__ is problematic
  - From: Florian Weimer
- Re: __has_include__ is problematic
  - From: Jakub Jelinek

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]