<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 30, 2013 at 3:31 PM, Eric Blake <span dir="ltr">&lt;<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/30/2013 04:08 PM, Anand Avati wrote:<br>
&gt; Eric,<br>
&gt; Thanks for the insights. I have posted a patch at<br>
&gt; <a href="http://review.gluster.org/6201" target="_blank">http://review.gluster.org/6201</a> which clarifies the usage of<br>
&gt; glfs_readdir_r() and also introduce glfs_readdir().<br>
<br>
</div>Thanks for starting that.  I see an off-by-one in that patch; pre-patch<br>
you did:<br>
<div class="im"><br>
strncpy (dirent-&gt;d_name, gf_dirent-&gt;d_name, 256);<br>
<br>
</div>but post-patch, you have:<br>
<br>
strncpy (dirent-&gt;d_name, gf_dirent-&gt;d_name, GF_NAME_MAX);<br>
<br>
with GF_NAME_MAX set to either NAME_MAX or 255.  This is a bug; you MUST<br>
strncpy at least 1 byte more than the maximum name if you are to<br>
guarantee a NUL-terminated d_name for the user.<br></blockquote><div><br></div><div style>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&#39;t the case before, in case the name was &gt; 255 bytes).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Oh, and NAME_MAX is not guaranteed to be defined as 255; if it is larger<br>
than 255 you are wasting memory compared to XFS, if it is less than 255<br>
[although unlikely], you have made it impossible to return valid file<br>
names to the user.  You may be better off just hard-coding GF_NAME_MAX<br>
to 255 regardless of what the system has for its NAME_MAX.<br></blockquote><div><br></div><div style>Hmm, I don&#39;t think so.. strncpy of 255 bytes on to a buffer guaranteed to be 256 or higher and also guaranteed to be 0-memset&#39;ed cannot return an invalid file name. No?</div>
<div style><br></div><div style>Avati</div><div style><br></div></div></div></div>