[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR13MB2503A8C61639B2C25358F03FFDCB9@BYAPR13MB2503.namprd13.prod.outlook.com>
Date: Mon, 30 Aug 2021 22:21:26 +0000
From: <Tim.Bird@...y.com>
To: <keescook@...omium.org>
CC: <rmoar@...gle.com>, <brendanhiggins@...gle.com>,
<davidgow@...gle.com>, <shuah@...nel.org>, <dlatypov@...gle.com>,
<kunit-dev@...glegroups.com>, <linux-kselftest@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <kernelci@...ups.io>,
<guillaume.tucker@...labora.com>
Subject: RE: RFC - kernel test result specification (KTAP)
> -----Original Message-----
> From: Kees Cook <keescook@...omium.org>
>
> On Mon, Aug 30, 2021 at 05:48:07PM +0000, Tim.Bird@...y.com wrote:
> > From: Kees Cook <keescook@...omium.org>
...
> > > Yes, though the optional "- " is strictly part of the optional
> > > description.
> >
> > It's mildly annoying that "-" is optional. It's trivial to deal with in the parser
> > to just ignore it if it's present. But it has no semantic meaning whatsoever.
> > IMHO it would be nice to either mandate it or remove it, for consistency's sake.
> > This could be based solely on the consensus for whether it added or detracted
> > from human readability, since parsers don't care.
>
> I have no strong opinion on the "-". I was surprised to encounter it
> as it's not part of the TAP 13 spec. I would prefer to drop it, if I had
> to choose.
The TAP 13 specification does not mention "-", but a dash on the result line
is used in most of the examples shown in the specification here:
http://testanything.org/tap-specification.html
In the top two examples on that page, the first one does not use dashes and
the second one does. It's kind of irritating to have that kind of loosey-goosey
syntax in a specification. IMHO the syntax should be more strictly specified
than this. I don't have a strong opinion either on whether to use dashes or not.
But it would be nice to make it consistent.
-- Tim Bird
Powered by blists - more mailing lists