From: Junio C Hamano <gitster@pobox.com>
To: Jeff Hostetler <git@jeffhostetler.com>
Cc: Taylor Blau <me@ttaylorr.com>,
mark via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, mark <870355373@qq.com>,
wangsirun <wangsirun@zhidaoauto.com>,
Jeff Hostetler <jeffhostetler@github.com>
Subject: Re: [PATCH] fix: check parameters in json-write.c
Date: Wed, 20 Sep 2023 13:10:55 -0700 [thread overview]
Message-ID: <xmqqil848v1s.fsf@gitster.g> (raw)
In-Reply-To: <dc45106c-d569-3438-d2ff-c3c94b6161d7@jeffhostetler.com> (Jeff Hostetler's message of "Wed, 20 Sep 2023 16:02:00 -0400")
Jeff Hostetler <git@jeffhostetler.com> writes:
> I suppose it is OK for the 2 string-value cases to assume a NULL pointer
> could be written as "" in the JSON output. Although, I kinda think a
> NULL pointer should call BUG() as we have in the various assert_*()
> routines. It really is a kind of logic error in the caller.
FWIW, that is my preference, too.
> Regardless what we decide for the <string-value> case, in the <key>
> case, the resulting JSON would not be valid. We need for the key to
> be a non-empty string. For example { "" : 1 } is not valid JSON.
> So the key case should call BUG() and not try to hide it.
I do not have a strong opinion on this side, and leave it up to the
area experts ;-)
>
> So I'm leaning towards just making it a BUG() in all cases, but I'm
> open to the other mixed handling.
>
> Jeff
prev parent reply other threads:[~2023-09-20 20:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 11:54 [PATCH] fix: check parameters in json-write.c mark via GitGitGadget
2023-09-19 17:48 ` Taylor Blau
2023-09-20 20:02 ` Jeff Hostetler
2023-09-20 20:10 ` Junio C Hamano [this message]
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=xmqqil848v1s.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=870355373@qq.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=jeffhostetler@github.com \
--cc=me@ttaylorr.com \
--cc=wangsirun@zhidaoauto.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.