Nei titoli e nei testi troverete qualche rimando cinematografico (ebbene si, sono un cinefilo). Se non vi interessano fate finta di non vederli, già che non sono fondamentali per la comprensione dei post...

Di questo blog ho mandato avanti, fino a Settembre 2018, anche una versione in Spagnolo. Potete trovarla su El arte de la programación en C. Buona lettura.

lunedì 24 novembre 2025

Il Logger
come scrivere un logger in C - pt.2

Michael Corleone: Io non penso affatto di dover eliminare tutti Tom, solo i miei nemici, tutto qui.

(...una premessa: questo post potrebbe sembrare un remake di un mio vecchio post. In realtà tratta, incidentalmente, lo stesso argomento, ma amplia notevolmente il discorso è affronta ben altri temi. Leggete e mi direte...)

Visto che nell'ultimo articolo avevo introdotto l'argomento logger usando Il Padrino del Maestro Francis Ford Coppola, per questa seconda parte mi è sembrato il caso di usare un'altro suo capolavoro, Il Padrino - Parte II. E, come già detto nell'altro articolo,"...il logger lavora dietro le quinte e registra tutto, non gli sfugge niente...", proprio come il protagonista del film... Come avrete già capito, in questo articolo parleremo ancora di logger e di syslog!

...ti spiego: senza il logger non vai da nessuna parte...

E veniamo al dunque: ci eravamo lasciati con una pseudo-specifica di un logger che usa il syslog (system logger) , con tanto di anticipazione dei log ottenuti. Adesso è venuto il momento della implementazione vera e propria, e spero che qualcuno abbia raccolto il mio invito a scriverne una versione propria aspettando questo nuovo post (non potete certo dire che non vi ho lasciato il tempo...); tra l'altro, come vedremo tra poco, l'implementazione è veramente semplicissima. Nello scorso post avevamo visto l’header file (mylog.h) e un esempio di uso (main.c), e quindi, con grande originalità, il file di implementazione lo chiameremo mylog.c. E vediamolo, vai col codice!

#define _GNU_SOURCE
#include <stdio.h>
#include <stdarg.h>
#include <syslog.h>
#include <unistd.h>
#include "mylog.h"

#define LOGGER_MAXSIZE 2048 // max size di un messaggio di log (in bytes)

// openLog - apre il log sul syslog
void openLog(int level)
{
// set del log level del syslog
setlogmask(LOG_UPTO(level));

// aprp il log sul syslog
openlog(NULL, LOG_PID | LOG_NDELAY | LOG_PERROR, LOG_USER);
}

// closeLog - chiude il log sul syslog
void closeLog()
{
// chiudo il syslog e mostro il risultato su stderr
closelog();
fprintf(stderr, "%s: syslog chiuso\n", __func__);
fflush(stderr);
}

// traceLog - scrive un messaggio di log sul syslog
void traceLog(int level, const char *format, ...)
{
// inizializzo la lista variabile di argomenti va_list usando la stringa format
va_list arglist;
va_start(arglist, format);

// costruisco una nuova stringa di format aggiungendo il TID a format
char my_format[LOGGER_MAXSIZE];
snprintf(my_format, sizeof(my_format), "[%d]: %s", gettid(), format);

// chiamo vsyslog(3) (syslog(3) con va_list) con la stringa di format costruita
vsyslog(level, my_format, arglist);

// chiudo la va_list
va_end(arglist);
}

Non starò a descrivere gli include-files, che sono, né più né meno, solo quelli che servono. Sembra lapalissiano, ma è normale trovare sorgenti con molti più include del necessario: non fanno danni ma complicano l'interpretazione visiva del codice. Ricordatevi di mettere solo quelli che servono.

Dopodiché passiamo alla vera e propria implementazione, e incontriamo le prime due delle tre funzioni che compongono il nostro logger, e cioè: openLog() e closeLog(). Sono molto semplici: la prima setta il livello di log con il valore passato come argomento (level) e poi esegue la vera e propria apertura usando l'apposita funzione della famiglia syslog(3), e cioè openlog(3); la seconda si limita, semplicemente, a chiudere il logger usando l'apposita funzione closelog(3).

