RFC: Remove %A, %B and %L from error messages
Maciej W. Rozycki
Sun Feb 18 15:21:00 GMT 2018
> I am considering applying the attached patch to remove the %A,
> %B format specifiers and the %L format qualifier from BFD error
> messages. The reasons for doing this are twofold: 1) It allows the
> bfd_error_handler function to be annotated with ATTRIBUTE_PRINTF, thus
> helping to detect formatting problems; and 2) the strings can now be
> verified by msgfmt and the translation project's validation code,
> which will lead to better translations. (Plus it should help avoid
> bugs like PR 22828).
> It does mean loosing the convenience of the %A, %B and %L operators,
> and replacing them with explicit function calls, but I think that it
> is worth it.
I think it's not, as far as `%A' and `%B' are concerned.
How about doing it the Linux way and replacing `%A' and `%B' with `%pA'
and `%pB' respectively? They've been using this for `printk' with their
equivalent of ATTRIBUTE_PRINTF:
#define __printf(a, b) __attribute__((format(printf, a, b)))
for ages now. Here's an example of documented syntax (taken from
(with __builtin_extract_return_addr() translation)
The ``F`` and ``f`` specifiers are for printing function pointers,
for example, f->func, &gettimeofday. They have the same result as
``S`` and ``s`` specifiers. But they do an extra conversion on
ia64, ppc64 and parisc64 architectures where the function pointers
are actually function descriptors.
The ``S`` and ``s`` specifiers can be used for printing symbols
from direct addresses, for example, __builtin_return_address(0),
(void *)regs->ip. They result in the symbol name with (``S``) or
without (``s``) offsets. If KALLSYMS are disabled then the symbol
address is printed instead.
The ``B`` specifier results in the symbol name with offsets and should be
used when printing stack backtraces. The specifier takes into
consideration the effect of compiler optimisations which may occur
when tail-call``s are used and marked with the noreturn GCC attribute."
-- which I think corresponds to our usage. Having glanced over the info
page for `msgfmt' I believe it should cope too.
Then I would expect the `L' qualifier to just work with ATTRIBUTE_PRINTF,
as it's been supported by GCC/glibc since forever. If not, then I'm fine
with moving forward on this one.
More information about the Binutils