[llvm-bugs] [Bug 42952] New: Don't recommend defining __has_* macros

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=42952

            Bug ID: 42952
           Summary: Don't recommend defining __has_* macros
           Product: Documentation
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: General docs
          Assignee: unassignedbugs at nondot.org
          Reporter: clang at evan.coeusgroup.com
                CC: llvm-bugs at lists.llvm.org

In the "Feature Checking Macros" section of "Clang Language Extensions", the
manual currently recommends code like:

  #ifndef __has_builtin         // Optional of course.
    #define __has_builtin(x) 0  // Compatibility with non-clang compilers.
  #endif

  ...
  #if __has_builtin(__builtin_trap)
    __builtin_trap();
  #else
    abort();
  #endif
  ...

This presents a problem in public headers, because other projects may want to
do something like:

  #if defined(__has_builtin)
    #define FOO_HAS_BUILTIN_TRAP __has_builtin(__builtin_trap)
  #elif defined(__GNUC__) && (__GNUC__ >= 4)
    #define FOO_HAS_BUILTIN_TRAP 1
  #else
    #define FOO_HAS_BUILTIN_TRAP 0
  #endif

But if someone has already created a `#define __has_builtin(x) 0`, this check
would define FOO_HAS_BUILTIN_TRAP to 0 instead of 1 on GCC 4+, and AFAIK there
is no way to verify that you're using a "real" __has_builtin.

I'd suggest changing the examples to something like

  #ifdef __has_builtin
    #define my_has_builtin(x) __has_builtin(x)
  #else
    #define my_has_builtin(x) 0 // Compatibility with non-clang compilers.
  #endif

  ...
  #if my_has_builtin(__builtin_trap)
    __builtin_trap();
  #else
    abort();
  #endif
  ...

That retains most of the simplicity of the existing examples, but doesn't
encourage people to write code that can easily result in portability problems
while claiming to be for "compatibility with non-clang compilers".

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190810/c7ca440d/attachment-0001.html>