bin/109478: [libc] [patch] adopt reentrant syslog functions from OpenBSD

[Jilles Tjoelker]

The following reply was made to PR bin/109478; it has been noted by GNATS.

From: Jilles Tjoelker <jilles at stack.nl>
To: bug-followup at FreeBSD.org, skreuzer at f2o.org
Cc:  
Subject: Re: bin/109478: [libc] [patch] adopt reentrant syslog functions from
 OpenBSD
Date: Sun, 6 Apr 2014 21:32:34 +0200

 In FreeBSD PR bin/109478, you wrote:
 > The patch essentially takes OpenBSD's reentrant syslog functions
 > (openlog_r, closelog_r, syslog_r and vsyslog_r) and makes them
 > available in FreeBSD. Hopefully this will make building of packages
 > such as spamd under FreeBSD easier since the source shouldn't require
 > modifications.
 
 There may be some point in syslog functions without global data, but I
 think OpenBSD's API exposes way too much information about the
 implementation and is therefore bad for ABI stability and encapsulation.
 
 Specifically, this kind of struct seems bad (in the header file):
 > +/* Used by reentrant functions */
 > +
 > +struct syslog_data {
 > +        int     log_file;
 > +        int     connected;
 > +        int     opened;
 > +        int     log_stat;
 > +        const char      *log_tag;
 > +        int     log_fac;
 > +        int     log_mask;
 > +};
 > +
 > +#define SYSLOG_DATA_INIT {-1, 0, 0, 0, (const char *)0, LOG_USER, 0xff}
 
 A better way would be for openlog_r() to allocate something and
 closelog_r() to free it again.
 
 I don't really like the word "reentrant"; I prefer terms like
 "thread-safe" and "async-signal safe" with clear definitions. It seems
 that async-signal safe is meant here, since our syslog implementation is
 thread-safe by locking.
 
 -- 
 Jilles Tjoelker