trusty (3) gd_native_type.3.gz

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

NAME

       gd_native_type — returns the native data type of a field in a dirfile

SYNOPSIS

       #include <getdata.h>

       gd_type_t gd_native_type(DIRFILE *dirfile, const char *field_code);

DESCRIPTION

       The  gd_native_type()  function queries a dirfile(5) database specified by dirfile and returns the native
       data type of the field field_code, which may contain a representation suffix.

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

       The native data type of a field of a given entry type is calculated as:

       BIT or INDEX Entry:
              GD_UINT64;

       CONST or CARRAY Entry:
              the data type of the field;

       LINCOM or POLYNOM Entry:
              if any of the scalar parameters is complex valued, or if the native data type of any of the  input
              fields is complex valued: GD_COMPLEX128, otherwise: GD_FLOAT64;

       LINTERP Entry:
              if the look-up table is complex valued: GD_COMPLEX128, otherwise: GD_FLOAT64;

       MULTIPLY or DIVIDE Entry:
              if either input field is complex valued: GD_COMPLEX128, otherwise: GD_FLOAT64;

       PHASE Entry:
              the native data type of the input field;

       RAW Entry:
              the data type of the raw data on disk;

       RECIP Entry:
              if  the  dividend  or  the  native  data type of the input field is complex valued: GD_COMPLEX128,
              otherwise: GD_FLOAT64;

       SBIT Entry:
              GD_INT64;

       STRING Entry:
              GD_NULL.

       Furthermore, if the supplied field_code contains a representation suffix, and the native data type of the
       field is complex valued, the native type returned will be the corresponding real valued type.

RETURN VALUE

       Upon  successful  completion,  gd_native_type() returns the native data type of the field code specified.
       This will be one of the symbols:

              GD_NULL, GD_UINT8, GD_INT8, GD_UINT16, GD_INT16, GD_UINT32,
              GD_INT32, GD_FLOAT32, GD_FLOAT64, GD_COMPLEX64, GD_COMPLEX128.

       The  meanings  of  these  symbols  are  explained in the gd_getdata(3) manual page.  On error, it returns
       GD_UNKNOWN and sets the dirfile error to a non-zero error value.  Possible error values are:

       GD_E_BAD_CODE
               The field specified by field_code or one of the fields it uses as input  was  not  found  in  the
               database.

       GD_E_BAD_DIRFILE
               The supplied dirfile was invalid.

       GD_E_BAD_REPR
               The  representation  suffix  specified  in  field_code,  or  in  one of its input fields, was not
               recognised.

       GD_E_BAD_SCALAR
               A non-literal scalar used in the definition of the field or one of its inputs was not  found,  or
               was not a CONST or CARRAY field.

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

       GD_E_OPEN_LINFILE
               An error occurred while trying to read a LINTERP table from disk.

       GD_E_RECURSE_LEVEL
               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 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).

SEE ALSO

       dirfile(5), gd_open(3), gd_getdata(3), gd_error(3), gd_error_string(3)