Re: [PATCH 1/3] libio: Refactor tst-fmemopen to use test-skeleton.c

[Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>]

On 25-06-2014 10:33, Adhemerval Zanella wrote:
> On 23-06-2014 13:06, Siddhesh Poyarekar wrote:
>> On Mon, Jun 23, 2014 at 10:20:21AM -0300, Adhemerval Zanella wrote:
>>> This patch refactor tst-fmemopen.c to use test-skeleton.c.  No logic
>>> changes are added.
>>>
>>> --
>>>
>>> 	* stdio-common/tst-fmemopen.c (do_test): Refactor to use
>>> 	test-skeleton.c.
>>>
>>> ---
>>>
>>> diff --git a/stdio-common/tst-fmemopen.c b/stdio-common/tst-fmemopen.c
>>> index 206bfd7..756d6fe 100644
>>> --- a/stdio-common/tst-fmemopen.c
>>> +++ b/stdio-common/tst-fmemopen.c
>>> @@ -8,10 +8,24 @@
>>>  #include <sys/stat.h>
>>>  #include <sys/types.h>
>>>  
>>> -int
>>> -main (int argc, char **argv)
>>> +static char *test_file;
>>> +
>>> +static void
>>> +do_prepare (int argc, char *argv[])
>>> +{
>>> +  /* Construct the test file name based on ARGV[0], which will be
>>> +     an absolute file name in the build directory.  Don't touch the
>>> +     source directory, which might be read-only.  */
>>> +  if (asprintf (&test_file, "%s.test", argv[0]) < 0)
>>> +    {
>>> +      puts ("asprintf failed\n");
>>> +      exit (EXIT_FAILURE);
>>> +    }
>>> +}
>>> +
>>> +static int
>>> +do_test (void)
>>>  {
>>> -  char *test_file;
>>>    const char blah[] = "BLAH";
>>>    FILE *fp;
>>>    char *mmap_data;
>>> @@ -19,17 +33,14 @@ main (int argc, char **argv)
>>>    struct stat fs;
>>>    const char *cp;
>>>  
>>> -  /* Construct the test file name based on ARGV[0], which will be
>>> -     an absolute file name in the build directory.  Don't touch the
>>> -     source directory, which might be read-only.  */
>>> -  if (argc != 1 || asprintf (&test_file, "%s.test", argv[0]) < 0)
>>> -    exit (99);
>>> -
>>>    /* setup the physical file, and use it */
>>>    if ((fp = fopen (test_file, "w+")) == NULL)
>>> -    exit (1);
>>> +    return 1;
>>>    if (fwrite (blah, 1, strlen (blah), fp) != strlen (blah))
>>> -    exit (2);
>>> +    {
>>> +      fclose (fp);
>>> +      return 1;
>> return 2?  Not that it matters much, but it looked like you wanted to
>> maintain compatibility there.  Looks OK otherwise and can go in
>> indepdendently.
> Thanks, I'll fix it.
>
>
Pushed upstream as af83568d3fdc84884378317504b4a2b76371bf8b.