Subject: Re: bug#6555: stat enhancement

From: Jim Meyering <[email-masked]>
Date: Mon, 05 Jul 2010 15:50:13 +0200

A Burgie wrote:
> On Mon, Jul 5, 2010 at 06:48, Jim Meyering <[email-masked]> wrote:
>>> The idea seems sensible.
>>
>> I think so, too.
>> However, the patch that adds the option would do well to add
>> a test that exercises it and to mention it in the NEWS file.
>> Your change will qualify as "significant".
>> Can you file a copyright assignment?  Here are guidelines:
>>
>>    http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING#n327
>
> I was wondering if that would apply, but I did not think it would as
> it was not really my own code (I copied from previously-GPL'd code and
> only, perhaps, added three or four lines of my own).  Please confirm
> if I am mistaken on this.

I figured that between moving that function into a file on its
own, declaring the function in its own header file,
adjusting df.c and stat.c to include the new .h file,
adjusting src/Makefile.am to list the new file, adding a test and
adding to NEWS you would end up adding more than 10 or 15 lines.

Oh.  And documentation.  You'll want to add a line or two to
the section on stat in doc/coreutils.texi.

If it's too much work on the portability front (wouldn't surprise me),
it may be ok simply to put the statically-declared function body
in a new .c file and include the .c file from each of stat.c and df.c.

BTW, please adjust this part of your patch not to dereference NULL
when find_mount_point fails:

  +    case 'm':
  +      out_string (pformat, prefix_len, find_mount_point (filename, statbuf));

Also, I'm a little reluctant to change the default format to
add an entire new line just for "Mountpoint: %s\n".
There is value in not changing the number of lines in the default output:
compatibility.