gd_alter_entry(3)

NAME
gd_alter_entry — modify the metadata of a Dirfile field

SYNOPSIS
#include <getdata.h>

int gd_alter_entry(DIRFILE *dirfile, const char *field_code, const gd_entry_t *entry, int recode);

DESCRIPTION
The function modifies the field specified by in the dirfile specified by to correspond to the new parameters specified by In addition to specifying a regular field, may also refer to a metafield by specifying it using its full (slashed) field code. However, should never contain a representation suffix. The form of is described in detail in the man page. The and members are ignored by this function and need not be initialised. All other members appropriate to the field type of should be initialised, except as noted below. To change the fragment index of a field, use To change the name of a field, use The only flags in the member which are honoured are GD_EN_HIDDEN, which should be set or cleared to set the hiddenness of the entry (see and GD_EN_COMPSCAL, which indicates whether scalar parameters are initialised from the complex valued or purely real member, which both are present (LINCOM, POLYNOM, RECIP). If specifies a RAW field and the argument is non-zero, the binary file associated with the field will be converted for changes in data type and samples-per-frame. In this case, the field's I/O pointer will be reset to the beginning-of-frame. If is zero, no binary file conversion will take place. If specifies a LINTERP field and the argument is non-zero, the look-up table file will be moved if specifies a different path. If a file with the new pathname already exists, it will be overwritten. If the field specified by is of type other than RAW or LINTERP, the argument is ignored. If specified a LINCOM or POLYNOM field, the value of indicates whether the purely real scalar lists (entry->a, or entry->b and entry->m) or the complex valued lists (entry->ca, or entry->cb and entry->cm) will be used. The unused counterparts need not be initialised. The member must correspond to the field type of This interface cannot be used to change the type of a given field. To do so, delete the old field first with and then create a new field of the desired type with Some entry members have special values which indicate no change should be made to the member. These special values are: any of the string members; spf, n_fields, numbits, cdividend, dividend, or array_len; bitnum or period; data_type or const_type; windop.

All elements relevant for the given field type must be initialised to one of the following values:

•   a pointer to a field code indicating a new scalar field to be used for the corresponding field parameter. If the parameter was previously a literal number, it will be replaced by the specified field code. If the parameter was previously a field code, the new field code will replace the old one. If the field code specifies a CARRAY field, the corresponding element should also be set.

•   a pointer to the empty string (""). In this case, no change is made to the field code for the corresponding field parameter: if one already existed, it is kept, otherwise the corresponding literal numerical parameter is used. If the value of the corresponding numerical member is the special value listed above indicating no change, no change is made to the field parameter at all. NB: In this case, GetData also ignores the corresponding element, even if it differs from the current value. To change a element without changing the corresponding set that element to its current value (at which point GetData operates as per the previous bullet).

•   the NULL pointer. If the corresponding field parameter was previously a field code, the field code will be deleted and a literal number used instead. In the special case when a scalar element is NULL and the corresponding numerical member contains a special value indicating no change listed above, GetData will de-reference the previous field code value and convert it into a literal number before removing the field code from the entry.

If this function is used to increase the length of a CARRAY field, the added elements will be uninitialised. Use or equivalent to initialise them.

RETURN VALUE
On success, return zero. On error, a negative-valued error code is returned. Possible error codes are: The specified dirfile was opened read-only. The library was unable to allocate memory. The field specified by was not found or a supplied field code did not contain the appropriate prefix or suffix. This error may also result from attempting to dereference a scalar field code which indicates a non-existent field. The supplied dirfile was invalid. One or more of the parameters specified in was invalid. The parameter did not correspond to the type of the field specified by or an attempt was made to modify the immutable INDEX field. This error may also result from attempting to dereference a scalar field code which does not indicate a CONST or CARRAY field. The parameter provided with a RAW entry, or the parameter provided with a CONST or CARRAY entry, was invalid. An I/O error occurred while translating the binary file associated with a modified RAW field, or an I/O error occurred while attempting to rename a LINTERP table file. The metadata of the fragment was protected from change. Or, a request to translate the binary file associated with a RAW field was attempted, but the data of the fragment was protected. The encoding scheme of the indicated format specification fragment is not known to the library. As a result, the library was unable to translate the binary file be associated with a modified RAW field. The encoding scheme of the indicated format specification fragment does not support translating the binary file associated with a modified RAW field.

The error code is also stored in the DIRFILE object and may be retrieved after this function returns by calling A descriptive error string for the error may be obtained by calling

HISTORY
The function appeared in GetData-0.5.0. In GetData-0.7.0, this function was renamed to In GetData-0.8.0, the first version supporting fragment affixes, this function would apply the destination fragment's affixes to the supplied name. In GetData-0.8.1, this changed: now assumes contains the full field name, including any necessary affixes. In GetData-0.10.0, the error return changed from -1 to a negative-valued error code. See for the history of the gd_entry_t structure.

SEE ALSO
dirfile-format(5)