putdata (3) - Linux Manuals

putdata: write data to a dirfile database


putdata --- write data to a dirfile database


#include <getdata.h>
size_t putdata(DIRFILE *dirfile, const char *field_code, off_t first_frame, off_t first_sample, size_t num_frames, size_t num_samples, gd_type_t data_type, const void *data_in);


The putdata() function writes data to a dirfile(5) database specified by dirfile for the field field_code, which may not contain a representation suffix. It writes num_frames frames plus num_samples samples to this field, starting first_sample samples past frame first_frame. The data is read from the user-supplied buffer data_in, which is has a data type specified by data_type. This interface cannot write to field representations.

The dirfile argument must point to a valid DIRFILE object previously created by a call to dirfile_open(3).

The first sample written will be

first_frame * samples_per_frame + first_sample
as measured from the start of the dirfile, where samples_per_frame is the number of samples per frame as returned by get_spf(3). The number of samples which putdata() attempts to write is, similarly,
num_frames * samples_per_frame + num_samples.
Although calling putdata() using both samples and frames is possible, the function is typically called with either num_samples and first_sample, or num_frames and first_frames, equal to zero.

The data_type argument should be one of the following symbols, which indicates the type of the input data:

unsigned 8-bit integer
signed (two's complement) 8-bit integer
unsigned 16-bit integer
signed (two's complement) 16-bit integer
unsigned 32-bit integer
signed (two's complement) 32-bit integer
unsigned 64-bit integer
signed (two's complement) 64-bit integer
IEEE-754 standard 32-bit single precision floating point number
IEEE-754 standard 64-bit double precision floating point number

The type of the input data need not be the same as the type of the data stored in the database. Type conversion will be performed as necessary to write the appropriate type. The argument data_in must point to a valid memory location of containing all the data to be written.


In all cases, putdata() returns the number of samples (not bytes) successfully written to the database, which may be zero if an error has occurred.

If an error has occurred, the dirfile error will be set to a non-zero value. Possible error values are:

The specified dirfile was opened read-only.
The library was unable to allocate memory.
The field specified by field_code, or one of the fields it uses for input, was not found in the database.
An invalid dirfile was supplied.
Either the field specified by field_code, or one of the fields it uses for input, was of MULTIPLY type, or LINCOM type with more than one input fields. In this case, putdata() has no knowledge on how to partition the input data. Alternately, the caller may have attempted to write to the implicit INDEX field, which is not possible.
The representation suffix specified in field_code was not recognised, or an attempt was made to write to a field representation, instead of the underlying field.
An invalid data_type was specified.
An internal error occurred in the library while trying to perform the task. This indicates a bug in the library. Please report the incident to the maintainer.
An error occurred while trying to read a LINTERP table from disk.
The data of the RAW field backing field_code was protected from change by a PROTECT directive.
An attempt was made to write data before the beginning-of-frame marker for field_code, or the raw field it depends on.
An error occurred while trying to open, read from, or write to a file on disk containing a raw field.
Too many levels of recursion were encountered while trying to resolve field_code. This usually indicates a circular dependency in field specification in the dirfile.
Reading from dirfiles with the encoding scheme of the specified dirfile is not supported by the library. See dirfile-encoding(5) for details on dirfile encoding schemes. The dirfile error may be retrieved by calling get_error(3). A descriptive error string for the last error encountered can be obtained from a call to get_error_string(3).