git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Adam Murray via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,  Adam Murray <ad@canva.com>
Subject: Re: [PATCH] trace2: prevent segfault on config collection where no value specified
Date: Thu, 07 Nov 2024 12:02:47 +0900	[thread overview]
Message-ID: <xmqqikszvj8o.fsf@gitster.g> (raw)
In-Reply-To: <20241107020100.GC961214@coredump.intra.peff.net> (Jeff King's message of "Wed, 6 Nov 2024 21:01:00 -0500")

Jeff King <peff@peff.net> writes:

> I.e., doing this, with an explicit value for the config option:
>
>   GIT_TRACE2=true GIT_TRACE2_CONFIG_PARAMS=status.* git -c status.relativePaths=true version
>
> should (and does) show:
>
>   20:48:11.662470 trace2.c:437                      def_param scope:command status.relativepaths=true
>
> If we swap that our for "-c status.relativePaths", then the outcome is
> the same: we've turned on that config option. But with your patch, the
> trace won't mention it at all.

which may be improvement, but ideally, the "valueless truth" case
should be given differently, perhaps like 

   20:48:11.662470 trace2.c:437                      def_param scope:command status.relativepaths

to allow showing what exactly the system has seen.  After all, trace
output is often used for debugging, and it is not unusual for a
buggy code path to behave on explicit truth and valueless truth
differently.

> So here I think we need to either:
>
>   1. Just quietly substitute "true" for the value. For a bool, the two
>      are equivalent, and this is probably an acceptable fiction for a
>      trace to show. For a non-bool (e.g., something like "author.name"),
>      though, it's an error, and the trace is somewhat misleading.
>
>   2. Put in some special marker for the NULL value. Something like
>      "(null)" works, but it's ambiguous with a config of the same value
>      (which obviously you wouldn't expect in normal use, but since the
>      point of tracing is often to debug, I could see it being
>      misleading).
>
> All of this is made harder by the fact that there are multiple output
> targets. So you'd have to pass the NULL down to them and let them handle
> it. Something like:
> ...
> diff --git a/trace2/tr2_tgt_normal.c b/trace2/tr2_tgt_normal.c
> index baef48aa69..924736ab36 100644
> --- a/trace2/tr2_tgt_normal.c
> +++ b/trace2/tr2_tgt_normal.c
> @@ -307,8 +307,9 @@ static void fn_param_fl(const char *file, int line, const char *param,
>  	enum config_scope scope = kvi->scope;
>  	const char *scope_name = config_scope_name(scope);
>  
> -	strbuf_addf(&buf_payload, "def_param scope:%s %s=%s", scope_name, param,
> -		    value);
> +	strbuf_addf(&buf_payload, "def_param scope:%s %s", scope_name, param);
> +	if (value)
> +		strbuf_addf(&buf_payload, "=%s", value);

Yes, exactly.

>  	normal_io_write_fl(file, line, &buf_payload);
>  	strbuf_release(&buf_payload);
>  }
>
> but you'd need to do the same for each target implementation.

Thanks.

  reply	other threads:[~2024-11-07  3:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-07  0:04 [PATCH] trace2: prevent segfault on config collection where no value specified Adam Murray via GitGitGadget
2024-11-07  2:01 ` Jeff King
2024-11-07  3:02   ` Junio C Hamano [this message]
2025-01-10  7:28 ` [PATCH v2] " Adam Murray via GitGitGadget
2025-01-10 17:10   ` Junio C Hamano
2025-01-22 10:11   ` Johannes Schindelin
2025-01-22 18:12     ` Junio C Hamano
2025-01-22 18:18       ` Junio C Hamano
2025-01-23 17:01         ` D. Ben Knoble
2025-01-23 18:02           ` Junio C Hamano
2025-01-23 21:15             ` D. Ben Knoble

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=xmqqikszvj8o.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ad@canva.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=peff@peff.net \
    /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 NNTP newsgroup(s).