[Gluster-devel] glfs_readdir_r is painful

[Anand Avati]

On Wed, Oct 30, 2013 at 3:31 PM, Eric Blake <eblake at redhat.com> wrote:

> On 10/30/2013 04:08 PM, Anand Avati wrote:
> > Eric,
> > Thanks for the insights. I have posted a patch at
> > http://review.gluster.org/6201 which clarifies the usage of
> > glfs_readdir_r() and also introduce glfs_readdir().
>
> Thanks for starting that.  I see an off-by-one in that patch; pre-patch
> you did:
>
> strncpy (dirent->d_name, gf_dirent->d_name, 256);
>
> but post-patch, you have:
>
> strncpy (dirent->d_name, gf_dirent->d_name, GF_NAME_MAX);
>
> with GF_NAME_MAX set to either NAME_MAX or 255.  This is a bug; you MUST
> strncpy at least 1 byte more than the maximum name if you are to
> guarantee a NUL-terminated d_name for the user.
>

The buffer is guaranteed to be 0-inited, and strncpy with 255 is now
guaranteed to have a NULL terminated string no matter how big the name was
(which wasn't the case before, in case the name was > 255 bytes).


>
> Oh, and NAME_MAX is not guaranteed to be defined as 255; if it is larger
> than 255 you are wasting memory compared to XFS, if it is less than 255
> [although unlikely], you have made it impossible to return valid file
> names to the user.  You may be better off just hard-coding GF_NAME_MAX
> to 255 regardless of what the system has for its NAME_MAX.
>

Hmm, I don't think so.. strncpy of 255 bytes on to a buffer guaranteed to
be 256 or higher and also guaranteed to be 0-memset'ed cannot return an
invalid file name. No?

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20131030/af9c4db8/attachment-0001.html>