linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 5/7] test_hexdump: check all bytes in real buffer
Date: Mon, 23 Nov 2015 10:28:25 +0100	[thread overview]
Message-ID: <87r3jhyshy.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: <1448038537.31665.176.camel@linux.intel.com> (Andy Shevchenko's message of "Fri, 20 Nov 2015 18:55:37 +0200")

On Fri, Nov 20 2015, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Thu, 2015-11-19 at 11:11 +0100, Rasmus Villemoes wrote:
>> 
>> First of all, ' ' is one of the characters which hexdump is certainly
>> supposed to spit out, so I think it's better to use some other
>> character for prefilling. Otherwise we wouldn't be able to detect a
>> stray write of a space which wasn't properly guarded by a size
>> check. I'd suggest '\xff' or any other non-ascii
>
> Okay, I may change the ' ' to something, but somehow printable. See
> also below.
>
>> > -			a = r == e && buf[l - 1] == '\0' && buf[l
>> > - 2] == ' ';
>> > -		else
>> > -			a = r == e && buf[50] == '\0' && buf[49]
>> > == '.';
>> > +		memset(test, ' ', sizeof(test));
>> > +		test[sizeof(buf) - 1] = '\0';
>> > +
>> > +		a = r == e && !memchr_inv(buf, ' ', sizeof(buf));
>> 
>> test and buf happen to have the same size, but
>> "test[sizeof(buf) - 1] = '\0'" is rather odd. But you don't even seem
>> to use test in this branch?
>
> Here I feel the test buffer just to print below if any error happens
> when buflen == 0.
>
> That's why I would like to have a somehow printable character.

Oh, but that's wrong! That is, printing the filled test buffer does not
actually show what was "expected", whether you were filling with spaces,
$ or \xff. I really can't think of a situation where you'd want to print
the supposedly unused part of the buffer, so the character used for
filling shouldn't matter.

In any case, the most important thing is to stay away from [ a-f0-9]
which hexdump is certainly expected to produce - the reason I suggested
a non-ascii character was because hexdump might produce any printable
ascii character in the ascii part (but I suppose one could use e.g. '#'
which isn't among the characters we feed it).

>> >  	} else {
>> > -		a = r == e && buf[e] == '\0';
>> > +		int f = min_t(int, e + 1, buflen);
>> > +
>> > +		test_hexdump_prepare_test(len, rs, gs, test,
>> > sizeof(test), ascii);
>> > +		test[f - 1] = '\0';
>> > +
>> > +		a = r == e && !memchr_inv(buf + f, ' ',
>> > sizeof(buf) - f) && !strcmp(buf, test);
>> >  	}
>> 
>> There's also a bit of duplication in the !buflen and buflen
>> branches. Why not pull the computation of f (the number of expected
>> bytes written) outside and do
>
> See above. buflen == 0 is a special case where buffer shouldn't be
> touched at all.

No, buflen==0 is not that special. We expect hexdump to touch exactly
the first buflen bytes (or only e+1, whichever is smaller), and the
remaining bytes should be untouched. A memcmp handles the first part, a
memchr_inv the second.

Rasmus




  reply	other threads:[~2015-11-23  9:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-11 16:35 [PATCH v1 0/7] hexdump: update test suite Andy Shevchenko
2015-11-11 16:35 ` [PATCH v1 1/7] test_hexdump: rename to test_hexdump Andy Shevchenko
2015-11-19 10:05   ` Rasmus Villemoes
2015-11-11 16:35 ` [PATCH v1 2/7] test_hexdump: introduce test_hexdump_prepare_test() helper Andy Shevchenko
2015-11-19 10:05   ` Rasmus Villemoes
2015-11-11 16:35 ` [PATCH v1 3/7] test_hexdump: go through all possible lengths of buffer Andy Shevchenko
2015-11-19 10:07   ` Rasmus Villemoes
2015-11-20 16:58     ` Andy Shevchenko
2015-11-23  8:59       ` Rasmus Villemoes
2015-11-26 15:22         ` Andy Shevchenko
2015-11-11 16:35 ` [PATCH v1 4/7] test_hexdump: replace magic numbers by their meaning Andy Shevchenko
2015-11-19 10:08   ` Rasmus Villemoes
2015-11-20 16:56     ` Andy Shevchenko
2015-11-11 16:35 ` [PATCH v1 5/7] test_hexdump: check all bytes in real buffer Andy Shevchenko
2015-11-19 10:11   ` Rasmus Villemoes
2015-11-20 16:55     ` Andy Shevchenko
2015-11-23  9:28       ` Rasmus Villemoes [this message]
2015-11-11 16:35 ` [PATCH v1 6/7] test_hexdump: test all possible group sizes for overflow Andy Shevchenko
2015-11-19 10:14   ` Rasmus Villemoes
2015-11-20 16:43     ` Andy Shevchenko
2015-11-23  9:36       ` Rasmus Villemoes
2015-11-11 16:35 ` [PATCH v1 7/7] test_hexdump: print statistics at the end Andy Shevchenko
2015-11-19 10:16   ` Rasmus Villemoes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r3jhyshy.fsf@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).