Notare che openlog(3) accetta una notevole serie di opzioni (col suo secondo argomento, option), che si possono mettere in OR per definire il funzionamento richiesto. Vi rimando al manuale di syslog(3) per la lista delle opzioni disponibili, comunque vi faccio notare che nell'esempio ho usato quelle più comuni, e cioè:

  • LOG_PID: include il PID (Process ID) del chiamante in ogni messaggio di log.
  • LOG_NDELAY: apre immediatamente la connessione (altrimenti la connessione viene aperta quando viene registrato il primo messaggio di log). Si parla di connessione perché per scrivere sul syslog si usa un socket, come già visto qui.
  • LOG_PERROR: scrive il messaggio di log anche su stderr.

E adesso veniamo al cuore del nostro logger, la funzione traceLog(), che è quella che si occupa di scrivere le tracce di log nel file del syslog: per farlo usa funzioni della famiglia stdarg(3) (che gestisce le "variable argument lists"), visto che la nostra traceLog() deve usare una sintassi printf-like, quindi con stringa di formattazione e argomenti variabili. L'operazione è divisa in tre parti come indicato nel codice stra-commentato):

  1. Inizializzo la lista variabile di argomenti va_list  usando la stringa format.
  2. Costruisco una nuova stringa di format aggiungendo il TID (Thread ID).
  3. Chiamo vsyslog(3) (che sarebbe una syslog(3) con va_list) con la stringa di format costruita precedentemente.
  4. Chiudo la va_list.

Faccio un appunto sul punto 2 qui sopra: è la fase di personalizzazione del messaggio di log, dove si possono aggiungere (a piacere) dettagli che si sommano a quelli standard presenti di default. In questo esempio ho aggiunto il TID (Thread ID), che in una applicazione multithread può essere utile a tracciare adeguatamente quello che è successo durante l'uso.

Cosa ve ne sembra dell'implementazione? Non è male, no? Ed è semplicissima! Provate a copiare e a compilare il tutto (con il main() del precedente articolo), vi assicuro che funziona bene (come tutti gli esempi che propongo nel blog, eh!).

E con questo credo che possiamo considerare concluso l'argomento logger su syslog. Il codice presentato in questi due articoli è molto simile a quello che uso spesso in produzione, quindi si tratta di un esempio pratico di uso reale, eh! Fatene buon uso!

Ciao e al prossimo post!

giovedì 30 ottobre 2025

Il Logger
come scrivere un logger in C - pt.1

Don Vito Corleone: Gli farò un'offerta che non potrà rifiutare.

(...una premessa: questo post potrebbe sembrare un remake di un mio vecchio post. In realtà tratta, incidentalmente, lo stesso argomento, ma amplia notevolmente il discorso è affronta ben altri temi. Leggete e mi direte...)

Il Logger è un po' come Il Padrino, il protagonista di uno dei capolavori del Maestro Francis Ford Coppola: lui lavora dietro le quinte e registra tutto, non gli sfugge niente. E quando è necessario bisogna ricorrere a lui per risolvere svariati problemi (uff... e, ahimè, in questo caso la finzione cinematografica è molto vicina a cose che succedono nella realtà...). Come avrete già capito, in questo articolo parleremo di logger e di syslog!

...gli farò un logger che non potrà rifiutare...

Quando si scrive Software bisogna sempre cercare di essere professionali, qualunque sia l'uso del Software che stiamo scrivendo. Ad esempio non ci si può dimenticare di prevedere un buon sistema di log (un logger, per gli amici). Ci sono, poi, alcuni professionisti della programmazione che non sanno neanche cos'è un buon sistema di log... ma questa è un altra storia...

