This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [patch bfd]: Fix printf formatter for mingw 1 of N
2012/10/11 Alan Modra <amodra@gmail.com>:
> On Wed, Oct 10, 2012 at 04:35:00PM +0200, Kai Tietz wrote:
>> Hello,
>>
>> this is first patch addressing this issue. There are several other
>> places where similiar issues are happening (see use of %z, %lld, and
>> %llx in bfd, binutils, and opcode sources). There are are several
>
> Are there really occurrences of %z in a printf format string? I do
> see some %z in strings, but they aren't passed to printf. Maybe I
> didn't look carefully enough.
Sure, there are. They are occuring all in gold. This tool shall work
on windows-host AFAIU, so there is for sure an issue. (gold has also
many uses of %llx, too).
>> different ways to resolve these issue. First would be to add - as
>> done by this patch - include of inttypes.h - if available - and use
>> int64_t here instead 'long long' type. Second would be to add those
>> helper macros to bfd-in.h (eg BFD_PRI64 and bfd_int64_t/bfd_uint64_t).
>> Another variant would be to use in binutils the gnulib existing for
>> gdb for now. The fourth solution would be to enable for mingw-targets
>> by default POSIX-printf, which of course don't resolve the issue for
>> VC.
>> So I would like to get your opinion, which variant is preferred by
>> binutils community to resolve this printf-formatting issue.
>>
>> ChangeLog
>>
>> 2012-10-10 Kai Tietz
>>
>> * coff-rs600.c (FMT20): Use
>> PRId64 macro, if available.
>> (FMT20_type): New.
>
> This doesn't look correct. intptr_t might be a 32-bit type on a
> 32-bit host. I think you should be casting to bfd_vma, and using
> BFD_VMA_FMT here and similarly in opcodes/ia64-dis.c.
Yes, sorry. I have in my repository int64_t instead. I pasted wrong
patch-version. Nevertheless I am not quite sure if at all places
bfd_vma is suitable. Especially in gold/
Regards,
Kai