From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Reformatting dynamic linker error mesages? (or, Bikeshed April 2015)
Date: Wed, 22 Apr 2015 02:15:28 -0400 [thread overview]
Message-ID: <20150422061527.GC6817@brightrain.aerifal.cx> (raw)
In-Reply-To: <20150422003740.GB1773@Sparta>
On Wed, Apr 22, 2015 at 12:37:41AM +0000, Isaac Dunham wrote:
> On Sat, Apr 18, 2015 at 06:54:36PM -0400, Rich Felker wrote:
> > One item on the roadmap that I want to work on is making the dynamic
> > linker error strings translatable. Since (unwritten, maybe) policy is
> > that we don't translate format strings in libc (it makes untrusted
> > locale files dangerous), this is going to require at least
> > restructuring of the code that generates the messages, and also calls
> > for restructuring of the actual text. I'm looking for ideas on how to
> > do this and make it the most legible and informative.
> >
> > The errors we have to worry with are:
>
> [reordered to make redundancy more obvious]
Thanks.
> > "Symbol not found: %s"
> > "Error relocating %s: %s: symbol not found"
> > "Error relocating %s: cannot allocate TLSDESC for %s",
> > "Error relocating %s: unsupported relocation type %d",
> > "Error relocating %s: RELRO protection failed: %m",
> > "Error loading shared library %s: %m (needed by %s)",
> > "Error loading shared library %s: %m"
> > "cannot load %s: %m\n"
> > "%s: Not a valid dynamic program\n"
> > "Library %s is not already loaded"
> > "Invalid library handle %p"
> > "Dynamic loading not supported"
> > "Unsupported request %d"
Here's a first try at making these reasonable for localization (still
left as format strings for clarity even though they can't actually
be):
"Symbol not found: %s"
"Error relocating library: %s: Symbol not found: %s"
"Error relocating library: %s: Unsupported relocation type: %d"
"Error relocating library: %s: Memory protection failure: %m"
"Error relocating library: %s: Out of memory"
and all of the above with:
"Error relocating main program:"
instead of library.
"Error loading dependency: %s (%s): %m"
"Error loading library: %s: %m"
"Error loading file: %s: %m"
"Library not already loaded: %s"
"Invalid library handle: %p"
"Dynamic loading not supported"
"Unsupported request: %d"
The %m's are also something of a fiction since there are a few cases
where we would want a message that doesn't come from errno (e.g.
invalid ELF headers). That's mildly ugly but definitely solvable.
> It looks like there's a bit of redundancy here, where 2-5 share
> "Error relocating %s", 6 and 7 share "Error loading shared library",
> and 1 and 2 share (save capitalization) "symbol not found".
> It would be nice to see that redundancy turned into shared submessages.
Yes. For example with symbol-not-found, the actual format would be
something like:
"%s: %s: %s: %s", _("Error relocating library"), name, _("Symbol not found"), sym
and:
"%s: %s", _("Symbol not found"), sym
Note that I'm using the GNU gettext _() notation for translation just
to make this simple to write in email; I don't endorse this in code.
:-)
> I also notice that there's a mix of two equivalent formats:
> error("...%m...") and
> dprintf(fd, "...%s...", strerror(errno))
>
> which I find odd.
I believe this is because the error function was originally unsuitable
for some of those places, but I may be wrong. I think it could be used
now.
> Do we want the calls to strerror(errno) converted to something localized?
> If so, %m would seem to be harmful.
strerror already returns a translated message. So does %m.
> On the other hand...is localization set up this early?
At first the messages would only be available via dlerror after
setlocale. However I think it may make sense to have the dynamic
linker setlocale(LC_ALL, "") on the first error. Since the main
program will never be invoked if there are errors, this would not
affect program semantics at all.
Rich
prev parent reply other threads:[~2015-04-22 6:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-18 22:54 Rich Felker
2015-04-22 0:37 ` Isaac Dunham
2015-04-22 6:15 ` Rich Felker [this message]
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=20150422061527.GC6817@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).