Provided by: libgetdata-dev_0.7.3-6_i386 bug


       gd_getdata — retrieve data from a dirfile database


       #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);


       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
       appropriate 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.

       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
       possible, the function is typically called with either num_samples  and
       first_sample, or num_frames and first_frames, equal to zero.

       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

                         C99-conformant 64-bit single precision complex number

                         C99-conformant  128-bit  double   precision   complex

              GD_NULL    the  null type: the database is queried as usual, but
                         no data is  returned.   In  this  case,  data_out  is
                         ignored and may be NULL.

       The  return  type  of  the data need not be the same as the type of the
       data stored in the database.  Type  conversion  will  be  performed  as
       necessary  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.


       In all cases, gd_getdata() returns the number of  samples  (not  bytes)
       successfully   read   from   the  database.   If  the  end-of-field  is
       encountered before the requested number of samples have  been  read,  a
       short  count will result.  The library does not consider this an error.
       Requests for data before the beginning-of-field marker, which may  have
       been  shifted  from  frame  zero  by  the  presence  of  a  FRAMEOFFSET
       directive, 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
       integral 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:

               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.

               The supplied field_code referred to a CONST, CARRAY, or  STRING
               field.           The          caller         should         use
               gd_get_constant(3),   gd_get_carray(3),   or   gd_get_string(3)

               The representation suffix specified in field_code, or in one of
               the field codes it uses for input, was invalid.

               A scalar field used in the definition  of  the  field  was  not
               found, or was not of scalar type.

               An invalid return_type was specified.

               A scalar field was found where a vector field was expected.

               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

               An error occurred while trying to open or read from 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.

               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.

               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  gd_error(3).   A
       descriptive error string for the last error encountered can be obtained
       from a call to gd_error_string(3).


       The  PHASE  field type is poorly defined, since a forward-shifted PHASE
       field will always encounter the end-of-field marker  before  its  input
       field  does.   This  has  ramifications  when  using  gd_getdata() with
       streaming data.  The Dirfile Standards make  tacit  admission  to  this
       problem  by  indicating the results of reading a PHASE field beyond the
       beginning- or end-of-field is "implementation dependent" (see  dirfile-
       format(5)).   As with any other field, gd_getdata() will return a short
       count whenever a read from a PHASE field  encounters  the  end-of-field

       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 time lag, and then back-shifting all  data  which  should  have
       been  written  earlier.   Another  possible  work-around  is  to  write
       systematically less data to the first RAW field in  proportion  to  the
       maximal  forward  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


       dirfile(5),    dirfile-encoding(5),   gd_open(3),   gd_get_constant(3),
       gd_error(3),     gd_error_string(3),     gd_nframes(3),      gd_spf(3),
       gd_get_string(3), gd_putdata(3)