Re: [PATCH/committed] sim: rx: cast bfd_vma when printing

[Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org>]

On 03 May 2021 16:47, Christian Biesinger via Gdb-patches wrote:
> On Mon, May 3, 2021 at 3:57 PM Mike Frysinger wrote:
> > On 03 May 2021 11:20, Christian Biesinger wrote:
> > > On Sat, May 1, 2021, 15:29 Mike Frysinger wrote:
> > > > A bit of a hack, but it's what we've been doing so far when printing
> > > > bfd_vma's since bfd doesn't provide PRI helper types for us to use.
> > > >
> > > > --- a/sim/rx/load.c
> > > > +++ b/sim/rx/load.c
> > > > @@ -151,7 +151,7 @@ rx_load (bfd *prog, host_callback *callback)
> > > >         }
> > > >        if (bfd_bread (buf, size, prog) != size)
> > > >         {
> > > > -         fprintf (stderr, "Failed to read %lx bytes\n", size);
> > > > +         fprintf (stderr, "Failed to read %lx bytes\n", (long) size);
> > >
> > > Wouldn't it be better to use "long long", especially for mingw?
> >
> > not sure why mingw is special here.  but let's ignore that.
> 
> mingw (and msvc) is special because sizeof(long) is 4, even on a 64-bit system.
> https://stackoverflow.com/questions/22344388/size-of-long-int-and-int-in-c-showing-4-bytes

we have ILP32 models on mips/n32 [2000], x86_64/x32 [2011], and aarch64 [2016],
so i don't think mingw does anything that unique anymore.

we've long known that long is inappropriate for things that could be 64-bit.
the trouble is when we half implement the suite like just coming up with a
typedef and skimping on printf formats :(.
-mike