Both codes look dangerous and strange. I'm primary a java developer, but from my experience with C, the normal convention is, that in C strings (aka char arrays) are terminated by a NULL character.

Given, that xattrs are basically mappings from strings to arbitrary byte strings (not limited to strings), I can see people storing both variants, but the man page has to say for the names: "An extended attribute's name is a simple NUL-terminated UTF-8 string." (see: http://www.polarhome.com/service/man/?qf=setxattr&af=0&tf=2&of=Darwin). So I would assume "normal" strings to be UTF-8 encoded and terminated by a NUL character.

The man page seems to be contradictory (https://ss64.com/osx/xattr.html):

[...]The metadata is often a null-terminated UTF-8 string, but can also be arbitrary binary data.[...]
[...]Attribute values are usually displayed as strings. However, if nils are detected in the data, the value is displayed in a hexadecimal representation.[...]

encodeString looks ok (it enforces the trailing \0 character), but getXAttr is broken. From my understanding decodeString should be implemented as Native.toString(xattrBuffer, StandardCharsets.UTF_8). Than you also don't need a ByteBuffer and can use a plain byte[]. decodeStringSequence can work on a byte[] and use the String(byte[], int offset, int length, Charset) constructor.

I hope this makes sense to you.

@jrobhoward could you please have a look at #1100? That would be my implementation. With that implementation the behavior of XAttrUtil should match the CLI.

Fixed via #1095