(define-serializable-cstruct _id ([field-id type-expr] ...) property ...)
property = #:alignment alignment-expr | #:malloc-mode malloc-mode-expr | #:serialize-inplace | #:deserialize-inplace | #:property prop-expr val-expr
Instances of the new type fulfill the serializable? predicate and can be used with serialize and deserialize. Serialization may fail if one of the fields contains an arbitrary pointer, an embedded non-serializable C struct, or a pointer to a non-serializable C struct. Array-types are supported as long as they don’t contain one of these types.
When #:serialize-inplace is specified, the serialized representation shares memory with the C struct object. While being more efficient, especially for large objects, changes to the object after serialization may lead to changes in the serialized representation.
A #:deserialize-inplace option reuses the memory of the serialized representation, if possible. This option is more efficient for large objects, but it may fall back to allocation via malloc-mode-expr for cyclic structures. As the allocation mode of the serialized representation will be 'atomic by default or may be arbitrary if #:serialize-inplace is specified, inplace deserialisation should be used with caution whenever the object contains pointers.
When the C struct contains pointers, it is advisable to use a custom allocator. It should be based on a non-moving-memory allocation like 'raw, potentially with manual freeing to avoid memory leaks after garbage collection.