Drop an assert in there? -- Rob
On Sep 3, 2009, at 11:19 AM, 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.
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
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
