erickguan commented on code in PR #7807:
URL: https://github.com/apache/opendal/pull/7807#discussion_r3486205417
##########
bindings/c/include/opendal.h:
##########
@@ -92,9 +92,11 @@ typedef struct opendal_presigned_request_inner
opendal_presigned_request_inner;
/**
* \brief opendal_bytes carries raw-bytes with its length
*
- * The opendal_bytes type is a C-compatible substitute for Vec type
- * in Rust, it has to be manually freed. You have to call opendal_bytes_free()
- * to free the heap memory to avoid memory leak.
+ * The opendal_bytes type is a C-compatible substitute for Vec type in Rust.
Review Comment:
👍
##########
bindings/c/src/types.rs:
##########
@@ -85,6 +87,22 @@ impl opendal_bytes {
}
}
}
+
+ pub(crate) fn to_buffer(&self) -> opendal::Result<Buffer> {
+ if self.len == 0 {
Review Comment:
I am also thinking we could make checks somewhat more strict - to disallow
users passing in len == 0 and data != nullptr.
##########
bindings/c/include/opendal.h:
##########
@@ -92,9 +92,11 @@ typedef struct opendal_presigned_request_inner
opendal_presigned_request_inner;
/**
* \brief opendal_bytes carries raw-bytes with its length
*
- * The opendal_bytes type is a C-compatible substitute for Vec type
- * in Rust, it has to be manually freed. You have to call opendal_bytes_free()
- * to free the heap memory to avoid memory leak.
+ * The opendal_bytes type is a C-compatible substitute for Vec type in Rust.
+ * For buffers returned by OpenDAL C APIs, call opendal_bytes_free() to free
+ * the heap memory and avoid memory leaks. For caller-owned input buffers
+ * passed to OpenDAL C APIs, the caller keeps ownership and must not call
+ * opendal_bytes_free() on them.
Review Comment:
Do we really want to allow non-null pointers when len is 0? e.g. malloc(0)'s
non-null result.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
