TT_MESSAGE_IARG_ADD(3)
π tt_message_iarg_add β the "add an int argument to a message" girlie π
okay so real talk, bestie: this one lives in the library call section of the manual (that's literally the header up top, tt_message_iarg_add(library call), twice, like a little matched set π). she's a C library function, she adds integers to messages, and she's honestly so straightforward once you get the vibe. let's go β¨
πΈ SYNOPSIS πΈ
like, the whole aesthetic in one block:
#include <Tt/tt_c.h>
Tt_status tt_message_iarg_add(
Tt_message m,
Tt_mode n,
const char *vtype,
int value);
four args, one status back, no drama. periodt π
π¦ DESCRIPTION π¦
so tt_message_iarg_add does exactly what it says on the tin: it adds a new argument to a message object and sets that argument's value to a given integer. no cap, that's the whole job π«Ά
β οΈ okay key thing, listen up: add all arguments before the message is sent. like, get your args in early, bestie. if you wanna change an existing argument's value later, the application must use only the modesTT_OUTorTT_INOUT. that's the rule, i don't make 'em π
π also, adding arguments when replying to a message produces undefined results. like, undefined. not "kinda weird", not "a little buggy" β undefined. don't do it, it's giving chaos π
the arguments, one by one π§
mβ the opaque handle for the message involved in this operation. she's opaque, she's a handle, she's the message in question β¨nβ specifies who (sender, handler, observers) writes and reads a message argument. aka the mode. modes below πvtypeβ describes the type of argument data being added πvalueβ the value to be added. it's an int. it's the whole point π
the modes π
these are the Tt_mode values that are defined, and honestly? each one has main character energy in its own way:
TT_INβ the argument is written by the sender and read by the handler and any observers. so: sender writes, handler + observers read πTT_OUTβ the argument is written by the handler and read by the sender and any reply observers. flip it: handler writes, sender + reply observers read π₯TT_INOUTβ the argument is written by the sender and the handler and read by all. everyone's involved, it's a group chat π¬
β RETURN VALUE β
upon successful completion, tt_message_iarg_add returns the status of the operation as one of these Tt_status values:
TT_OKβ the operation completed successfully. slay, we love a clean return πTT_ERR_MODEβ the specifiedTt_modeis invalid. you gave her a mode she doesn't recognize, bestie πTT_ERR_NOMPβ thettsession(1)process is not running and the ToolTalk service cannot restart it. the session said "not me being gone" πTT_ERR_POINTERβ the pointer passed does not point to an object of the correct type for this operation. wrong object, wrong vibe, vibe check failed π
π SEE ALSO π
go read these next, i'm obsessed with cross-references actually:
that's the whole squad π«Ά
okay signing off π this cutie is tt_message_iarg_add(library call) β that's the page name and the section, matched set, no version stamp or date printed on this one, so that's all we've got and honestly it's enough π stay hydrated, add ur args before sending, and never add args while replying. mwah πΈβ¨
π¦ where this page comes from
- nixos 26.05: cde 2.5.3
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms