gd_putdata(3)

💖 NAME 💖

gd_putdata — ok so this is the one that writes data into a Dirfile database ✨ (it lives in the GETDATA manual section, bestie, section 3, the library-calls girlies 🎀)

🦋 SYNOPSIS 🦋

#include <getdata.h>

size_t gd_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);

🌸 DESCRIPTION 🌸

The gd_putdata() function writes data to a dirfile(5) database specified by dirfile for the field field_code, and heads up: field_code may not contain a representation suffix. Like, at all. It writes num_frames frames plus num_samples samples to this field, starting first_sample samples past frame first_frame. The data gets read from the user-supplied buffer data_in, and that buffer has a data type specified by data_type. And lowkey important: this interface cannot write to field representations, periodt.

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

Unless you're using GD_HERE (more on that below 👇), 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 gd_spf(3). And the number of samples which gd_putdata() attempts to write is, similarly,

num_frames * samples_per_frame + num_samples.

Ik that mixing frames and samples is possible, but the function is typically called with either num_samples and first_sample, or num_frames and first_frames, equal to zero. Pick a lane bestie 💅

Instead of explicitly specifying the origin of the write, the caller may pass the special symbol GD_HERE as first_frame. This will result in the write occurring at the current position of the I/O pointer for the field (go check gd_getdata(3) for a whole discussion of I/O pointers, it's giving lore). In this case, the value of first_sample is ignored. Bye ✌️

The data_type argument should be one of the following symbols, which indicates the type of the input 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 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 library is doing the glow-up for you, no cap ✨) The argument data_in must point to a valid memory location of containing all the data to be written.

Upon successful completion, the I/O pointer of the field will be on the sample immediately following the last sample written, if possible. On error, the position of the I/O pointer is not specified — so don't come for it, it's just vibing somewhere 💀

👑 RETURN VALUE 👑

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

On error, this function returns zero and stores a negative-valued error code in the DIRFILE object which may be retrieved by a subsequent call to gd_error(3). Possible error codes are:

• GD_E_ACCMODE — The specified dirfile was opened read-only. 🙈
• 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_FIELD_TYPE — Either the field specified by field_code, or one of the fields it uses for input, was of MULTIPLY, DIVIDE, WINDOW, INDIR, or SINDIR type, or a LINCOM with more than one input field, or a POLYNOM with quadratic or higer terms. Alternately, the caller may have attempted to write to the implicit INDEX field, which is not possible.
• GD_E_BAD_TYPE — An invalid data_type was specified.
• GD_E_DIMENSION — The field specified by field_code was not a vector field. The caller should use gd_put_carray(3), gd_put_constant(3), or gd_put_string(3) instead. Or, a scalar field was found where a vector field was expected in the definition of field_code.
• GD_E_DOMAIN — An attempt was made to write to a LINTERP field with a look-up table which was not monotonic or not purely real.
• GD_E_INTERNAL_ERROR — 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. 🐛
• GD_E_IO — An error occurred while trying to open, read from, or write to a file on disk containing a raw field or a LINTERP table.
• GD_E_LUT — A LINTERP table was malformed.
• GD_E_PROTECTED — The data of the RAW field backing field_code was protected from change by a /PROTECT directive.
• GD_E_RANGE — An attempt was made to write data either before the beginning-of-frame marker for field_code, or the raw field it depends on, or else outside the addressable Dirfile range (more than 2**63 samples beyond the start of the Dirfile).
• 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. 🌀
• GD_E_UNSUPPORTED — 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.

A descriptive error string for the error may be obtained by calling gd_error_string(3).

⭐ NOTES ⭐

When operating on a platform whose size_t is N-bytes wide, a single call of gd_putdata() will never write more than (2**(N-M) - 1) samples, where M is the size, in bytes, of the largest data type used to calculate the stored field. If a larger request is specified, less data than requested will be written, without raising an error. 😭 This limit is imposed even when data_type is GD_NULL (i.e., even when no actual I/O or calculation occurs). In all cases, the actual amount of data is returned. The math said no and she meant it 💅

🎀 HISTORY 🎀

The putdata() function appeared in GetData-0.3.0.

In GetData-0.7.0, this function was renamed to gd_getdata().

The GD_HERE symbol used for sequential writes appeared in GetData-0.8.0.

🌈 SEE ALSO 🌈

GD_SIZE(3), gd_error(3), gd_error_string(3), gd_getdata(3), gd_open(3), gd_put_carray(3), gd_put_constant(3), gd_put_sarray(3), gd_put_string(3), gd_seek(3), gd_spf(3), dirfile(5), dirfile-encoding(5)

And that's the whole page bestie!! This is Version 0.10.0, dated 25 January 2017 — an icon, a legend, and she is the moment. Go write some data 💖✨🦋