Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: Tom Tromey <tom@tromey.com>,
	 "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	 Keith Seitz <keiths@redhat.com>
Subject: Re: [PATCH] gdb, btrace: support libipt v2.2 events
Date: Tue, 05 May 2026 07:28:24 -0600	[thread overview]
Message-ID: <87se86f0jr.fsf@tromey.com> (raw)
In-Reply-To: <DM8PR11MB574978C2C2333F2E449CDCFFDE312@DM8PR11MB5749.namprd11.prod.outlook.com> (Markus T. Metzger's message of "Mon, 4 May 2026 07:16:13 +0000")

> I'd need to break at the =, then, like this:

> 	    std::string aux_string
> 	      = (std::string (_("trig: trbv = "))
> 		 + hex_string (event.variant.trig.trbv));

> The patch matches the surrounding style, so if you want this fixed, I'd need
> to fix it everywhere in a separate patch.

In gdb it's pretty normal for some code to be weird or wrong.
For example tdep files are less reviewed than others.

However the presence of some code that isn't standards-conformant
doesn't mean that new code should be.  You see this a lot with things
like NULL/nullptr -- using nullptr in new code doesn't imply that all
the old code has to be updated at the same time.

So IMO new code should follow the relevant coding standards, even if
other code in the same function does not.

thanks,
Tom

  parent reply	other threads:[~2026-05-05 13:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30 11:24 Markus Metzger
2026-04-30 18:11 ` Keith Seitz
2026-05-01 16:39   ` Tom Tromey
2026-05-04  7:16     ` Metzger, Markus T
2026-05-04 16:08       ` Simon Marchi
2026-05-05 13:28       ` Tom Tromey [this message]
2026-05-08  5:07         ` Metzger, Markus T
2026-05-04  7:16   ` Metzger, Markus T

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=87se86f0jr.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@redhat.com \
    --cc=markus.t.metzger@intel.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