public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/16355] New: syslog.h's SYSLOG_NAMES namespace violation and utter mess Date: Fri, 20 Dec 2013 18:18:00 -0000 [thread overview] Message-ID: <bug-16355-131@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2013-12-20 18:18 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-12-20 18:18 bugdal at aerifal dot cx [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-16355-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).