lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Fixing build with clang 7 and 64-bit Linux


From: Greg Chicares
Subject: Re: [lmi] Fixing build with clang 7 and 64-bit Linux
Date: Mon, 12 Nov 2018 18:06:14 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 2018-11-11 19:52, Vadim Zeitlin wrote:
[...]
>       https://github.com/vadz/lmi/pull/103

https://github.com/vadz/lmi/pull/103/commits/07fba915f6d250dfab5ee06bc79fe88ac75efeef
| facets.cpp:118:50: error: constant expression evaluates to -8193 which
| cannot be narrowed to type 'std::ctype_base::mask' (aka 'unsigned
| short') [-Wc++11-narrowing]
|
| when using clang by simply removing the braces, which impose C++11
| initialization and forbidding narrowing, and allowing the implicit cast
| to unsigned short to take place.
...
|             // See "Implementation note" above.
| -           constexpr std::ctype_base::mask z = {~std::ctype_base::space};
| +           constexpr std::ctype_base::mask z = ~std::ctype_base::space;

See the cited "Implementation note". I think that one or more of
  {gcc; clang; the C++11 and C++17 standards}
is incorrect. Let's figure out exactly what's wrong, and reconsider
the other workarounds discussed in that note, before working around
the present workaround.

Does clang compile Dietmar Kuehl's original
  rc[C] &= ~std::ctype_base::space;
without warning? and if not, then should it?

C++11 and C++17 both [bitmask.types] prescribe:

|  constexpr bitmask operator~(bitmask X){
|  return static_cast<bitmask>(~static_cast<int_type>(X));
|  }
|  bitmask& operator&=(bitmask& X, bitmask Y){
|  X = X & Y; return X;
|  }
...
| To clear a value Y in an object X is to evaluate the expression X &=~ Y.

and I don't see any error there. (This paper:
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3110.html
cited in the "Implementation note" seems to have been accepted;
its main point is that some enums elsewhere needed to be changed,
but that doesn't affect <ctype>.)

Thus,
  ~Y
is of type bitmask and the prescribed "clear a value" operation
  X &= ~Y
is valid; doesn't that mean that Kuehl's original
  rc[C] &= ~std::ctype_base::space;
is strictly conforming? If so, then maybe only gcc is wrong, and
only gcc needs any workaround (which can later be removed when
they correct the problem), but for clang we can just revert to
the original because it has always been correct.

But is clang also wrong, perhaps in a different way than gcc?
It complains about line 118:
    constexpr std::ctype_base::mask z = {~std::ctype_base::space};
    "constant expression evaluates to -8193"
but the standard says:

|  constexpr bitmask operator~(bitmask X){
|  return static_cast<bitmask>(~static_cast<int_type>(X));
|  }

so is clang saying that 'static_cast<bitmask>' fails to cast its
value to type <bitmask>? Or did they omit that static_cast in
their standard library implementation?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]