SD_BUS_MESSAGE_GET_TYPE(3)

πŸ’… SD_BUS_MESSAGE_GET_TYPE(3) πŸ’…

okay bestie, welcome to sd_bus_message_get_type β€” the manual page, part of the whole sd-bus universe, and honestly? she's a little legend. this one's all about querying bus message addressing/credentials metadata, which sounds like a lot but is literally just "hey, what kind of message is this and who's it from". you're gonna slay this, i promise 🫢


✨ SYNOPSIS ✨

#include <systemd/sd-bus.h>

int sd_bus_message_get_type(sd_bus_message *m, uint8_t *type);

sd_bus_error* sd_bus_message_get_error(sd_bus_message *m);

int sd_bus_message_get_errno(sd_bus_message *m);

sd_bus_creds* sd_bus_message_get_creds(sd_bus_message *m);

int sd_bus_message_is_signal(sd_bus_message *m, const char *interface,
                             const char *member);

int sd_bus_message_is_method_call(sd_bus_message *m,
                                  const char *interface,
                                  const char *member);

int sd_bus_message_is_method_error(sd_bus_message *m, const char *name);

like, seven whole functions in one page. she's an overachiever πŸ’…


🌸 DESCRIPTION 🌸

sd_bus_message_get_type() drops the type of a message into the output parameter type, and it'll be one of SD_BUS_MESSAGE_METHOD_CALL, SD_BUS_MESSAGE_METHOD_RETURN, SD_BUS_MESSAGE_METHOD_ERROR, or SD_BUS_MESSAGE_SIGNAL. where does that type come from? either you handed it over as a parameter when you made the message with sd_bus_message_new(3), or it got set automatically when the message was created with sd_bus_message_new_signal(3), sd_bus_message_new_method_call(3), sd_bus_message_new_method_error(3) and similar functions. autopilot, iconic ✨

sd_bus_message_get_error() hands you back the error stored in the message m, if there even is one. no error? it returns NULL. and sd_bus_message_get_errno() gives you that same error stored in the message m, but as a positive errno-style value. no error? it returns zero. ngl that's the whole diff between those two. errors get mapped to errno values according to the default mappings plus any extra error mappings you registered β€” see sd-bus-errors(3) and sd_bus_error_add_map(3) for the receipts πŸŽ€

sd_bus_message_get_creds() returns the message credentials attached to the message m, and if like, no credentials are attached to the message, it returns NULL. bestie, listen: ownership of the credentials instance is not transferred to the caller, so do not free it. it's not yours, leave it alone πŸ™ˆ

sd_bus_message_is_signal() checks if message m is a signal message. if interface is non-null, she also checks if the message has the same interface set. if member is non-null, she also checks if the message has the same member set. also peep sd_bus_message_new_signal(3). returns true when all the checks pass πŸ¦‹

sd_bus_message_is_method_call() checks if message m is a method call message. if interface is non-null, it also checks if the message has the same interface set. if member is non-null, it also checks if the message has the same member set. also see sd_bus_message_new_method_call(3). returns true when all checks pass πŸ’–

sd_bus_message_is_method_error() checks if message m is an error reply message. if name is non-null, it also checks if the message has the same error identifier set. also see sd_bus_message_new_method_error(3). returns true when all checks pass ⭐


πŸ‘‘ RETURN VALUE πŸ‘‘

on success, these functions (except sd_bus_message_get_error() and sd_bus_message_get_creds(), those two are the exceptions, don't come for me) return a non-negative integer. on failure, they return a negative errno-style error code.

and sd_bus_message_get_errno()? she always returns a non-negative integer, even on failure. main character energy, truly πŸ’€

πŸ’€ Errors

the errors you might get back mean these things:

  • -EINVAL β€” the message parameter m or an output parameter is NULL. basically "girl where is it" 😭

🧚 NOTES 🧚

so the functions described here are available as a shared library, which you can compile against and link to with the libsystemd pkg-config(1) file. standard stuff, lowkey easy 🌈

all functions listed here are thread-agnostic, and only a single thread may operate on a given object at any given time. different threads may access the same object at different times (just not at the same time, bestie, that's the whole point). multiple independent objects may be used from different threads in parallel β€” that part's fine πŸ‘‘

the code described here uses getenv(3), which is declared to be not multi-thread-safe. what that means for you: code calling the functions described here must not call setenv(3) from a parallel thread. highly recommend only doing your setenv() calls during an early phase of the program, back when no other threads have been started yet. do it early, avoid the chaos 🫢


🌟 HISTORY 🌟

sd_bus_message_get_type(), sd_bus_message_is_signal(), sd_bus_message_is_method_call(), and sd_bus_message_is_method_error() were added in version 240. a whole era.

sd_bus_message_get_error(), sd_bus_message_get_errno(), and sd_bus_message_get_creds() were added in version 246. glow-up round two ✨


πŸŽ€ SEE ALSO πŸŽ€

systemd(1), sd-bus(3), sd_bus_message_new(3), sd_bus_message_set_destination(3), sd-bus-errors(3), sd_bus_error_add_map(3)


k that's the whole page, you ate that. this one's from systemd 261.3, manual page SD_BUS_MESSAGE_GET_TYPE(3) β€” go forth and query your message metadata, bestie πŸ’œπŸ¦‹πŸ“

πŸ“¦ where this page comes from