This is the mail archive of the
mailing list for the glibc project.
[Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 20 Dec 2013 18:18:06 +0000
- Subject: [Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess
- Auto-submitted: auto-generated
Bug ID: 16355
Summary: syslog.h's SYSLOG_NAMES namespace violation and utter
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
CC: drepper.fsp at gmail dot com
syslog.h badly violates the namespace and not just declares but defines arrays
facilitynames and prioritynames if the macro SYSLOG_NAMES is defined by the
application. This is non-conforming since SYSLOG_NAMES is in the namespace
belonging to the application. Technically the conformance issue could be fixed
#if defined(SYSLOG_NAMES) && defined(__USE_MISC)
or similar, but the whole thing is still really bad behavior. In particular,
only one translation unit can define SYSLOG_NAMES, since it causes definitions
for the arrays to be emitted. And there's no way to access the arrays from
other translation units since there's no way to request declarations without
Most possible fixes have drawbacks:
1. facilitynames could be made external and moved into libc, with just a
declaration in the header. This is really bad because it results in a copy
relocation and the size of the array becomes part of the ABI.
2. facilitynames could be #defined as (__get_facilitynames()), with CODE
*__get_facilitynames(); This is bad because it breaks applications that assume
it has array type (e.g. that sizeof is meaningful).
3. facilitynames could be #defined as (*__get_facilitynames()) or similar, with
CODE (*__get_facilitynames())[N]; This hard-codes the size as part of the ABI
but at least eliminates the copy relocation.
4. facilitynames could be given internal linkage (static). This probably
couldn't break anything, but I'm not sure.
5. facilitynames could be defined as a macro expanding to a compound literal
array. This is also unlikely to break anything (except maybe -std=c89
-pedantic-errors or something) but it does result in bloat when the array is
used in more than one place.
Other ideas welcome...
You are receiving this mail because:
You are on the CC list for the bug.