Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 22 Apr 2015 02:15:28 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Reformatting dynamic linker error mesages? (or, Bikeshed
 April 2015)

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.