Closed hdamron17 closed 4 years ago
The __has_header
macro is only usable in a #if
expression so I think I'll need to fix #449 first.
@hdamron17 interested in picking this back up now that #449 is fixed?
@hdamron17 interested in picking this back up now that #449 is fixed?
I'm still thinking through how everything will tie together, especially the function macros (others are easy and I could switch this to only do those if you want).
Let's do only object macros for now yeah. That will hit the vast majority of use cases.
The standard says "None of these macro names, nor the identifier defined, shall be the subject of a #define or a #undef preprocessing directive" (6.10.8p2). In clang, it is a warning and then successfully redefines. For us, any of the constantly redefined macros (like __LINE__
), this would override any user redefinition. Is this something we care about since the standard says no?
'shall not' means this is a constraint on the user, not on the compiler, so technically the behavior is undefined. It would be friendly to give a warning but I'm fine having it do unexpected things since this is a really bad idea anyway.
I think it would be hard to maintain giving a warning since we don't differentiate the builtins anywhere. I'll leave it such that __LINE__
and __FILE__
cannot be replaced but the others can (although none of them should).
Interestingly, clang doesn't define __STDC_IEC_559__
.
Also, according to GCC, "GCC does not define __STDC_IEC_559__
or implement the associated standard pragmas"
Even though GCC says it doesn't, __STDC_IEC_559__
is defined as 1 on my Ubuntu machine. On Mac with clang, nothing.
Just waiting on __STDC_IEC_559__
now.
r? @jyn514
This will provide the functionality to define builtin macros. Those in #453 and
__has_header()
will be implemented as proof of concept.