syslog: revert LOG_FAC/LOG_FACMASK changes

commit 895736d49b made these changes
along with fixing a real bug in LOG_MAKEPRI. based on further
information, they do not seem to be well-motivated or in line with
policy.

the result of LOG_FAC is not a meaningful facility value if we shift
it down like before, but apparently the way it is used by applications
is as an index into an array of facility names. moreover, all
historical systems which define it do so with the shift. as it is a
nonstandard interface, there is no justification for providing a macro
by the same name that is incompatible with historical practice.

the value of LOG_FACMASK likewise is 0x3f8 on all historical systems
checked. while only 5 bits are used for existing facility codes, the
convention seems to be that all 7 bits belong to the facility field
and theoretically could be used to expand to having more facilities.
that seems unlikely to happen, but there is no reason to make a
gratuitously incompatible change here.
This commit is contained in:
Rich Felker 2024-07-05 13:22:25 -04:00
parent 008f737ddf
commit dd1e63c363
2 changed files with 3 additions and 3 deletions

View File

@ -46,8 +46,8 @@ extern "C" {
#define LOG_LOCAL7 (23<<3)
#define LOG_NFACILITIES 24
#define LOG_FACMASK 0xf8
#define LOG_FAC(p) ((p)&LOG_FACMASK)
#define LOG_FACMASK 0x3f8
#define LOG_FAC(p) (((p)&LOG_FACMASK)>>3)
#define LOG_PID 0x01
#define LOG_CONS 0x02

View File

@ -128,7 +128,7 @@ static void _vsyslog(int priority, const char *message, va_list ap)
static void __vsyslog(int priority, const char *message, va_list ap)
{
int cs;
if (!(log_mask & LOG_MASK(priority&7)) || (priority&~0xff)) return;
if (!(log_mask & LOG_MASK(priority&7)) || (priority&~0x3ff)) return;
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cs);
LOCK(lock);
_vsyslog(priority, message, ap);