Newsgroup: it.comp.os.linux.development
Titolo: syslog %m e portabilità

Il problema risulta essere di soluzione meno semplice e/o elegante del
previsto.
Volevo scrivere 2 funzioni wrapper intorno a syslog e perror in modo
da avere la stessa interfaccia indipendentemente dal fatto che stessi
girando "normale" o daemon.
strerror non è thread safe. strerror_r richiede che mi prepari un
buffer e a questo punto mi sembra di fare un po' troppo lavoro
rispetto a quello che dovrebbe fare una libreria.
Potrei andare di diretto via <errno.h> e sys_errlist[] ma questo mi
spaventa:
Be careful when directly accessing this list because new error  values
may  not  have  been  added  to sys_errlist[].
anche se dovrebbe essere thread safe se vado solo in lettura.
Ho dato una scorsa a quello che fa eg. postfix e non ho trovato
particolare ispirazione.
Mi chiedevo se per recuperare strerror ci fossero già soluzioni
collaudate per roba multithread cercando di rimanere il più portabile
possibile.
Purtroppo come programmatore di C me la cavicchio, come conoscitore di
unix mooolto meno e mi riesca difficile indovinare dov'è il confine
tra la mia ignoranza e la mancanza di uno standard o di pratiche
"comuni" e non vorrei continuare a reinventare la ruota.
thx

 possibile.
Puoi scrivere una funzione di logging che protegga con mutex gli accessi 
agli stream nonché le chiamate a strerror(). Tutte le operazioni di 
scrittura log dovranno far riferimento a questa funzione.
Ciao
  David
-- 
<d.santinoli presso mi. flashnet. it>

 funzione.
Dolore.
Il problema mi par di capire non è tanto sul'accesso agli stream...
anche se le entry del log di un thread potrebbero essere "out of
order" rispetto a quelle di un altro thread queste cose sono "thread
safe".
perror e syslog dovrebbero essere thread safe.
E` strerror che *non* lo è. Probabilmente perchè il puntatore char*
che restituisce punta a una variabile globale (_?_).
Infatti la versione thread safe di strerror_r si fa passare un buffer
locale... solo che a questo punto mi riscrivo le glibc, e in fondo c'è
anche troppa roba da imparare ;)
Per usare strerror_r dovrei
- allocarmi la memoria del buffer a mano, non voglio sapere come
syslog e perror risolvono la faccenda di essere thread safe, ma
sicuramente lo fanno meglio di quanto lo possa fare io incluso il
problema dello overhead dell'allocazione della memoria per roba che in
fondo è già li da qualche parte (sys_errlist[]?)
- conoscere la dimensione del buffer aka lunghezza massima dei
messaggi di errore... che magari in qualche docu è scritta
Imparare vuol dire anche imparare a star lontano dai guai inutili ;)
A questo punto mi sembra più elegante usare sys_errlist[], che fatto
solo in lettura ed essendo una struttura che non *dovrebbe* essere
modificata nel tempo, dovrebbe essere thread safe.
Mi rimane da capire all'atto pratico in che cosa si concretizza
questo:
Be careful when directly accessing this list because new error values
may  not  have  been  added  to sys_errlist[].
una volta compilato un programma...???
In Linux errno.h è in include/linux + include/asm ed è una serie di
#define...
In teoria per quello che devo fare io non dovrebbero esserci problemi
ad accedere direttamente all'array via errno. Credo il problema
evidenziato dalle man pages di perror non mi riguardi.
Conferme?

 una volta compilato un programma...???
Un'interpretazione possibile è che qualche funzione potrebbe restituire 
valori di errno al di fuori del range coperto da sys_errlist[].


 sys_errlist[].
Sinceramente mi piace poco quel "some library" in "The integer errno
is set by system calls (and some library functions)".
Some quali? ;) Se sono le glibc bhe... aggiornatevi... le metterò nei
Require :P <joking>
Quindi OK visto che posso sapere qual'è l'upper bound potrei
controllare.
A prescindere mi sono accorto comunque che alcuni assuntiche avevo
fatto sono sbagliati, quindi devo ripensare a un po' di cose.
...argomento temporaneamente chiuso per pausa riflessione
thx