gd_put_carray_slice(3)
π gd_put_carray_slice(3) β GETDATA π
okay bestie, so you know how we're out here living in a dirfile(5) database and you just want to write some data into a CARRAY or a CONST? yeah. that's this whole page. it lives in the GETDATA manual and it's literally the trio you need: gd_put_carray, gd_put_carray_slice, and gd_put_constant β all three write CONST or CARRAY data to a dirfile database. no cap. β¨
π¦ SYNOPSIS π¦
#include <getdata.h>
int gd_put_carray_slice(DIRFILE *dirfile, const char *field_code,
unsigned int start, size_t len, gd_type_t data_type, const void
*data_in);
int gd_put_carray(DIRFILE *dirfile, const char *field_code, gd_type_t
data_type, const void *data_in);
int gd_put_constant(DIRFILE *dirfile, const char *field_code, gd_type_t
data_type, const void *data_in);
πΈ DESCRIPTION πΈ
So gd_put_carray_slice() writes data into a dirfile(5) database (the one you pass as dirfile), straight into the CARRAY scalar array named by field_code. the data gets converted from whatever type you say in data_type, and it's read from your user-supplied buffer data_in. where does it land? the first element it writes to is given by start, and the number of elements it stores is len. iconic. π
gd_put_carray() is the same vibe, except it writes the whole scalar array β exactly as if you'd called gd_put_carray_slice() with start equal to zero and len equal to whatever gd_array_len(3) hands back. and gd_put_constant()? that one is equivalent to calling gd_put_carray_slice() with start equal to zero and len equal to one. cute, tiny, one element. π
π¨ none of these interfaces can write to field representations. nope. not happening. periodt.
The data_in argument must point to a valid memory location holding all the data you want written. and if you're curious how many elements gd_put_carray() is gonna store, call gd_array_len(3) and it'll tell you. now here's the thing β unlike gd_putdata(3), writing data past the end of the field is not permitted. sorry bestie, no overflow shenanigans. if you wanna add data to a CARRAY, first increase its length by calling gd_alter_carray(3), or another equivalent function. glow up the field before you fill it. π
π data_type, the vibe check π
data_type should be one of these symbols, and it tells everyone what type the data pointed to by data_in actually is:
GD_UINT8β unsigned 8-bit integerGD_INT8β signed (two's complement) 8-bit integerGD_UINT16β unsigned 16-bit integerGD_INT16β signed (two's complement) 16-bit integerGD_UINT32β unsigned 32-bit integerGD_INT32β signed (two's complement) 32-bit integerGD_UINT64β unsigned 64-bit integerGD_INT64β signed (two's complement) 64-bit integerGD_FLOAT32β IEEE-754 standard 32-bit single precision floating point numberGD_FLOAT64β IEEE-754 standard 64-bit double precision floating point numberGD_COMPLEX64β C99-conformant 64-bit single precision complex numberGD_COMPLEX128β C99-conformant 128-bit double precision complex number
and here's the slay part: the type of the input data does not need to match the storage type of the field. type conversion will be performed as necessary to return the requested type. it just works. π§
the dirfile argument must point to a valid DIRFILE object that was previously created by a call to gd_open(3). don't be out here passing random garbage, okay? π
β¨ RETURN VALUE β¨
on success, gd_put_carray(), gd_put_carray_slice() and gd_put_constant() all return zero. on error, they return a negative-valued error code. 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 byfield_codewas not found in the database.GD_E_BAD_DIRFILEβ the supplied dirfile was invalid.GD_E_BAD_FIELD_TYPEβ the suppliedfield_codewas not aCONSTnor aCARRAY.GD_E_BAD_TYPEβ an invaliddata_typewas specified.GD_E_BOUNDSβ a request for data beyond the end of the field was made.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_PROTECTEDβ the fragment containing the constant was protected from change. π
the error code is also stored in the DIRFILE object, and you can grab it after this function returns by calling gd_error(3). want a nice descriptive string for whatever went wrong? call gd_error_string(3). π«Ά
π HISTORY π
- the
put_constant()function appeared in GetData-0.4.0. - in GetData-0.7.0, this function was renamed to
gd_put_constant(). the functionsgd_put_carray()andgd_put_carray_slice()functions also appeared in this release. - in GetData-0.10.0, the error return from this function changed from
-1to a negative-valued error code.
π SEE ALSO π
dirfile(5), gd_array_len(3), gd_carrays(3), gd_error(3), gd_error_string(3), gd_get_carray_slice(3), gd_open(3), gd_put_constant(3)
and that's the whole page, bestie!! π this was Version 0.10.0, dated 25 December 2016 β yes, a literal Christmas gift from the GETDATA girlies. go write some CARRAY data. you got this. mwah. πβ¨
π¦ where this page comes from
- debian bookworm: libgetdata-doc 0.11.0-6
- debian trixie: libgetdata-doc 0.11.0-15
- fedora 43: getdata-devel 0.11.0-13.fc43 Β· GPL-2.0-or-later
- fedora 43: getdata-devel 0.11.0-13.fc43 Β· GPL-2.0-or-later
- fedora 44: getdata-devel 0.11.0-14.fc44 Β· GPL-2.0-or-later
- fedora 44: getdata-devel 0.11.0-14.fc44 Β· GPL-2.0-or-later
- nixos 26.05: getdata 0.11.0
- nixpkgs unstable: getdata 0.11.0
- ubuntu jammy: libgetdata-doc 0.11.0-3ubuntu1
- ubuntu noble: libgetdata-doc 0.11.0-13
- ubuntu questing: libgetdata-doc 0.11.0-15
- ubuntu resolute: libgetdata-doc 0.11.0-17build1
- ubuntu stonking: libgetdata-doc 0.11.0-17build2
- Copyright (C) 2016 D. V. Wiebe
- Copyright (C) 2010, 2011, 2012, 2016 D. V. Wiebe
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms