This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [patch bfd]: Add further support for x86_64 mingw
- From: Brian Dessent <brian at dessent dot net>
- To: Kai Tietz <Kai dot Tietz at onevision dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Tue, 22 Jan 2008 07:23:41 -0800
- Subject: Re: [patch bfd]: Add further support for x86_64 mingw
- References: <OFD547C4B9.B36CD08D-ONC12573D8.005075C8-C12573D8.005130F1@onevision.de>
- Reply-to: Binutils <binutils at sourceware dot org>
Kai Tietz wrote:
> > Can't you just use the standard inttypes.h macros, e.g.
> >
> > #define sprintf_vma(s,x) sprintf (s, "%016" PRIx64, x)
>
> I could add the inttypes.h header into bfd-in.h, but this would mean to
> inherit config, too. This I think isn't a good choice. So the other
I suppose that would pull in a new dependency where it previously didn't
exist before. I was thinking you could provide a default value of llx
(et cetera) if it's not defined, but you'd still need to do a header
check and I guess that's too much trouble.
> solution to prevent to much target specific '#ifdef'-clauses would be to
> add to bfd-in.h an equivalent to the printf formatters in standard
> inttypes.h, like BFD_PRIx64, BFD_PRIx32, ...? Otherwise it seems to be
> better to live with target specific clauses. What is your opinion about
> this?
Is _WIN32 really the right thing to predicate this on? For example
someone using Cygwin and also using the w32api directly (by #include
<windows.h>) will have _WIN32 defined, but they aren't using MSVCRT and
so I64x is wrong. Admittedly this is probably not something that is
likely to occur in bfd, and I know this is a common idiom, but why not
conditionalize it on __MSVCRT__ instead? MinGW gcc defines this as a
builtin right next to _WIN32 but it is not overloaded with the meaning
of "I'm using the Windows headers."
Brian