This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 2/2] libio: Update tst-fmemopen2.c
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Cc: Carlos O'Donell <carlos at redhat dot com>
- Date: Wed, 15 Jul 2015 11:44:14 -0300
- 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> <55A66422 dot 5010306 at linux dot vnet dot ibm dot com>
Thanks for checking it.
On 15-07-2015 10:46, Stefan Liebler wrote:
> 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;
> Is this is a bug in the new fmemopen implementation?!
> If it isn't, the testcase should initialize buf with zeros.
Yes, it is an issue with new implementation since it requires to open the stream
to first null byte (thus the strnlen) only for 'a' mode. The follow patch should
fix the behaviour you are seeing:
diff --git a/libio/fmemopen.c b/libio/fmemopen.c
index e6e6a49..3ab3e8d 100644
@@ -150,7 +150,7 @@ __fmemopen (void *buf, size_t len, const char *mode)
- c = (fmemopen_cookie_t *) malloc (sizeof (fmemopen_cookie_t));
+ c = (fmemopen_cookie_t *) calloc (sizeof (fmemopen_cookie_t), 1);
if (c == NULL)
@@ -165,7 +165,6 @@ __fmemopen (void *buf, size_t len, const char *mode)
c->buffer = '\0';
- c->maxpos = 0;
@@ -182,7 +181,8 @@ __fmemopen (void *buf, size_t len, const char *mode)
if (mode == 'w' && mode == '+')
c->buffer = '\0';
- c->maxpos = strnlen (c->buffer, len);
+ if (mode == 'a')
+ c->maxpos = strnlen (c->buffer, len);
Carlos, if you allow I would like to push this modification for 2.22.
> 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
>>> 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.