gd_linterp_tablename(3)

gd_linterp_tablename 💖

okay bestie so this is a page from the GETDATA manual, section 3 (that's the library-functions girlies). It's called gd_linterp_tablename and it's here to retrieve the pathname of a look-up table in a Dirfile. Yes, a whole function for that. She's specific. She's iconic. Let's go 🎀

✨ NAME ✨

gd_linterp_tablename — bestie, she retrieves the pathname of a look-up table in a Dirfile. That's the whole job. She does one thing and she does it flawlessly 💅

🌸 SYNOPSIS 🌸

#include <getdata.h>

char *gd_linterp_tablename(DIRFILE *dirfile, const char *field_code);

Two arguments, one char * back. Clean. Minimal. Ate. 🔥

🦋 DESCRIPTION 🦋

So here's the tea, fr fr: gd_linterp_tablename() goes and gets you the pathname of the look-up table (LUT, for short, iykyk) that's being used by the LINTERP field you name in field_code, living inside the dirfile you handed over as dirfile.

And like — if field_code happens to contain a valid representation suffix? It gets ignored. Not a problem, not an error, just ignored. She moves on. Periodt.

Note, bestie, this one matters: this function returns a fully canonicalised, absolute path. Meanwhile the value of the table member in a gd_entry_t object (go see gd_entry(3) for that whole situation) is the path which appears in the format specification on disk, which may be a path relative to the fragment directory. So they are NOT the same thing and you cannot be out here treating them like they are. Okay? Okay 🫶

💖 RETURN VALUE 💖

On success, gd_linterp_tablename() returns the full pathname of the LUT associated with the specified field — and she returns it in a newly-allocated buffer. Brand new. Fresh out the box. 🎁

By default that buffer is allocated with malloc(3), but you can specify a different memory manager by calling gd_alloc_funcs(3) before you call this function. Timing is everything, bestie. And listen: the caller is responsible for deallocating the returned buffer. That's you. You're the caller. Free your memory, it's self-care 🧚

On error, this function returns NULL and stores a negative-valued error code in the DIRFILE object, which you can retrieve with a subsequent call to gd_error(3). Possible error codes are:

• GD_E_ALLOC — the library was unable to allocate memory. She tried, she really did 😭
• GD_E_BAD_CODE — the field specified by field_code was not found. Doesn't exist. Not in this house 🙈
• GD_E_BAD_DIRFILE — the supplied dirfile was invalid. Something's off with her 💀
• GD_E_BAD_FIELD_TYPE — the field specified by field_code was not a LINTERP field. Wrong vibe check, wrong field type, sorry 🍓

And if you want an actual descriptive error string for whatever went wrong — like, words, not just a number — call gd_error_string(3). She'll tell you what happened in full sentences 💜

⭐ HISTORY ⭐

The gd_linterp_tablename() function appeared in GetData-0.8.1. Baby's been around. Respect the elders 👑

🌈 SEE ALSO 🌈

• gd_alloc_funcs(3)
• gd_entry(3)
• gd_error(3)
• gd_error_string(3)
• dirfile(5)
• dirfile-format(5)

That's the whole page, bestie — go forth and canonicalise those paths 💅

This lil masterclass comes to you courtesy of Version 0.10.0, dated 25 December 2016, filed under gd_linterp_tablename(3) in the GETDATA manual. Merry everything, slay, bye 🎀✨