SubObjectAccess

zencan_node::object_dict

Trait SubObjectAccess 

Source 
pub trait SubObjectAccess: Sync + Send {
    // Required methods
    fn read(&self, offset: usize, buf: &mut [u8]) -> Result<usize, AbortCode>;
    fn read_size(&self) -> usize;
    fn write(&self, data: &[u8]) -> Result<(), AbortCode>;

    // Provided methods
    fn begin_partial(&self) -> Result<(), AbortCode> { ... }
    fn write_partial(&self, _buf: &[u8]) -> Result<(), AbortCode> { ... }
    fn end_partial(&self) -> Result<(), AbortCode> { ... }
}
Expand description

Allow transparent byte level access to a sub object

Required Methods§

Source

fn read(&self, offset: usize, buf: &mut [u8]) -> Result<usize, AbortCode>

Read data from the sub object

Read up to buf.len() bytes, starting at offset

§Arguments
  • offset: The offset into the object to begin the read
  • buf: The output buffer to fill
§Returns

The number of bytes read into buf, on success

§Errors
Source

fn read_size(&self) -> usize

Return the amount of data which can be read

This should return the maximum number of bytes which can be read from the object

For most objects, this is simply it’s allocated size – e.g. for a UInt32 DataType read_size always return 4. Others may have variable or run-time determined size, for example VisibleString objects can ctonshorter than their allocated size.

Note: Callers cannot assume that a call to read will return the same number of bytes as read_size. It is possible for the available number of bytes to change between a call to read_size and a subsequent call to read.

Source

fn write(&self, data: &[u8]) -> Result<(), AbortCode>

Write data to the sub object

For most objects, the length of data must match the size of the object exactly. However, for some objects, such as Domain, VisibleString, UnicodeString, or objects with custom callback implementations it may be possible to write shorter values.

§Errors

Other error types may be returned by special purpose objects implemented via custom callback.

Provided Methods§

Source

fn begin_partial(&self) -> Result<(), AbortCode>

Begin a multi-part write to the object

Not all objects support partial writes. Primarily it is large objects which support it in order to allow transfer of data in multiple blocks. It is up to the application to ensure that no other writes occur while a partial write is in progress, or else the object data may be corrupted and/or a call to write_partial may return an abort code on a subsequent call.

Partial writes should always be performed according to the following sequence:

  • One call to begin_partial
  • Zero or more calls to write_partial
  • One call to end_partial
§Errors
Source

fn write_partial(&self, _buf: &[u8]) -> Result<(), AbortCode>

Write part of multi-part data to the object

Calls to write_partial must be preceded by a call to begin_partial, and followed by a call to end_partial.

§Errors
Source

fn end_partial(&self) -> Result<(), AbortCode>

Finish a multi-part write

Implementors§