From: Alan Modra <amodra@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: binutils@sourceware.org, gdb-patches@sourceware.org
Subject: Re: Get rid of fprintf_vma and sprintf_vma
Date: Mon, 1 Aug 2022 23:02:33 +0930 [thread overview]
Message-ID: <YufV8eievmHe5aKi@squeak.grove.modra.org> (raw)
In-Reply-To: <b6c70d97-f3ea-07a8-6e2d-caf3140d4f98@suse.com>
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
next prev parent reply other threads:[~2022-08-01 13:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-01 4:33 Alan Modra
2022-08-01 9:01 ` Jan Beulich
2022-08-01 13:32 ` Alan Modra [this message]
2022-08-04 3:41 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YufV8eievmHe5aKi@squeak.grove.modra.org \
--to=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=jbeulich@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).