gd_getdata(3) GETDATA gd_getdata(3)NAMEgd_getdata — retrieve data from a dirfile database
SYNOPSIS
#include <getdata.h>
size_t gd_getdata(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 return_type, void *data_out);
DESCRIPTION
The gd_getdata() function queries a dirfile(5) database specified by
dirfile for the field field_code. It fetches num_frames frames plus
num_samples samples from this field, starting first_sample samples past
frame first_frame. The data is converted to the data type specified by
return_type, and stored in the user-supplied buffer data_out.
The field_code may contain one of the representation suffixes listed in
dirfile-format(5). If it does, gd_getdata() will compute the appropri‐
ate complex norm before returning the data.
The dirfile argument must point to a valid DIRFILE object previously
created by a call to gd_open(3). The argument data_out must point to a
valid memory location of sufficient size to hold all data requested.
Unless using GD_HERE (see below), the first sample returned 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 gd_spf(3). The number
of samples fetched is, similarly,
num_frames * samples_per_frame + num_samples.
Although calling gd_getdata() using both samples and frames is possi‐
ble, the function is typically called with either num_samples and
first_sample, or num_frames and first_frames, equal to zero.
Instead of explicitly specifying the origin of the read, the caller may
pass the special symbol GD_HERE as first_frame. This will result in
the read occurring at the current position of the I/O pointer for the
field (see gd_seek(3) for a discussion of field I/O pointers). In this
case, the value of first_sample is ignored.
The return_type argument should be one of the following symbols, which
indicates the desired return type of the data:
GD_UINT8 unsigned 8-bit integer
GD_INT8 signed (two's complement) 8-bit integer
GD_UINT16 unsigned 16-bit integer
GD_INT16 signed (two's complement) 16-bit integer
GD_UINT32 unsigned 32-bit integer
GD_INT32 signed (two's complement) 32-bit integer
GD_UINT64 unsigned 64-bit integer
GD_INT64 signed (two's complement) 64-bit integer
GD_FLOAT32 IEEE-754 standard 32-bit single precision floating
point number
GD_FLOAT64 IEEE-754 standard 64-bit double precision floating
point number
GD_COMPLEX64
C99-conformant 64-bit single precision complex number
GD_COMPLEX128
C99-conformant 128-bit double precision complex num‐
ber
GD_NULL the null type: the database is queried as usual, but
no data is returned. In this case, data_out is ig‐
nored and may be NULL.
The return type of the data need not be the same as the type of the da‐
ta stored in the database. Type conversion will be performed as neces‐
sary to return the requested type. If the field_code does not indicate
a representation, but conversion from a complex value to a purely real
one is required, only the real portion of the requested vector will be
returned.
Upon successful completion, the I/O pointer of the field will be on the
sample immediately following the last sample returned. On error, the
position of the I/O pointer is not specified, and may not even be well
defined.
Behaviour While Reading Specific Field Types
PHASE: A forward-shifted PHASE field will always encounter the end-of-
field marker before its input field does. This has ramifica‐
tions when reading streaming data with gd_getdata() and using
gd_nframes(3) to gauge field lengths (that is: a forward-shifted
PHASE field always has less data in it than gd_nframes(3) im‐
plies that it does). As with any other field, gd_getdata() will
return a short count whenever a read from a PHASE field encoun‐
ters the end-of-field marker.
Backward-shifted PHASE fields do not suffer from this problem,
since gd_getdata() pads reads past the beginning-of-field marker
with NaN or zero as appropriate. Database creators who wish to
use the PHASE field type with streaming data are encouraged to
work around this limitation by only using backward-shifted PHASE
fields, by writing RAW data at the maximal frame lag, and then
back-shifting all data which should have been written earlier.
Another possible work-around is to write systematically less da‐
ta to the reference RAW field in proportion to the maximal for‐
ward phase shift. This method will work with applications which
respect the database size reported by gd_nframes(3) resulting in
these applications effectively ignoring all frames past the
frame containing the maximally forward-shifted PHASE field's
end-of-field marker.
MPLEX: Reading an MPLEX field typically requires GetData to read data
before the range returned in order to determine the value of the
first sample returned. This can become expensive if the encod‐
ing of the underlying RAW data does not support seeking back‐
wards (which is true of most compression encodings). How much
preceding data GetData searches for the initial value of the re‐
turned data can be adjusted, or the lookback disabled complete‐
ly, using gd_mplex_lookback(3). If the initial value of the
field is not found in the data searched, GetData will fill the
returned vector, up to the next available sample of the mulit‐
plexed field, with zero for integer return types, or
IEEE-754-conforming NaN (not-a-number) for floating point return
types, as it does when providing data before the beginning-of-
field.
GetData caches the value of the last sample from every MPLEX it
reads so that a subsequent read of the field starting from the
following sample (either through an explicit starting sample
given by the caller or else implicitly using GD_HERE) will not
need to scan the field backwards. This cache is invalidated if
a different return type is used, or if an intervening operation
moves the field's I/O pointer.
WINDOW:
The samples of a WINDOW for which the field conditional is false
will be filled with either zero for integer return types, or
IEEE-754-conforming NaN (not-a-number) for floating point return
types.
RETURN VALUE
In all cases, gd_getdata() returns the number of samples (not bytes)
successfully read from the database. If the end-of-field is encoun‐
tered before the requested number of samples have been read, a short
count will result. The library does not consider this an error. Re‐
quests for data before the beginning-of-field marker, which may have
been shifted from frame zero by the presence of a FRAMEOFFSET direc‐
tive, will result in the the data being padded at the front by NaN or
zero depending on whether the return type is of floating point or inte‐
gral type.
If an error has occurred, zero is returned and the dirfile error will
be set to a non-zero value. Possible error values are:
GD_E_ALLOC
The library was unable to allocate memory.
GD_E_BAD_CODE
The field specified by field_code, or one of the fields it uses
for input, was not found in the database.
GD_E_BAD_DIRFILE
An invalid dirfile was supplied.
GD_E_BAD_REPR
The representation suffix specified in field_code, or in one of
the field codes it uses for input, was invalid.
GD_E_BAD_SCALAR
A scalar field used in the definition of the field was not
found, or was not of scalar type.
GD_E_BAD_TYPE
An invalid return_type was specified.
GD_E_DIMENSION
The supplied field_code referred to a CONST, CARRAY, or STRING
field. The caller should use gd_get_constant(3), gd_get_car‐
ray(3), or gd_get_string(3) instead. Or, a scalar field was
found where a vector field was expected in the definition of
field_code or one of its inputs.
GD_E_DOMAIN
An immediate read was attempted using GD_HERE, but the I/O
pointer of the field was not well defined because two or more
of the field's inputs did not agree as to the location of the
I/O pointer.
GD_E_INTERNAL_ERROR
An internal error occurred in the library while trying to per‐
form the task. This indicates a bug in the library. Please
report the incident to the maintainer.
GD_E_OPEN_LINFILE
An error occurred while trying to read a LINTERP table from
disk.
GD_E_RAW_IO
An error occurred while trying to open or read from a file on
disk containing a raw field.
GD_E_RECURSE_LEVEL
Too many levels of recursion were encountered while trying to
resolve field_code. This usually indicates a circular depen‐
dency in field specification in the dirfile.
GD_E_UNKNOWN_ENCODING
The encoding scheme of a RAW field could not be determined.
This may also indicate that the binary file associated with the
RAW field could not be found.
GD_E_UNSUPPORTED
Reading from dirfiles with the encoding scheme of the specified
dirfile is not supported by the library. See dirfile-encod‐
ing(5) for details on dirfile encoding schemes.
The dirfile error may be retrieved by calling gd_error(3). A descrip‐
tive error string for the last error encountered can be obtained from a
call to gd_error_string(3).
NOTES
To save memory, gd_getdata() uses the memory pointed to by data_out as
scratch space while computing derived fields. As a result, if an error
is encountered during the computation, the contents of this memory buf‐
fer are unspecified, and may have been modified by this call, even
though gd_getdata() will report zero samples returned on error.
Reading slim-compressed data (see defile-encoding(5)), may cause unex‐
pected memory usage. This is because slimlib internally caches open
decompressed files as they are read, and getdata doesn't close data
files between gd_getdata() calls for efficiency's sake. Memory used by
this internal slimlib buffer can be reclaimed by calling
df_raw_close(3) on fields when finished reading them.
SEE ALSOdirfile(5), dirfile-encoding(5), gd_get_constant(3), gd_get_string(3),
gd_error(3), gd_error_string(3), gd_mplex_lookback(3), gd_nframes(3),
gd_open(3), gd_raw_close(3), gd_seek(3), gd_spf(3), gd_putdata(3),
GD_SIZE(3)Version 0.8.3 26 January 2013 gd_getdata(3)
