* __has_include__ is problematic
@ 2019-01-10 14:21 Florian Weimer
2019-01-10 14:32 ` Jakub Jelinek
0 siblings, 1 reply; 8+ messages in thread
From: Florian Weimer @ 2019-01-10 14:21 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __has_include__ is problematic
2019-01-10 14:21 __has_include__ is problematic Florian Weimer
@ 2019-01-10 14:32 ` Jakub Jelinek
2019-01-10 14:35 ` Florian Weimer
2019-01-14 21:40 ` Nathan Sidwell
0 siblings, 2 replies; 8+ messages in thread
From: Jakub Jelinek @ 2019-01-10 14:32 UTC (permalink / raw)
To: Florian Weimer; +Cc: gcc
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __has_include__ is problematic
2019-01-10 14:32 ` Jakub Jelinek
@ 2019-01-10 14:35 ` Florian Weimer
2019-01-10 14:37 ` Jakub Jelinek
2019-01-14 21:40 ` Nathan Sidwell
1 sibling, 1 reply; 8+ messages in thread
From: Florian Weimer @ 2019-01-10 14:35 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc
* 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __has_include__ is problematic
2019-01-10 14:35 ` Florian Weimer
@ 2019-01-10 14:37 ` Jakub Jelinek
2019-01-14 21:51 ` Florian Weimer
0 siblings, 1 reply; 8+ messages in thread
From: Jakub Jelinek @ 2019-01-10 14:37 UTC (permalink / raw)
To: Florian Weimer; +Cc: gcc
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __has_include__ is problematic
2019-01-10 14:32 ` Jakub Jelinek
2019-01-10 14:35 ` Florian Weimer
@ 2019-01-14 21:40 ` Nathan Sidwell
2019-01-14 21:51 ` Florian Weimer
1 sibling, 1 reply; 8+ messages in thread
From: Nathan Sidwell @ 2019-01-14 21:40 UTC (permalink / raw)
To: Jakub Jelinek, Florian Weimer; +Cc: gcc
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: __has_include__ is problematic
2019-01-14 21:40 ` Nathan Sidwell
@ 2019-01-14 21:51 ` Florian Weimer
2019-01-15 12:27 ` Nathan Sidwell
0 siblings, 1 reply; 8+ messages in thread
From: Florian Weimer @ 2019-01-14 21:51 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: Jakub Jelinek, gcc
* 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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: __has_include__ is problematic
2019-01-14 21:51 ` Florian Weimer
@ 2019-01-15 12:27 ` Nathan Sidwell
0 siblings, 0 replies; 8+ messages in thread
From: Nathan Sidwell @ 2019-01-15 12:27 UTC (permalink / raw)
To: Florian Weimer; +Cc: Jakub Jelinek, gcc
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-01-15 12:27 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-10 14:21 __has_include__ is problematic Florian Weimer
2019-01-10 14:32 ` Jakub Jelinek
2019-01-10 14:35 ` Florian Weimer
2019-01-10 14:37 ` Jakub Jelinek
2019-01-14 21:51 ` Florian Weimer
2019-01-14 21:40 ` Nathan Sidwell
2019-01-14 21:51 ` Florian Weimer
2019-01-15 12:27 ` Nathan Sidwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).