Use ByteSpan for string arguments in command handlers and attribute

[erjiaqing]

Problem

The Zigbee protocol uses Pascal style string, which has 1/2 bytes of length in the front of data instead of NULL terminated. The code in cluster handlers, the attribute managements should accept a ByteSpan.

Proposed Solution

Use ByteSpan for string arguments in command handlers and attribute. Update codegen.

[bzbarsky-apple]

We should use Span<char>, not ByteSpan, imo.... It would more accurately represent what's actually going on.

[erjiaqing]

We should use Span<char>, not ByteSpan, imo.... It would more accurately represent what's actually going on.

I would still suggest using ByteSpan, per spec, its encoding is not specified, thus we may encounter issues on some platforms if Span<char> is used, the uint8_t is 8bit unsiged integer type, but char can be signed or unsigned integer per C++ spec.

[bzbarsky-apple]

per spec, its encoding is not specified

Per CHIP spec the encoding of a string is specified to be UTF-8.

but char can be signed or unsigned integer per C++ spec.

That is a good point, because code units are of course unsigned. Nevertheless, the typical API that accepts UTF-8 strings uses char *; if we use something else we're going to need a bunch of casts in either SDK code that interfaces with app APIs or in app code that tries to do something with these strings.... Note that the TLV PutString/GetString APIs use char *.

I would also be in favor of adding a TLVReader::GetDataPtr (or other name) that hands out char * for the UTF-8 string type and fails for all other types, and perhaps restricting the current GetDataPtr to just the octet string type.

Another option for now would be to just add a DataModelString type, typedefed to whatever we want at the moment (though we still have to decide that), but then we can change the typedef later as needed if we discover that our choice was wrong. That would at least avoid us making changes in all the places where it's just passed through.

But I pretty strongly suspect that we should follow common convention and use char * for UTF-8 strings.

[holbrookt]

Any update on this? Still blocking OTA