gd_nframes(3)
π gd_nframes β the GETDATA manual, but make it make sense π
okay bestie, buckle up, we're reading a GETDATA manpage together and it's actually so good.
β¨ NAME β¨
gd_nframes β report the size of a Dirfile π¦
πΈ SYNOPSIS πΈ
#include <getdata.h>
off_t gd_nframes(DIRFILE *dirfile);
π DESCRIPTION π
So gd_nframes() looks at a dirfile(5) database β the one you point at with dirfile β and hands you back the number of frames in that database. Slay.
But here's the tea: different fields can totally have different numbers of frames, so the Dirfile Standards (peep dirfile(5)) had to pick a winner. The number of frames in the database is defined to be equal to the number of frames in the reference field, which is the one set by the /REFERENCE directive (that's in dirfile-format(5)). And if no reference field is defined? Then it's whatever the first raw field in the format specification says. periodt.
If literally no vector fields are defined in the database, gd_nframes() returns zero and still succeeds. no drama π
Also, the dirfile argument has to point to a valid DIRFILE object that you already made by calling gd_open(3). Like, it has to be real. Don't be passing it nonsense π
π₯ RETURN VALUE π₯
If everything goes off without a hitch, gd_nframes() returns the number of frames in the dirfile β and it is never negative, iconic. On error though? It returns a negative-valued error code. Here's the whole lineup:
GD_E_ALLOCβ the library couldn't allocate memory. it's giving broke πGD_E_BAD_DIRFILEβ the dirfile you supplied was invalid.GD_E_IOβ an I/O error happened while figuring out the number of samples in the data file tied to the reference field.GD_E_UNKNOWN_ENCODINGβ couldn't determine how many samples the reference field has, because the encoding used to store that reference field's data file was just... not understood. mystery vibe πGD_E_UNSUPPORTEDβ GetData straight up does not support determining the number of samples for the encoding of the data file associated with the reference field.
The error code also gets stashed inside the DIRFILE object, so after this function returns you can go grab it with gd_error(3). And if you want a whole descriptive error string? That's gd_error_string(3), bestie π«Ά
π HISTORY π
- The
get_nframes()function appeared inGetData-0.3.0. - In
GeData-0.7.0, this function was renamed togd_nframes(). (yes it saysGeData, that's literally how it's printed, we don't ask questions π)
π SEE ALSO π
dirfile(5), dirfile-encoding(5), gd_open(3), gd_bof(3), gd_eof(3), gd_error(3), gd_error_string(3)
and that's the whole page, babes. this one's from Version 0.10.0, dated 25 December 2016 β a little vintage, a little festive, still serving. go read your dirfiles, 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) 2008, 2010, 2011, 2014, 2016 D. V. Wiebe
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms