Tcl_SignalId(3)

πŸ“¦
version 9.0.3 Β· 3 versions
, in alpine 3.23, alpine 3.24, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable

πŸ’– NAME πŸ’–

Tcl_SignalId, Tcl_SignalMsg β€” bestie, we're converting signal codes ✨

This one lives in the Tcl Library Procedures section of the manual, page Tcl_SignalId(3), so if you were looking for the group chat where signal numbers get translated into actual words? You found it. 🫢


🌸 SYNOPSIS 🌸

#include <tcl.h>

const char *
Tcl_SignalId(sig)

const char *
Tcl_SignalMsg(sig)

πŸŽ€ ARGUMENTS πŸŽ€

  • int sig (in) β€” a POSIX signal number, like SIGPIPE. That's it. That's the whole input. Give it a number, it gives you a name. Iconic behaviour tbh. πŸ’…

✨ DESCRIPTION ✨

Okay so here's the tea, bestie: Tcl_SignalId and Tcl_SignalMsg both take that signal number you handed them (sig) and hand you back a string representation of it. Same input, two whole different vibes. 🌈

  • Tcl_SignalId β€” this one is the machine-readable one. It gives you a textual identifier like "SIGPIPE". Like, the actual technical name, no fluff, built for code to read. Very "let me speak to the compiler" energy.
  • Tcl_SignalMsg β€” this one is the human-readable one. It gives you a string like "bus error". Like, the friendly version, the one you'd actually say out loud to a person. It's giving translation services for your terminal. 😭
Heads up though, fr fr: the strings that come back from these functions are statically allocated. That means the caller must not free them and must not modify them. Do not touch. Do not edit. Do not free() them. They are not yours, they are the library's, and they are staying exactly as they are. 🚫🧼

πŸ‘‘ KEYWORDS πŸ‘‘

signals, signal numbers


That's the whole page, no cap β€” straight from the Tcl 8.3 days, and this manual page is still going by Tcl_SignalId(3). Go forth and convert those signals, queen. πŸ¦‹πŸ’œ

πŸ“¦ where this page comes from