From: Jan Beulich <jbeulich@suse.com>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org, gdb-patches@sourceware.org
Subject: Re: Get rid of fprintf_vma and sprintf_vma
Date: Mon, 1 Aug 2022 11:01:57 +0200 [thread overview]
Message-ID: <b6c70d97-f3ea-07a8-6e2d-caf3140d4f98@suse.com> (raw)
In-Reply-To: <YudXrks243QlD01x@squeak.grove.modra.org>
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)?
As to the patch - I'm happy to see these two helper functions go away.
I do recall running into issues resulting from their use.
Jan
next prev parent reply other threads:[~2022-08-01 9:02 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 [this message]
2022-08-01 13:32 ` Alan Modra
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=b6c70d97-f3ea-07a8-6e2d-caf3140d4f98@suse.com \
--to=jbeulich@suse.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
/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).