On 17 June 2014 22:07, Stefan Weil <s...@weilnetz.de> wrote:
> This helps detecting wrong format strings.
>
> Signed-off-by: Stefan Weil <s...@weilnetz.de>
> ---
>
> This patch is not intended to be applied before fixing some potential errors.
>
> Addings the GNU gcc format attribute results in lots of compiler errors like
> these ones:
>
> CXX disas/libvixl/a64/disasm-a64.o
> disas/libvixl/a64/disasm-a64.cc: In member function ‘int
> vixl::Disassembler::SubstituteImmediateField(vixl::Instruction*, const
> char*)’:
> disas/libvixl/a64/disasm-a64.cc:1372:66: error: format ‘%d’ expects argument
> of type ‘int’, but argument 3 has type ‘int64_t {aka long int}’
> [-Werror=format]
> disas/libvixl/a64/disasm-a64.cc:1421:52: error: format ‘%d’ expects argument
> of type ‘int’, but argument 3 has type ‘int64_t {aka long int}’
> [-Werror=format]
> disas/libvixl/a64/disasm-a64.cc:1442:48: error: format ‘%d’ expects argument
> of type ‘int’, but argument 3 has type ‘int64_t {aka long int}’
> [-Werror=format]
> disas/libvixl/a64/disasm-a64.cc:1449:42: error: format ‘%d’ expects argument
> of type ‘int’, but argument 3 has type ‘int64_t {aka long int}’
> [-Werror=format]
>
> I don't know the reason, because all locations seem to have arguments
> which are function calls, and the called function returns Instr which
> is uint32_t, not int64_t.
As usual, I'm sceptical about carrying local libvixl patches
unless they're really necessary.
Which platform are you building on, and what does it
define uint32_t and int64_t as? I agree that it looks to me
like the compiler's wrong here, but maybe there's an integer
promotion rule for varargs I'm unaware of that means the
uint32_t gets promoted to int64_t ?
If the format strings really are wrong we can feed that back
to upstream libvixl and get them fixed there.
thanks
-- PMM