Per aggiungere un logger al nostro Software possiamo aiutarci col sistema operativo, ad esempio su UNIX e Linux abbiamo il syslog (system logger) che è molto flessibile e ci semplifica la vita. Nel caso di non potere (o non volere) usare i mezzi forniti dal sistema si può pensare di scriversi un proprio sistema di log (l'ho fatto alcune volte, ma erano esigenze particolari di progetto), ma il syslog dei sistemi POSIX è così pratico e flessibile che non si può rinunciare a usarlo. Comunque in un mio vecchio articolo potete trovare un buon esempio di "logger indipendente".

Sia perché non voglio fare un post troppo lungo (diventerebbe noioso), sia per seguire una specie di approccio specifica+implementazione (adattato a un blog di programmazione), ho diviso il post in due puntate: nella prima descriverò, a mo' di specifica funzionale, l'header file (mylog.h) e un esempio di uso (main.c). Nella seconda puntata descriverò la vera e propria implementazione.

Vediamo l'header file, mylog.h:

// prototipi globali
void openLog(int level);
void closeLog();
void traceLog(int level, const char* format, ...) __attribute__ ((format(printf, 2, 3)));
// NOTA: il __attribute__ serve a mostrare warning (a compile-time) sui parametri di traceLog()

Semplicissimo e auto-esplicativo, no? Il nostro prodotto è formato da tre funzioni canoniche (apri, chiudi, traccia). L'argomento level di openLog() è il livello di log richiesto, e corrisponde a uno degli otto livelli di gravità previsti dal syslog standard (dal più grave al meno grave: LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE, LOG_INFO, LOG_DEBUG). Quasi inutile spiegare che, settando un livello, nel file del syslog appariranno tutti i messaggi di uguale o maggiore gravità del livello selezionato.

Merita invece un po' di attenzione il prototipo della funzione traceLog(): è la funzione per scrivere i messaggi nel syslog, ed è una funzione printf-like, quindi con argomenti variabili che si formattano usando l'argomento format. Notare che ho aggiunto, dopo il prototipo, questo attributo:

__attribute__ ((format(printf, 2, 3)));

A cosa serve? Come ben saprete le funzioni della famiglia printf(3) sono conosciute dal compilatore, e quindi se sbagliamo a formattare un argomento (ad esempio se assegniamo un int a un campo %s  che si aspetta una stringa) il compilatore emette un warning  che ci aiuta a correggere il problema a compile-time (che, nell'esempio appena descritto, si trasformerebbe in un problemone a run-time).

Il fatto è che la nostra funzione traceLog() è sconosciuta al compilatore, e quindi per generare eventuali warning bisogna presentargliela: e questo lo possiamo fare con l'apposito attributo format(archetype, string-index, first-to-check) che, nel nostro caso, specifica che è una printf (archetype=printf) con la stringa come secondo argomento (string-index=2) e gli argomenti variabili dalla terza posizione (first-to-check=3). Sfortunatamente tutto questo è valido solo per GCC, ma visto che è il compilatore più usato su UNIX e Linux mi sembra una informazione utilissima, no?

Vediamo ora il main dell'esempio d'uso: vai col codice!

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <syslog.h>
#include "mylog.h"

// prototipi locali
static int getLoglevel(const char* level);

// main - funzione main
int main(int argc, char* argv[])
{
// test del numero di argomenti
if (argc != 2) {
// errore: numero errato di argomenti
fprintf(stderr, "%s: numero errato di argomenti\n", argv[0]);
fprintf(stderr, "uso: %s loglevel (e.g.: %s debug)\n", argv[0], argv[0]);
return EXIT_FAILURE;
}

// test del argomento loglevel
int loglevel;
if ((loglevel = getLoglevel(argv[1])) == -1) {
// errore: livello di log sconosciuto
fprintf(stderr, "%s: livello di log sconosciuto (%s)\n", argv[0], argv[1]);
fprintf(stderr, "uso: %s loglevel (e.g.: %s debug)\n", argv[0], argv[0]);
return EXIT_FAILURE;
}

// apro il log su syslog
openLog(loglevel);

// eseguo un test di traceLog()
traceLog(LOG_EMERG, "log di tipo LOG_EMERG (il livello impostato è %s)", argv[1]);
traceLog(LOG_ALERT, "log di tipo LOG_ALERT (il livello impostato è %s)", argv[1]);
traceLog(LOG_CRIT, "log di tipo LOG_CRIT (il livello impostato è %s)", argv[1]);
traceLog(LOG_ERR, "log di tipo LOG_ERR (il livello impostato è %s)", argv[1]);
traceLog(LOG_WARNING, "log di tipo LOG_WARNING (il livello impostato è %s)", argv[1]);
traceLog(LOG_NOTICE, "log di tipo LOG_NOTICE (il livello impostato è %s)", argv[1]);
traceLog(LOG_INFO, "log di tipo LOG_INFO (il livello impostato è %s)", argv[1]);
traceLog(LOG_DEBUG, "log di tipo LOG_DEBUG (il livello impostato è %s)", argv[1]);

// chiudo il log
closeLog();

// exit Ok
return EXIT_SUCCESS;
}

// getLoglevel - ritorna il loglevel come numero definito in syslog.h
static int getLoglevel(
const char* level) // la stringa corrispondente al numero definito
{
if (!strcmp(level, "emerg")) // sistema non usabile
return LOG_EMERG;
else if (!strcmp(level, "alert")) // necessità di azione immediata
return LOG_ALERT;
else if (!strcmp(level, "crit")) // condizione critica
return LOG_CRIT;
else if (!strcmp(level, "err")) // condizione di errore
return LOG_ERR;
else if (!strcmp(level, "warning")) // condizione di warning
return LOG_WARNING;
else if (!strcmp(level, "notice")) // condizione normale, ma significativa
return LOG_NOTICE;
else if (!strcmp(level, "info")) // messaggio di informazione
return LOG_INFO;
else if (!strcmp(level, "debug")) // messaggio di debug
return LOG_DEBUG;

// livello di log sconosciuto
return -1;
}

Semplice, no? Eseguo un test degli argomenti e, se vanno bene, apro il logger, lo uso, lo chiudo ed esco. Nel caso di una errata linea di comando mostro l'errore e un esempio di lancio corretto: "uso: ./mylog loglevel (e.g.: ./mylog debug)". Il resto del codice è, come sempre, stra-commentato, quindi non credo che ci sia altro da aggiungere.

Ma, in pratica, usando una linea di comando del tipo "./mylog err" quale sara il risultato? Nel file del syslog  verranno aggiunte le seguenti linee (delle quali spiegherò il contenuto nel prossimo articolo):

2025-10-27T19:12:48.035208+01:00 mint22 mylog[8030]: [8030]: log di tipo LOG_EMERG (il livello impostato è err)
2025-10-27T19:12:48.036163+01:00 mint22 mylog[8030]: [8030]: log di tipo LOG_ALERT (il livello impostato è err)
2025-10-27T19:12:48.036390+01:00 mint22 mylog[8030]: [8030]: log di tipo LOG_CRIT (il livello impostato è err)
2025-10-27T19:12:48.036625+01:00 mint22 mylog[8030]: [8030]: log di tipo LOG_ERR (il livello impostato è err)

Notare che, essendo il livello scelto nella linea di comando quello di LOG_ERR, non sono apparsi i messaggi di LOG_NOTICE, LOG_INFO e LOG_DEBUG. Aggiungo che le scritte di log possono apparire anche su terminale se (come vedremo nel prossimo articolo) il syslog  viene aperto con questa modalità (che è opzionale).

Per oggi abbiamo finito. I più volenterosi potranno, nell'attesa della seconda parte, scrivere una propria implementazione, e poi confrontarla con la mia, ma la mia sarà sicuramente migliore... (si allontana sghignazzando).

Ciao e al prossimo post!

venerdì 19 settembre 2025

atoi(3)? No, grazie!
come sostituire la atoi(3) in C

uomo travestito da Babbo Natale: Per la miseria! Non hanno più ritegno! Fare la multa a Babbo Natale la sera della vigilia! E alla Befana che faranno, le sequestrano la scopa?

Nell'ultimo articolo (che vi invito a rileggere) terminai con questo P.S.: "Nel prossimo articolo, anche se parlerò d'altro, vi proporrò la versione più efficiente e stringata possibile della atoi(3)...". L'idea era, in effetti di parlare d'altro ma, per la serie "battere il ferro finché è caldo", perché lasciare del tutto l'argomento atoi(3)? Solo che, invece di parlare di utili esercizi per rinfrescare le basi del C, oggi vi proporrò un nuovo capitolo della saga dei "No, grazie!" (ah: ne ho scritti altri e vi invito a leggerli o rileggerli, qui, quiqui, quiqui e qui) ). E, quindi, benvenuti a: atoi(3)? No, grazie!, dove spiegherò come e perché sostituire la atoi(3). Il film di riferimento è, ancora, il buon Mamma, ho perso l'aereo, un film Natalizio che ora è un po' fuori stagione, ma sarà perché sto già aspettando le vacanze di Natale...

...e daje con la atoi(3)...

Prima di tutto devo mantenere la promessa: ecco la versione più efficiente e stringata possibile della atoi(3) (o almeno credo che lo sia...). Vai col codice!
// myatoi - una atoi(3) molto stringata
int myatoi(const char *nptr)
{
int result = 0;
while (*nptr)
result = result * 10 + *nptr++ - '0';

return result;
}

Sono tre (3!) linee di codice più il return, credo che sia difficile farla ancora più stringata, no? Ovviamente, come detto nella premessa, questa versione minimale fa solo l'indispensabile, quindi niente controllo della coerenza dell'input, niente gestione degli errori, ecc.

E a voi come è andata? Siete riusciti a scrivere una atoi(3) decente in meno di 10 minuti?

E ora veniamo al dunque, facciamo il punto sulla atoi(3) di libreria e vediamo perché è meglio sostituirla. Il perché è ben descritto già nel manuale della funzione, nel paragrafo "BUGS":

errno is not set on error so there is no way to distinguish between 0
as an error and as the converted value. No checks for overflow or un‐
derflow are done. Only base-10 input can be converted. It is recom‐
mended to instead use the strtol() and strtoul() family of functions in
new programs.

e quindi, per riassumere, i problemi sarebbero questi:

  1. Non imposta errno  in caso di errore, quindi è impossibile sapere se un valore ritornato 0 è un errore o un vero valore 0...
  2. Derivato dal punto 1: restituisce 0 se la stringa non rappresenta un numero intero (o decimale), che è indistinguibile da una stringa di input formattata correttamente che indica lo zero.
  3. Ha un comportamento indefinito se il valore del risultato non può essere rappresentato.

Il manuale propone di usare, in alternativa, una funzione della famiglia strtol(3), che è una buona idea, anche se, devo dire, la strtol(3) non è propriamente una funzione user-friendly, non ha un uso semplice e immediato come la atoi(3), e non è esente dal problema di identificazione corretta di tutti gli errori da parte del chiamante. Comunque, se volete seguire rigidamente i consigli del manuale usate la strtol(3), che va benissimo; io, dato che ci sono, vi propongo una mia funzione alternativa che si usa (più o meno) come la atoi(3) ma che non ha nessuno dei suoi difetti (e usa internamente la strtol(3)). L'ho chiamata safeatoi(). Vai col codice!

// safeatoi - una atoi(3) senza problemi
int safeatoi(const char *nptr)
{
// set risultato di default e set errno a 0 prima di usare strtol(3)
int result = -1;
errno = 0;

// set risultato usando strtol(3)
char *endptr;
const long lresult = strtol(nptr, &endptr, 10);

// check risultato e eventualmente mostro l'errore
if (endptr == nptr) {
// errore
fprintf(stderr, "%s: non è un numero decimale\n", nptr);
} else if (*endptr != '\0') {
// errore
fprintf(stderr, "%s: un carattere extra alla fine del input: %s\n", nptr, endptr);
} else if ((lresult == LONG_MIN || lresult == LONG_MAX) && errno != 0) {
// errore
fprintf(stderr, "%s: fuori dal range del tipo long\n", nptr);
} else if (lresult > INT_MAX) {
// errore
fprintf(stderr, "%ld maggiore di INT_MAX\n", lresult);
} else if (lresult < INT_MIN) {
// errore
fprintf(stderr, "%ld minore di INT_MIN\n", lresult);
} else {
// success
result = (int)lresult;
}

return result;
}

Che ne dite? Non è male, no? Questa versione scrive (su stderr) gli (eventuali) errori di esecuzione, pertanto si può sapere se qualcosa è andata male e se il valore ottenuto è corretto o no. Notare che nei test interni è presente anche il test di overflow su long, che essendo questa una atoi(3) potrebbe sembrare superfluo, ma non lo è, perché è comunque un errore che è necessario trattare, ed è anche una buona base per la codifica di una eventuale safeatol() alternativa alla atol(3).

Questa versione "sicura" è utile ed è adatta ad essere inserita direttamente in un progetto, possibilmente redirigendo le scritte al syslog  invece che a stderr. Ma se l'obbiettivo è scrivere una vera funzione di libreria non possiamo basare il funzionamento su scritte di errore, bisogna seguire un altro approccio. E quindi? Ebbene si, sto per proporvi ben due (2! crepi l'avarizia!) versioni di una atoi(3) sicura, usabili come funzioni di libreria. La differenza tra le due versioni è che una usa una interfaccia GNU-specific, mentre l'altra ha una interfaccia XSI-compliant (ossia: POSIX). In realtà nessuna delle due realizza l'interfaccia in modo completamente canonico, ma visto che si tratta di funzioni aggiuntive esterne alla libc non si possono fare miracoli...

E cominciamo con la versione GNU-specific, che ho chiamato gsafeatoi(). Vai col codice!

// gsafeatoi - una atoi(3) senza problemi e in stile (quasi) GNU-specific
int gsafeatoi(const char *nptr, char *buf, size_t buflen)
{
// set risultato di default e set errno a 0 prima di usare strtol(3)
int result = -1;
errno = 0;

// set risultato usando strtol(3)
char *endptr;
const long lresult = strtol(nptr, &endptr, 10);

// check risultato e eventualmente mostro l'errore
if (endptr == nptr) {
// errore
if (buf)
snprintf(buf, buflen, "%s: non è un numero decimale", nptr);
} else if (*endptr != '\0') {
// errore
if (buf)
snprintf(buf, buflen, "%s: un carattere extra alla fine del input: %s", nptr, endptr);
} else if ((lresult == LONG_MIN || lresult == LONG_MAX) && errno != 0) {
// errore
if (buf)
snprintf(buf, buflen, "%s: fuori dal range del tipo long", nptr);
} else if (lresult > INT_MAX) {
// errore
if (buf)
snprintf(buf, buflen, "%ld maggiore di INT_MAX", lresult);
} else if (lresult < INT_MIN) {
// errore
if (buf)
snprintf(buf, buflen, "%ld minore di INT_MIN", lresult);
} else {
// successo
result = (int)lresult;
if (buf)
snprintf(buf, buflen, "success");
}

return result;
}

Come sempre il codice è stra-commentato quindi non credo che ci sia da dilungarsi troppo in dettagli. Grazie a questo tipo di interfaccia è possibile ricevere la stringa di errore e così verificare se il risultato è valido. Ovviamente il chiamante deve fornire un buffer (e la sua lunghezza) per permettere la scrittura del messaggio.

E adesso possiamo passare alla versione XSI-compliant, che ho chiamato psafeatoi(). Vai col codice!

// psafeatoi - una atoi(3) senza problemi e in stile (quasi) XSI-compliant (POSIX)
int psafeatoi(const char *nptr, int *result)
{
// set risultato di default e set errno a 0 prima di usare strtol(3)
*result = -1;
errno = 0;

// set risultato usando strtol(3)
char *endptr;
const long lresult = strtol(nptr, &endptr, 10);

// check risultato e eventualmente mostro l'errore
int retval;
if (endptr == nptr) {
// errore: non è un numero decimale
retval = 1;
} else if (*endptr != '\0') {
// errore: un carattere extra alla fine del input
retval = 2;
} else if ((lresult == LONG_MIN || lresult == LONG_MAX) && errno != 0) {
// errore: fuori dal range del tipo long
retval = 3;
} else if (lresult > INT_MAX) {
// errore: maggiore di INT_MAX
retval = 4;
} else if (lresult < INT_MIN) {
// errore: minore di INT_MIN
retval = 5;
} else {
// successo
*result = (int)lresult;
retval = 0;
}

return retval;
}

Come è evidente, grazie a questo tipo di interfaccia, è possibile ricevere un codice di successo (0) o di errore (1, 2, ecc.) per verificare se il risultato è valido o che tipo di errore si è verificato. In realtà la interfaccia XSI-compliant canonica dovrebbe ritornare l'errno  gestito dalla libc, ma nel nostro caso dovremo accontentarci del nostro codice user-defined che potremo, ad esempio definire in un header apposito del progetto.

Che ne dite? Spero che questo prolungamento dell'argomento atoi(3) vi sia piaciuto e, soprattutto, vi sia risultato utile. E se no, pazienza, me ne farò una ragione...

Ciao, e al prossimo post!