[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] [libc++]bitmask element ECMAScript is 0
From: Hubert Tong via cfe-dev <cfe-dev () lists ! llvm ! org>
Date: 2016-10-27 20:21:03
Message-ID: CACvkUqbV_6FF+coCVj5BNUsXV+wpgiVQ3evV3W1mcJs-0X=B8Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Oct 13, 2016 at 11:12 AM, Jason Liu via cfe-dev <
cfe-dev@lists.llvm.org> wrote:
> When I was browsing regex header from libcxx, I found the following code:
>
> enum syntax_option_type
>
> {
>
> icase = 1 << 0,
>
> nosubs = 1 << 1,
>
> optimize = 1 << 2,
>
> collate = 1 << 3,
>
> ECMAScript = 0,
>
> basic = 1 << 4,
>
> extended = 1 << 5,
>
> awk = 1 << 6,
>
> grep = 1 << 7,
>
> egrep = 1 << 8
>
> };
>
>
> syntax_option_type is an implementation-defined bitmask type. According to
> standard, bitmask elements have distinct, nonzero values. And the value 0
> is used to represent an empty bitmask, in which no bitmask elements are
> set.
>
> Standard does mention that if no grammar element is set, the default
> grammar is ECMAScript. But ECMAScript still looks like a bitmask element
> inside of bitmask type syntax_option_type to me, which means it should be
> non-zero.
>
> Interestingly, when I look at the history of regex header, ECMAScript was
> a non-zero value at some point, but got changed to 0 in a later commit.
>
> So my questions are... Any reasons why we changed it to 0? (Maybe for
> cleaner implementation?) Is this still standard compliant? If not, should
> we modify it to be more standard compliant?
>
The use of "0" breaks use cases like the following:
bool isEcmaScript(::std::regex_constants::syntax_option_type v) {
return v & ::std::regex_constants::ECMAScript;
}
> Thanks in advance!
>
>
> Regards,
>
>
> Jason Liu
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 13, 2016 \
at 11:12 AM, Jason Liu via cfe-dev <span dir="ltr"><<a \
href="mailto:cfe-dev@lists.llvm.org" \
target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">When I was browsing regex header \
from libcxx, I found the following code:<div>
<p class="gmail-m_-7254379418759664096gmail-p1"><span \
class="gmail-m_-7254379418759664096gmail-s1">enum </span><span \
class="gmail-m_-7254379418759664096gmail-s2">syntax_option_type</span></p> <p \
class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2">{</span></p> <p \
class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"> icase = 1 << \
0,</span></p> <p class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"> nosubs = 1 << \
1,</span></p> <p class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"> optimize = 1 << \
2,</span></p> <p class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"> collate = 1 << \
3,</span></p> <p class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"> ECMAScript = 0,</span></p> <p \
class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"> basic = 1 << \
4,</span></p> <p class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"> extended = 1 << \
5,</span></p> <p class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"> awk = 1 << \
6,</span></p> <p class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"> grep = 1 << \
7,</span></p><p class="gmail-m_-7254379418759664096gmail-p2"> egrep = 1 \
<< 8</p> <p class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2">};</span></p><p \
class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2"><br></span></p><p \
class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2">syntax_option_type is an \
implementation-defined bitmask type. According to standard, bitmask elements have \
distinct, nonzero values. And the value 0 is used to represent an empty bitmask, in \
which no bitmask elements are set. </span></p><p \
class="gmail-m_-7254379418759664096gmail-p2"><span \
class="gmail-m_-7254379418759664096gmail-s2">Standard does mention that if no grammar \
element is set, the default grammar is ECMAScript. But ECMAScript still looks like a \
bitmask element inside of bitmask type syntax_option_type to me, which means it \
should be non-zero. </span></p><p \
class="gmail-m_-7254379418759664096gmail-p2">Interestingly, when I look at the \
history of regex header, ECMAScript was a non-zero value at some point, but got \
changed to 0 in a later commit. </p><p \
class="gmail-m_-7254379418759664096gmail-p2">So my questions are... Any reasons why \
we changed it to 0? (Maybe for cleaner implementation?) Is this still standard \
compliant? If not, should we modify it to be more standard \
compliant?</p></div></div></blockquote><div>The use of "0" breaks use cases \
like the following:<br></div><div>bool \
isEcmaScript(::std::regex_constants::syntax_option_type v) {<br></div><div> return \
v & ::std::regex_constants::ECMAScript;<br></div><div>}<br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><p \
class="gmail-m_-7254379418759664096gmail-p2">Thanks in advance!</p><p \
class="gmail-m_-7254379418759664096gmail-p2"><br></p><p \
class="gmail-m_-7254379418759664096gmail-p2">Regards,</p><p \
class="gmail-m_-7254379418759664096gmail-p2"><br></p><p \
class="gmail-m_-7254379418759664096gmail-p2">Jason Liu</p></div></div> \
<br>______________________________<wbr>_________________<br> cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" \
target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br> \
<br></blockquote></div><br></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
cfe-dev mailing list
cfe-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic