This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] avoid stat/fstat in statvfs/fstatvfs
Roland McGrath <roland@hack.frob.com> wrote:
> That looks fine.
>
> > * sysdeps/unix/sysv/linux/fstatvfs.c (fstatvfs):
> > Pass fd to __internal_statvfs instead of calling fstat64.
> > * sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
> > Pass fd to __internal_statvfs64 instead of calling fstat64.
>
> In a case like this, it's usual practice to write just "Likewise."
> for the second one. But that's not mandatory.
Ah, I considered "Likewise." but figured maybe the difference between
"__internal_statvfs64" and "__internal_statvfs" might be significant
(even though it's really the same function)
> Ideally there should be a bugzilla item filed for this issue.
> Even though it's not really user-visible per se (for user-visible changes
> we have a hard rule requiring bugzilla filings), a change that is being
> tracked by downstream bug reports and such is easier for everyone to
> keep track of if there is a BZ# to go with it. If you file one,
> use [BZ #nnn] in the log entry as you see done elsewhere in ChangeLog.
I'm not fan of signing into websites or filling out <form> elements,
so I am hoping to avoid that. I haven't looked too closely at BZ,
maybe there's an email/command-line interface like Debian BTS?
> Do you have copyright papers on file with the FSF? I don't see a record
> for you.
No. I consider this a trivial change, so I hope I don't have to.
> Do you want someone to commit this for you? If you think it likely you'll
> post more changes in the future, then we encourage you to get set up to do
> your own commits (on specific approval, of course). The details are on
> the wiki.
I would like somebody to commit this for me, I don't expect more
changes. It took me many, many years of using glibc to find my first
minor issue with it :)