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
- From: Alan Modra <amodra at gmail dot com>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: Binutils <binutils at sourceware dot org>, Nick Clifton <nickc at redhat dot com>
- Date: Thu, 11 Oct 2012 12:18:19 +1030
- Subject: Re: [patch bfd]: Fix printf formatter for mingw 1 of N
- References: <CAEwic4YmqeafrZe9HzPZw+D7R_7RRjJ1ZepiKX-AmW3x3CAtJg@mail.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.
> 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.
--
Alan Modra
Australia Development Lab, IBM