public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess
@ 2013-12-20 18:18 bugdal at aerifal dot cx
2013-12-20 22:46 ` [Bug libc/16355] " schwab@linux-m68k.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: bugdal at aerifal dot cx @ 2013-12-20 18:18 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16355
Bug ID: 16355
Summary: syslog.h's SYSLOG_NAMES namespace violation and utter
mess
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
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
by changing:
#ifdef SYSLOG_NAMES
to:
#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
definitions.
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/16355] syslog.h's SYSLOG_NAMES namespace violation and utter mess
2013-12-20 18:18 [Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess bugdal at aerifal dot cx
@ 2013-12-20 22:46 ` schwab@linux-m68k.org
2013-12-20 23:04 ` bugdal at aerifal dot cx
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: schwab@linux-m68k.org @ 2013-12-20 22:46 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16355
--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
SYSLOG_NAMES is defined by the syslogd source to get the definition of
facilitynames and prioritynames, see
<http://svnweb.freebsd.org/base/head/usr.sbin/syslogd/syslogd.c?revision=258077&view=markup>.
As such it can safely be removed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/16355] syslog.h's SYSLOG_NAMES namespace violation and utter mess
2013-12-20 18:18 [Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess bugdal at aerifal dot cx
2013-12-20 22:46 ` [Bug libc/16355] " schwab@linux-m68k.org
@ 2013-12-20 23:04 ` bugdal at aerifal dot cx
2013-12-20 23:56 ` schwab@linux-m68k.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: bugdal at aerifal dot cx @ 2013-12-20 23:04 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16355
--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
Andreas, what? Your comment makes no sense. First you say it's defined by an
application (FreeBSD syslogd, which probably is not the one used on most
glibc-based systems...) to get these definitions, and then you say it's safe to
remove (it's not; it would break the application).
At the very least, several syslogd implementations, including Busybox syslogd,
define SYSLOG_NAMES to get these definitions. So just removing them would need
to be coordinated with programs using them. It's _probably_ safe to just move
the whole mess under __USE_MISC though to fix the conformance issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/16355] syslog.h's SYSLOG_NAMES namespace violation and utter mess
2013-12-20 18:18 [Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess bugdal at aerifal dot cx
2013-12-20 22:46 ` [Bug libc/16355] " schwab@linux-m68k.org
2013-12-20 23:04 ` bugdal at aerifal dot cx
@ 2013-12-20 23:56 ` schwab@linux-m68k.org
2014-06-13 11:23 ` fweimer at redhat dot com
2022-04-15 21:13 ` adhemerval.zanella at linaro dot org
4 siblings, 0 replies; 6+ messages in thread
From: schwab@linux-m68k.org @ 2013-12-20 23:56 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16355
--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
FreeBSD never uses glibc's syslog.h.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/16355] syslog.h's SYSLOG_NAMES namespace violation and utter mess
2013-12-20 18:18 [Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess bugdal at aerifal dot cx
` (2 preceding siblings ...)
2013-12-20 23:56 ` schwab@linux-m68k.org
@ 2014-06-13 11:23 ` fweimer at redhat dot com
2022-04-15 21:13 ` adhemerval.zanella at linaro dot org
4 siblings, 0 replies; 6+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 11:23 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16355
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libc/16355] syslog.h's SYSLOG_NAMES namespace violation and utter mess
2013-12-20 18:18 [Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess bugdal at aerifal dot cx
` (3 preceding siblings ...)
2014-06-13 11:23 ` fweimer at redhat dot com
@ 2022-04-15 21:13 ` adhemerval.zanella at linaro dot org
4 siblings, 0 replies; 6+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2022-04-15 21:13 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16355
Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
CC| |adhemerval.zanella at linaro dot o
| |rg
Target Milestone|--- |2.36
Status|NEW |RESOLVED
--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Fixed on 2.36.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-04-15 21:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-20 18:18 [Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess bugdal at aerifal dot cx
2013-12-20 22:46 ` [Bug libc/16355] " schwab@linux-m68k.org
2013-12-20 23:04 ` bugdal at aerifal dot cx
2013-12-20 23:56 ` schwab@linux-m68k.org
2014-06-13 11:23 ` fweimer at redhat dot com
2022-04-15 21:13 ` adhemerval.zanella at linaro dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).