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

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

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.

bfd_vma printing is poorly handled in many places in sim when bfd_vma is 64-bit
but the host cpu is 32-bit (i.e. sizeof(long) == 4).  the (long) cast pattern
that i used here for printing is based on those.  i don't think sim is the only
place that does this poorly tbh, it's just what i'm focusing on.

imo picking any type to cast to and copying & pasting that everywhere is a bit
of a losing proposition.  imo we should provide a PRI constant for code to use
as that'll align with other fixed types (e.g. uint64_t).  that makes it obvious
when code is doing it correctly vs the compiler not happening to warn because
the current configuration provides typedefs that align with the hardcoded sizes.
but i don't really have the energy to take on that work.

specifically for the rx_load code, this stuff needs to get deleted entirely and
switched to the existing common/ logic.  which is why i preferred a hacky patch
here rather than diving deeper into the problem.

so you're not wrong, i'm just not investing in code that i know will die :).
-mike