[Pvfs2-developers] here_string endecode bug?

Rob Ross rross at mcs.anl.gov
Thu Sep 3 12:49:33 EDT 2009


Drop an assert in there? -- Rob

On Sep 3, 2009, at 11:19 AM, Pete Wyckoff wrote:

> mtmoore at clemson.edu wrote on Thu, 03 Sep 2009 11:51 -0400:
>> In looking at some issues I was having with the encoding of  
>> PVFS_dirent
>> structs in requests I saw an inconsistency in how here_strings are
>> encoded and decoded. encode_string memcpys strings starting at  
>> *(pptr)+4
>> unless it's length 0 in which case it sets *(pptr) to 0. However,
>> decode_here_string always copys from *(pptr) + 4. So, if d_name is an
>> empty string when encoded d_name gets 1 byte of *(pptr)+4 instead  
>> of 0
>> on decoding.
>>
>> The fix is just to handle decoding like encoding. Is there a reason  
>> for
>> always copying to *(pptr)+4 in decode_here_string? Is this something
>> that should be changed?
>
> encode_string always ships at least 8 bytes.  For a null string,  
> that's 8
> bytes of zeroes.  Decoding a null "here" string will use one of
> those zero bytes to set pbuf[0] = '\0'.  I figured it would be nice
> to make sure the string was set to NULL.
>
>> diff -r1.24.24.1 endecode-funcs.h
>> 131c131,134
>> <     memcpy(pbuf, *(pptr) + 4, len + 1); \
>> ---
>>>>    if( len ) \
>>>>        memcpy(pbuf, *(pptr) + 4, len + 1); \
>>>>    else \
>>>>        memcpy(pbuf, *(pptr), len + 1); \
>
> This patch had better be a noop.
>
> You might add some comments in there so hte code is a bit less
> opaque.
>
> 		-- Pete
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers



More information about the Pvfs2-developers mailing list