Lines Matching refs:is
3 # for an empty field. First field is an RE. Second field is flags. If
4 # C flag given, regcomp() is expected to fail, and the third field is the
7 # Otherwise it is expected to succeed, and the third field is the string to
8 # try matching it against. If there is no fourth field, the match is
9 # expected to fail. If there is a fourth field, it is the substring that
10 # the RE is expected to match. If there is a fifth field, it is a comma-
13 # starting with @ indicates that the (sub)expression is expected to match
16 # is newline, `S' is space, `T' is tab, `Z' is NUL.
20 # b RE is a BRE, not an ERE
22 # C regcomp() error expected, third field is error name
132 # The following test is wrong. Using \b in an BRE or ERE is undefined.
139 # trailing $ is a peculiar special case for the BRE code
159 # actually, this next one probably ought to fail, but the spec is unclear
161 # here is a case that no NFA implementation does right
186 # '{' is always a special char outside bracket expressions. So test ony BRE:
239 # Wow, there is serious disconnect here. The ERE grammar is like this:
246 # where ERE_dupl_symbol is any of the repetition methods. It is clear from
247 # this that consecutive repetition is OK. On top of this, the one test not
248 # marked as failing must fail. For BREs the situation is different, so we
298 # This test is invalid. "one" is no collating symbol in any standardized
331 # This test is invalid. "one" is no collating symbol in any standardized
429 # do we get the right subexpression when it is used more than once?