__has_include__ is problematic

__has_include__ is problematic

[Florian Weimer]

Can we remove __has_include__?

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.)

Thanks,
Florian

Re: __has_include__ is problematic

[Jakub Jelinek]

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.

	Jakub

Re: __has_include__ is problematic

[Florian Weimer]

* Jakub Jelinek:

> 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 doesn't a synthetic

#define __has_include __has_include

work?

Thanks,
Florian

Re: __has_include__ is problematic

[Jakub Jelinek]

On Thu, Jan 10, 2019 at 03:35:14PM +0100, Florian Weimer wrote:
> * Jakub Jelinek:
> 
> > 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 doesn't a synthetic
> 
> #define __has_include __has_include
> 
> work?

Because the magic builtin is a preprocessor builtin, kind of macro,
so you can't have a normal macro with the same name.

	Jakub

Re: __has_include__ is problematic

[Nathan Sidwell]

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

Re: __has_include__ is problematic

[Florian Weimer]

* Jakub Jelinek:

> Because the magic builtin is a preprocessor builtin, kind of macro,
> so you can't have a normal macro with the same name.

Could we turn this kind-of-macro into something that can be tested using
#ifdef?

Thanks,
Florian

Re: __has_include__ is problematic

[Florian Weimer]

* Nathan Sidwell:

> 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?

Wouldn't that break -dM rather horribly?

Thanks,
Florian

Re: __has_include__ is problematic

[Nathan Sidwell]

>> 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?
> 
> Wouldn't that break -dM rather horribly?
pah!
> 

However, the following thinks __DATE__ is a defined macro, so there must 
be some other subtlety with __has_include?

nathans@zathras:6>gcc -xc - <<EOF
#ifdef __DATE__
#error DATE IS A MACRO
#endif
EOF
<stdin>:2:2: error: #error DATE IS A MACRO

(typing that makes me realize why users think it is __has_include__, 
that's a really unfortunate name to use for an implementation detail)

nathan
-- 
Nathan Sidwell