This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] libio: Update tst-fmemopen2.c
- From: Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 15 Jul 2015 15:46:10 +0200
- Subject: Re: [PATCH 2/2] libio: Update tst-fmemopen2.c
- Authentication-results: sourceware.org; auth=none
- References: <55802AFD dot 1040404 at linaro dot org> <559C2D12 dot 6000508 at redhat dot com> <559C4341 dot 3040107 at linaro dot org>
Hi,
i get the following failure for this test on s390-32:
FAIL: third ftello returned 28, expected 100
FAIL: final string is "just
hellod`<80>@^]<92>Ua^C<B0>^?<9E>u<F8>^?<9E>u`", expected "just hellod"
I think the "expected 100" should be "expected 11". See testcode - there
is nbuf instead of nstr as argument to printf:
if (o != nstr)
{
printf ("FAIL: third ftello returned %jd, expected %zu\n",
(intmax_t)o, nbuf);
result = 1;
}
But the return value isn't 11 as tested by tst-fmemopen2.c.
If the testcase is linked against old-fmemopen, this test passes.
The problem is, that buf contains random characters.
fmemopen performs c->maxpos = strnlen (c->buffer, len);
Thus maxpos depends on the random characters in buf.
If the current position is set to the end of buffer with:
fseeko (fp, 0, SEEK_END)
, then ftello (fp); returns the value of "c->maxpos".
But according to
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html:
"The stream shall also maintain the size of the current buffer contents;
use of fseek() or fseeko() on the stream with SEEK_END shall seek
relative to this size. For modes r and r+ the size shall be set to the
value given by the size argument. For modes w and w+ the initial size
shall be zero and for modes a and a+ the initial size shall be either
the position of the first null byte in the buffer or the value of the
size argument if no null byte is found.",
the initial size of the current buffer should be 0 for modes w and w+
instead of the first null byte in buffer.
For w+, fmemopen sets the fist character to zero before strnlen is called:
if (mode[0] == 'w' && mode[1] == '+')
c->buffer[0] = '\0';
The old-fmemopen function sets the first character to zero for w and w+:
if (mode[0] == 'w')
c->buffer[0] = '\0';
The test passes on s390-32 if the first character (or at a lower index
than 11) is set to zero just before the fmemopen call.
If buf contains a string larger than "hello world", the testcase also
fails on s390-64/x86_64.
Failure:
FAIL: third ftello returned 20, expected 100
FAIL: final string is "just hellod234567890", expected "just hellod"
if buf contains the following string before the fmemopen call:
strcpy (buf, "12345678901234567890");
FILE *fp = fmemopen (buf, nbuf, "w");
Is this is a bug in the new fmemopen implementation?!
If it isn't, the testcase should initialize buf with zeros.
Bye
Stefan
On 07/07/2015 11:23 PM, Adhemerval Zanella wrote:
On 07-07-2015 16:48, Carlos O'Donell wrote:
On 06/16/2015 09:56 AM, Adhemerval Zanella wrote:
Reposting to see if I can land it for 2.22.
--
This patch updates tst-fmemopen2 to check for fmemopen with NULL buffer
inputs and also refactor the code a bit.
The test relies on a POSIX compliant fmemopen implementation.
Tested on x86_64, i386, aarch64, and arm-linux-gnueabihf.
* stdio-common/tst-fmemopen2.c (do_test): Add test for NULL and zero
length buffers.
* stdio-common/tst-fmemopen.c (do_test): Refactor to use
test-skeleton.c.
OK with nits fixed and after you checkin the fmemopen fixes.
Thanks for the review, I have updated the patch with all your requests and
I have also added some more comments about the tests intentions.