public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Subject: [PATCH 1/5] gas: avoid inserting extra newline in buffer_and_nest()
Date: Tue, 29 Nov 2022 11:36:21 +0100	[thread overview]
Message-ID: <01b77f18-8af3-4128-3645-2f1e05690197@suse.com> (raw)
In-Reply-To: <9afdf9c8-323b-78c1-d75b-8964e00cdec5@suse.com>

In "-alm" listings I've noticed an odd blank line following the inserted
.linefile one. This results from the explicit NL inserted being
redundant with the one left in place from the original input line by all
respective callers. Note that we need to compensate for the removed line
by bumping the directive argument (which in turn is decremented again in
s_linefile() before calling new_logical_line_flags(), and I have to
confess that when putting together the original change I was a little
puzzled by the imbalance of increments/decrements, but then I forgot to
actually go look for the cause).

While there also switch to sb_add_string() instead of effectively open-
coding it to some degree.

--- a/gas/macro.c
+++ b/gas/macro.c
@@ -142,10 +142,10 @@ buffer_and_nest (const char *from, const
 
       as_where (&line);
       if (!flag_m68k_mri)
-	linefile = xasprintf ("\t.linefile %u .\n", line);
+	linefile = xasprintf ("\t.linefile %u .", line + 1);
       else
-	linefile = xasprintf ("\tlinefile %u .\n", line);
-      sb_add_buffer (ptr, linefile, strlen (linefile));
+	linefile = xasprintf ("\tlinefile %u .", line + 1);
+      sb_add_string (ptr, linefile);
       xfree (linefile);
     }
 


  reply	other threads:[~2022-11-29 10:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-29 10:34 [PATCH 0/5] gas: diagnostics for macros and some tidying Jan Beulich
2022-11-29 10:36 ` Jan Beulich [this message]
2022-11-29 10:36 ` [PATCH 2/5] gas: squash (some) .linefile from listings Jan Beulich
2022-11-29 10:37 ` [PATCH 3/5] gas: add Dwarf line number test for .macro expansions Jan Beulich
2022-11-29 10:38 ` [PATCH 4/5] Arm: avoid unhelpful use of .macro in testsuite Jan Beulich
2022-11-29 10:44 ` [PATCH 5/5] gas: re-work line number tracking for macros and their expansions Jan Beulich

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=01b77f18-8af3-4128-3645-2f1e05690197@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@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).