[util] Create ByteSpan class for holding OCTET_STRING type values in ZCL encoder #5122
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pullapprove
bot
requested review from
andy31415,
bzbarsky-apple,
chrisdecenzo,
hawk248,
jelderton,
msandstedt,
mspang,
saurabhst,
wehale and
woody-apple
bzbarsky-apple
requested changes
Mar 3, 2021
erjiaqing
force-pushed
the
zcl_bytes_data
branch
from
d910804 to
93ab134
Compare
erjiaqing
force-pushed
the
zcl_bytes_data
branch
3 times, most recently
from
be0784a to
724c3bb
Compare
erjiaqing
force-pushed
the
zcl_bytes_data
branch
2 times, most recently
from
5f40b73 to
e6f39e9
Compare
vivien-apple
reviewed
Mar 4, 2021
examples/all-clusters-app/all-clusters-common/gen/CHIPClustersObjc.h
Outdated
Show resolved
Hide resolved
erjiaqing
force-pushed
the
zcl_bytes_data
branch
from
e6f39e9 to
30bc91b
Compare
erjiaqing
force-pushed
the
zcl_bytes_data
branch
from
30bc91b to
933b628
Compare
erjiaqing
force-pushed
the
zcl_bytes_data
branch
from
933b628 to
5f85798
Compare
andy31415
reviewed
Mar 4, 2021
erjiaqing
force-pushed
the
zcl_bytes_data
branch
from
5f85798 to
36581ad
Compare
erjiaqing
changed the title
erjiaqing
changed the title
andy31415
approved these changes
Mar 4, 2021
examples/all-clusters-app/all-clusters-common/gen/CHIPClustersObjc.mm
Outdated
Show resolved
Hide resolved
| @@ -117,7 +128,7 @@ public: | |||
|
|
|||
| chip::Controller::{{asCamelCased parent.name false}}Cluster cluster; | |||
| cluster.Associate(device, endpointId); | |||
| return cluster.{{asCamelCased name false}}(onSuccessCallback->Cancel(), onFailureCallback->Cancel(){{#chip_server_cluster_command_arguments}}, {{#if (isByteString type)}} reinterpret_cast<uint8_t*>(m{{asCamelCased label false}}), static_cast<uint32_t>(strlen(m{{asCamelCased label false}})){{else}}m{{asCamelCased label false}}{{/if}}{{/chip_server_cluster_command_arguments}}); | |||
| return cluster.{{asCamelCased name false}}(onSuccessCallback->Cancel(), onFailureCallback->Cancel(){{#chip_server_cluster_command_arguments}}, {{#if (isByteString type)}} chip::ByteSpan(reinterpret_cast<uint8_t *>(m{{asCamelCased label false}}), strlen(m{{asCamelCased label false}})){{else}}m{{asCamelCased label false}}{{/if}}{{/chip_server_cluster_command_arguments}}); | |||
There was a problem hiding this comment.
Suggested change
| return cluster.{{asCamelCased name false}}(onSuccessCallback->Cancel(), onFailureCallback->Cancel(){{#chip_server_cluster_command_arguments}}, {{#if (isByteString type)}} chip::ByteSpan(reinterpret_cast<uint8_t *>(m{{asCamelCased label false}}), strlen(m{{asCamelCased label false}})){{else}}m{{asCamelCased label false}}{{/if}}{{/chip_server_cluster_command_arguments}}); | |
| return cluster.{{asCamelCased name false}}(onSuccessCallback->Cancel(), onFailureCallback->Cancel(){{#chip_server_cluster_command_arguments}}, {{#if (isByteString type)}} chip::ByteSpan(chip::chip::Uint8::from_char(m{{asCamelCased label false}}), strlen(m{{asCamelCased label false}})){{else}}m{{asCamelCased label false}}{{/if}}{{/chip_server_cluster_command_arguments}}); |
I assume there will be a followup at some point to store a ByteSpan in the member, right?
sagar-apple
reviewed
Mar 4, 2021
| @@ -378,8 +378,8 @@ NS_ASSUME_NONNULL_BEGIN | |||
| timeoutMs:(uint32_t)timeoutMs | |||
| completionHandler:(ResponseHandler)completionHandler; | |||
| - (void)commissioningComplete:(ResponseHandler)completionHandler; | |||
| - (void)setFabric:(char *)fabricId | |||
| fabricSecret:(char *)fabricSecret | |||
| - (void)setFabric:(NSString)fabricId | |||
There was a problem hiding this comment.
This won't compile, should be NSString *
examples/all-clusters-app/all-clusters-common/gen/CHIPClustersObjc.mm
Outdated
Show resolved
Hide resolved
mspang
approved these changes
Mar 5, 2021
erjiaqing
force-pushed
the
zcl_bytes_data
branch
from
1bec859 to
094f77f
Compare
erjiaqing
force-pushed
the
zcl_bytes_data
branch
from
094f77f to
5a83a56
Compare
bzbarsky-apple
approved these changes
Mar 5, 2021
erjiaqing
changed the title
|
Updated title of this PR, will submit another PR for decoder / handler side. |
|
@msandstedt PTAL |
msandstedt
approved these changes
Mar 5, 2021
jelderton
approved these changes
Mar 5, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
The ZCL codegen does not support OCTET_STRING for strings which is not expected to be non-null terminated. This is a critical issue for codegen on the encoder side, which cannot encode OCTET_STRING correctly.
Summary of Changes
This PR introduces the BytesData type for holding OCTET_STRING type in ZCL without the ownership of the data.
#4503