public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Raphael M Zinsly <rzinsly@linux.ibm.com>
To: Raoni Fassina Firmino <raoni@linux.ibm.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v8] string: Adds tests for test-strncasecmp and test-strncpy
Date: Thu, 6 Aug 2020 11:46:25 -0300	[thread overview]
Message-ID: <74cf61b4-3dbb-e86a-451f-7c6e2d13369d@linux.ibm.com> (raw)
In-Reply-To: <20200731141439.jwqewilnsfrnw266@work-tp>

Hi Raoni,
Thanks for the review

On 31/07/2020 11:14, Raoni Fassina Firmino wrote:
> Hi Raphael,
> 
> Sorry for my late review, hope it is useful.
> 
> I Tested the patch on powerpc-linux-gnu (with kernel ppc64) on top of
> master (0ad926f349) with no problems.
> 
> 
>> diff --git a/string/test-strncasecmp.c b/string/test-strncasecmp.c
> 
> OK.
> 
> 
>> diff --git a/string/test-strncpy.c b/string/test-strncpy.c
> ...
> 
>> +  const size_t maxoffset = 64;
> 
> I am confused about the role of maxoffset == 64 and sizeof(CHAR), if the
> intended value of 64 is for the buffer size in bytes or array elements.
> But in any case I think It surely is not a problem to be larger than the
> minimum 64 bytes, I am just pointing it out because I may be missing
> something.
> 
maxoffset is based on the usual register sizes as suggested here: 
https://sourceware.org/pipermail/libc-alpha/2020-June/114978.html

> 
>> +  /* Put s1 at the maxoffset from the edge of buf1's last page.  */
>> +  s1 = (CHAR *) buf1 + BUF1PAGES * page_size / sizeof(CHAR) - maxoffset;
> 
> I don't understand how the position in the buffer is being calculated
> here, IIUIC you want the last `maxoffset * sizeof(CHAR)` bytes at the
> end of buf1, in this case `page_size / sizeof(CHAR)` doesn't make sense
> for me, but my math may be off.
> 
This was intended for test-wcsncpy, as `wchar_t` is bigger than `char` 
we need more space in the buffer to use the same test. Your suggestion 
makes sense, but the wmemset fails if s1 is placed with just `maxoffset 
* sizeof(CHAR)`, seems it is accessing the protected area.
The page test at test-strnlen also uses `page_size / sizeof(CHAR)`.

> 
>> +  /* s2 needs room to put a string with size of maxoffset + 1 at s2 +
>> +     (maxoffset - 1).  */
>> +  s2 = (CHAR *) buf2 + page_size / sizeof(CHAR) - maxoffset * 2;
> 
> Same as before, but also `maxoffset * 2` guarantees that only one of the
> tests will touch the edge of buf2 page, I am not sure if this is the
> intended case.
> 
What do you mean by one of the tests?
If you are referring to test-strncasecmp it's a different behavior, 
strncpy fills the `dest` string with NULL if the `src` is smaller than 
`N`, so it will reach the maxoffset+1 and the end of buf2.

> 
>> +	    do_one_test (impl, (s2 + off2), (s1 + off1), maxoffset - off1 - 1,
>> +			 maxoffset + 1);
> 
> Reading do_one_test, it seems like len, here as `maxoffset - off1 - 1`,
> should be `maxoffset - off1`, as it is supposed to be the size of src.
> I know that because the trailing '\0' on src, this in practice will not
> be a problem, but for a case when sizeof(src) and sizeof(dest) is the
> same, do_one_test will ended up doing the last bit for len < n.
> 
The len expected on do_one_test is the number of chars in `src`, if you 
take a look at test-stpncpy.c:
#define STRNCPY_RESULT(dst, len, n) ((dst) + ((len) > (n) ? (n) : (len)))
Counting the trailing '\0' will use it to compare with stpncpy's result 
thus getting a false fail.

> nit, and totally optional, you don't need "()" around (s2 + off2) and
> (s1 + off1), I am only mentioning because you didn't use it for the
> other parameters.
> 
> 
> 
> o/
> Raoni
> 

Best Regards,
-- 
Raphael Moreira Zinsly
IBM
Linux on Power Toolchain

  reply	other threads:[~2020-08-06 14:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 18:27 Raphael Moreira Zinsly
2020-07-30 18:35 ` Lucas A. M. Magalhaes
2020-07-31 14:14 ` Raoni Fassina Firmino
2020-08-06 14:46   ` Raphael M Zinsly [this message]
2020-08-14 17:26     ` Raoni Fassina Firmino
2020-08-03 17:49 ` Carlos O'Donell
2020-08-20 22:55 ` Paul E Murphy

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=74cf61b4-3dbb-e86a-451f-7c6e2d13369d@linux.ibm.com \
    --to=rzinsly@linux.ibm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=raoni@linux.ibm.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).