[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.
> 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
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
