Re: Get rid of fprintf_vma and sprintf_vma

[Alan Modra via Gdb-patches <gdb-patches@sourceware.org>]

On Mon, Aug 01, 2022 at 11:01:57AM +0200, Jan Beulich wrote:
> On 01.08.2022 06:33, Alan Modra via Binutils wrote:
> > --- a/gas/config/tc-i386.c
> > +++ b/gas/config/tc-i386.c
> > @@ -2377,15 +2377,8 @@ offset_in_range (offsetT val, int size)
> >      }
> >  
> >    if ((val & ~mask) != 0 && (-val & ~mask) != 0)
> > -    {
> > -      char val_buf[128];
> > -      char masked_buf[128];
> > -
> > -      /* Coded this way in order to ease translation.  */
> > -      sprintf_vma (val_buf, val);
> > -      sprintf_vma (masked_buf, val & mask);
> > -      as_warn (_("0x%s shortened to 0x%s"), val_buf, masked_buf);
> > -    }
> > +    as_warn (_("0x%" PRIx64 " shortened to 0x%" PRIx64),
> > +	     (uint64_t) val, (uint64_t) (val & mask));
> >  
> >    return val & mask;
> >  }
> > @@ -4913,12 +4906,8 @@ md_assemble (char *line)
> >  	  i.types[j].bitfield.disp32 = 0;
> >  	  if (i.types[j].bitfield.baseindex)
> >  	    {
> > -	      char number_buf[128];
> > -
> > -	      /* Coded this way in order to allow for ease of translation.  */
> > -	      sprintf_vma (number_buf, exp->X_add_number);
> > -	      as_bad (_("0x%s out of range of signed 32bit displacement"),
> > -		      number_buf);
> > +	      as_bad (_("0x%" PRIx64 " out of range of signed 32bit displacement"),
> > +		      (uint64_t) exp->X_add_number);
> >  	      return;
> >  	    }
> >  	}
> 
> Just as a general remark / question, seeing these changes: Wouldn't
> it be slightly better to use the # modifier in cases like these? It's
> one byte less of literal string space and results in zero to be
> printed as plain "0" (no 0x prefix)?

Yes, that would be nicer.  I do have a nagging suspicion that some
compilers complain about unknown format specifier if you write
"%#" PRIx64.  Maybe that was with "%#" BFD_VMA_FMT "x", I can't
remember exactly where I saw the warning.  Or possibly it was some
random development version of gcc I happened to be using, in which
case it's not a problem.

-- 
Alan Modra
Australia Development Lab, IBM