Pete Wyckoff wrote: > [email protected] 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. >
I see where 8 bytes are always shipped in encode_string but I'm not seeing where 8 bytes of '\0' get encoded for a NULL string or if the length of the string is 0. However, adding an 8 byte memset worth of '\0' to *(pptr) in the else (length 0) branch of encode_string also resolves the problem I was seeing. So, your point may make for a better solution. Michael _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
