
<html>

  <head>

    <meta content="text/html; charset=ISO-8859-1"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <div class="moz-cite-prefix">On 21.06.2012 08:43, Daniel Jasper

      wrote:<br>

    </div>

    <blockquote

cite="mid:CAK_tg0zO80mheaSDAFb1TaPUshe+Ch_MtVX4fvce3Asy2QWvGA@mail.gmail.com"

      type="cite">

      <div style="font-family: arial, helvetica, sans-serif">Currently

        __has_feature, __has_extension and __has_attribute implement

        something similar, but this change does not really fit any of

        those categories as it should be considered a bug. Not allowing

        this attribute on fields was an oversight that was fixed. Thus I

        (after discussion with chandlerc) suggest introducing

        __has_bug. <font size="2">

          <div><br>

          </div>

          <div>This should default to 1 (all bugs that are not

            explicitly fixed in a clang version are still bugs) and to

            provide compatibility with other compilers, sources can

            used:</div>

          <div>#ifndef __has_bug</div>

          <div># define __has_bug(x) __clang__</div>

          <div>#endif</div>

          <div><br>

          </div>

          <div>Any thoughts?</div>

        </font><br>

      </div>

    </blockquote>

    I had the same idea (for some app's plugin API, but the principle is

    the same). In this case, however, I think we should give the builtin

    a clang-specific name. __has_feature and __has_extension could be

    done the same way by other compilers with matching feature names,

    and code would profit. However, another compiler is unlikely to have

    exactly the same bug, or realize it and come up with the same name

    scheme (I would just use Bugzilla numbers). What's more, since all

    unknown bug names are considered not fixed, that would mean that

    each such test would need a compiler predicate first.<br>

    That is, if GCC also implemented this, then you can no longer just

    use the custom define you described, because __has_bug would already

    be defined. Then your code would think that GCC has every bug Clang

    ever had, and vice versa.<br>

    <br>

    So I think we should either call it __has_clang_bug, or else come up

    with a scheme to namespace the bug names and only claim that we have

    those that are in our namespace, i.e. __has_bug(clang, 12323) would

    default to true on Clang unless 12323 has been specifically fixed,

    whereas __has_bug(gcc, 65834) would default to false on Clang. The

    obvious downside of the second approach is that it is harder (maybe

    even impossible) to emulate using a macro.<br>

    <br>

    Sebastian<br>

  </body>

</html>