Re: [PATCH 2/2] libio: Update tst-fmemopen2.c

[Stefan Liebler <stli at linux dot vnet dot ibm dot com>]

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.