[PATCH] D81667: [RFC, FileCheck] Add precision to format specifier

Thomas Preud'homme via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 17 11:18:50 PDT 2020


thopre added a comment.

In D81667#2098625 <https://reviews.llvm.org/D81667#2098625>, @jdenny wrote:

> >> I don't understand the above regex due to the space character after the `?`.  Was that intended?
> > 
> > No, fixed now.
>
> It now says `#%.5u, VAR2:` matches `(([1-9][0-9]+)?[0-9]{1,5})`, but that matches `123456789`.  I think that's unintended.
>
> >> Can you give some example inputs and explain the intended matching behavior for `#%.5u, VAR2:`?  Why is this behavior needed in FileCheck but not in scanf?
> > 
> > Say the directive is:
> > 
> > CHECK: Address #%.8x,ADDR: is aligned
> > 
> > and the input text is:
> > 
> > Address 12345678 is aligned
> > 
> > I'd expect the directive to match and the value in ADDR to be 0x12345678. Now if the input text was:
> > 
> > Address FFFFFFFF12345678
> > 
> > I'd expect the directive to fail.
>
> You mean fail to match and continue searching?  Or fail immediately?
>
> So, `%.8x` is a maximum?  For printf, it's a minimum.  scanf's `%8x` (no `.`) feels more like what you're going for except that it discards additional digits instead of failing to match.


My bad, my example was completely wrong. My personal motivation is consistency in the syntax. New example:

I'd expect 0x[[#%.8x, ADDR:]] to match 00001234 or FFFFFFFF12345678 but not 1234 due to there not being enough digits. I guess it could be useful to check alignment in a tool but as I said my main motivation is keeping a common format specifier syntax for all numeric substitution blocks. Note that my regex was indeed wrong anyway, it should be (([1-9][0-9]+)?[0-9]{5}).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81667/new/

https://reviews.llvm.org/D81667





More information about the llvm-commits mailing list