git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Carlo Arenas <carenas@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, tr@thomasrast.ch
Subject: Re: [PATCH] add -p: avoid use of undefined $key when ReadKey -> EOF
Date: Sun, 28 Nov 2021 12:52:39 -0800	[thread overview]
Message-ID: <CAPUEspjo+cKLnE+MoABp_NnGDCCz8fL=pJj3ZNsKmCVetUn1jA@mail.gmail.com> (raw)
In-Reply-To: <xmqq8rx85ala.fsf@gitster.g>

On Sun, Nov 28, 2021 at 11:44 AM Junio C Hamano <gitster@pobox.com> wrote:
> Carlo Marcelo Arenas Belón  <carenas@gmail.com> writes:
> > Add a test for undefined and encapsulate the loop and the original
> > print that relied on it within it.
>
> I wondered where a change to t/ directory was, but we are not
> talking about that kind of test ;-)  OK.

Will change the wording in v2 with something less ambiguous like
"Check for undefined.."

> I am undecided, but the minimum patch below seems to makes the above
> intention in the updated code clearer.
>
> diff --git i/git-add--interactive.perl w/git-add--interactive.perl
> index bc3a1e8eff..c459c675e7 100755
> --- i/git-add--interactive.perl
> +++ w/git-add--interactive.perl
> @@ -1175,7 +1175,7 @@ sub prompt_single_character {
>                 ReadMode 'cbreak';
>                 my $key = ReadKey 0;
>                 ReadMode 'restore';
> -               if ($use_termcap and $key eq "\e") {
> +               if (defined $key && $use_termcap and $key eq "\e") {
>                         while (!defined $term_escapes{$key}) {
>                                 my $next = ReadKey 0.5;
>                                 last if (!defined $next);

The issue I had with that was that the order of the checks is slightly
awkward and inefficient (ex: $use_termcap = false probably should
short circuit, and both checks for $key make more sense next to each
other) and doing it outside avoids the extra !defined check for print.

It would also look cleaner IMHO if the expression would be rewritten
to use '&&' instead of 'and', which smells like unnecessary
refactoring that I intentionally tried to avoid by creating a
precondition instead so `diff -w` is really small and straight
forward.

I have no strong opinions eitherway, so let me know what you would
prefer and will get a v2 with it; thanks for reviewing.

Carlo

PS. list email is for whatever reason taking a long time to arrive
from vger, hopefully not many are affected, but I might be slow to
respond

  reply	other threads:[~2021-11-28 20:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-28 17:49 [PATCH] add -p: avoid use of undefined $key when ReadKey -> EOF Carlo Marcelo Arenas Belón
2021-11-28 19:44 ` Junio C Hamano
2021-11-28 20:52   ` Carlo Arenas [this message]
2021-11-28 23:15     ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPUEspjo+cKLnE+MoABp_NnGDCCz8fL=pJj3ZNsKmCVetUn1jA@mail.gmail.com' \
    --to=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tr@thomasrast.ch \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).