Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-slice bytes support #439

Merged
merged 27 commits into from
Jun 28, 2024

Conversation

DenisBiryukov91
Copy link
Contributor

@DenisBiryukov91 DenisBiryukov91 commented Jun 24, 2024

Multi-slice bytes support.
Support for pair / iterator serialization / deserialization;
Implementation of z_bytes_iterator, z_bytes_reade and z_bytes_writer; closes #445, closes #446
Implementation of z_bytes_empty(...), z_bytes_is_empty(...) and z_bytes_len(...); closes #444
closes #425

@DenisBiryukov91 DenisBiryukov91 marked this pull request as draft June 24, 2024 17:15
@DenisBiryukov91 DenisBiryukov91 marked this pull request as ready for review June 27, 2024 12:08

_z_arc_slice_t _z_arc_slice_get_subslice(const _z_arc_slice_t* s, size_t offset, size_t len) {
assert(offset + len <= s->len);
assert(s->slice.in != NULL || (len == 0 && offset == 0));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Asserts will be removed on RELEASE compile, I'd say we should use them only in tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is internal function, thus I believe asserts here are justified, since they clearly represent the contract on input arguments (i.e. under no circumstances they are supposed to be violated, no matter what the user input would be to the public api).

Copy link
Contributor

@jean-roland jean-roland Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if the check is important, assert is not ideal:

  • They disappear when NDEBUG is defined.
  • They don't make much sense on bare metal systems and as such might be unavailable.
  • It violates Misra rule 21.8 The library functions abort, exit, getenv and system of shall not be used.

So if the error is somewhat recoverable, then the function should return an error which then propagate or is processed.

If it's truly unrecoverable, I guess we need to create a portable mechanism that doesn't violate the Misra rule.

Copy link
Contributor Author

@DenisBiryukov91 DenisBiryukov91 Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this error is supposed to be non-recoverable (but likely will be caught before in some higher level api and bubbled up through error propagation mechanism). But as I said it is internal function and thus asserts are supposed to help catching this violation during testing/development. Using asserts is really a standard practice in specifying contracts, I do not see why we should complicate it. They really contribute to a safer development process with little to no overhead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I didn't understand the intent correctly. if it's used as in-place testing, then it's fine.

Maybe it could be worth to wrap them, in case we stumble upon an availability issue on some platforms but it's not in the scope of this PR.

@@ -66,6 +66,11 @@ static inline void _z_noop_copy(void *dst, const void *src) {
(void)(src);
}

static inline void _z_noop_move(void *dst, void *src) {
(void)(dst);
(void)(src);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should use the _ZP_UNUSED macro for these.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@jean-roland
Copy link
Contributor

Fixes (at least partially) #419

Copy link
Member

@sashacmc sashacmc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@milyin milyin merged commit 2668357 into eclipse-zenoh:dev/1.0.0 Jun 28, 2024
50 checks passed
@DenisBiryukov91 DenisBiryukov91 deleted the dev/multi_slice_bytes branch July 2, 2024 14:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants