cp is going a byte too far after it writes both name and value.
This doesn't cause any actual errors because it "get's lucky". It results in the same byte pattern one wants, but only because the cp buf starts out as all zero's.
Your comment and the patch don't seem to line up. The code is still going a byte beyond the name and value. The final nul byte gets written to ensure that there will be a double-nul, which is what the schema defines as the actual end-of-attribute marker (leaving room to write different data before the marker). Regardless, this patch was applied as it addresses an issue where a null name or null value were causing them to not write their nul byte. If both happened to be null, it would actually mess up the double-nul marker assumption.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your comment and the patch don't seem to line up. The code is still going a byte beyond the name and value. The final nul byte gets written to ensure that there will be a double-nul, which is what the schema defines as the actual end-of-attribute marker (leaving room to write different data before the marker). Regardless, this patch was applied as it addresses an issue where a null name or null value were causing them to not write their nul byte. If both happened to be null, it would actually mess up the double-nul marker assumption.