git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Pranit Bauva <pranit.bauva@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>,
	Christian Couder <chriscool@tuxfamily.org>,
	Lars Schneider <larsxschneider@gmail.com>
Subject: Re: [PATCH 1/2] bisect--helper: `is_expected_rev` shell function in C
Date: Sat, 11 Jun 2016 17:48:06 +0530	[thread overview]
Message-ID: <CAFZEwPMqwtw061O0QVRGf+dqpxKjp1jRvFE5CUEayEiUhxWveQ@mail.gmail.com> (raw)
In-Reply-To: <CAPig+cTECf6JT6+1SWo-eEwKPOAN3eYL20tvFS90Q28gu5vrZw@mail.gmail.com>

Hey Eric,

On Sat, Jun 11, 2016 at 12:44 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Fri, Jun 10, 2016 at 9:39 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> On Fri, Jun 10, 2016 at 3:03 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> On Wed, Jun 8, 2016 at 11:24 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>>> Reimplement `is_expected_rev` shell function in C. This will further be
>>>> called from `check_expected_revs` function. This is a quite small
>>>> function thus subcommand facility is redundant.
>>>
>>> This patch should be squashed into patch 2/2, as it is otherwise
>>> pointless without that patch, and merely adds dead code.
>>
>> Sure I will squash and will explain it in the commit message.
>
> Explain what in the commit message? If anything, I'd expect the commit
> message to shrink since you won't need to explain anymore that this
> function is split out.

Yes I would remove the part where it is explained that this function
is split out. I will just explain that 2 functions are converted in 1
commit.

>>>> +       if (!file_exists(git_path_bisect_expected_rev()))
>>>> +               return 0;
>>>
>>> Invoking file_exists() seems unnecessarily redundant when you can
>>> discern effectively the same by checking the return value of
>>> strbuf_read_file() below. I'd drop the file_exists() check altogether.
>>
>> I wanted to imitate the code. But I guess it would actually be better
>> if I drop this file_exists().
>
> There is a bit of a lesson to be learned by this example. While it's
> true that the C conversion should retain the behavior of the original
> shell code, that does not mean blindly mirroring the implementation
> line for line is a good idea. A couple things to take into
> consideration:
>
> There are idiomatic ways of doing things in each language. What is
> idiomatic in shell is not necessarily so in C. The C conversion should
> employ C idioms and flow in a way which is natural for C code.
>
> Consider what the original shell code is doing at a higher level than
> merely by reading it line-by-line. In the case in question, the code
> is:
>
>     test -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
>     test "$1" = $(cat "$GIT_DIR/BISECT_EXPECTED_REV")
>
> While it's true that it's asking "does the file exist and is its value
> the same as $1", the 'test -f' avoids a "file not found" error from
> the $(cat ...) invocation. Since the return value of
> strbuf_read_file() effectively encapsulates the "does the file exist"
> check, a separate check isn't really needed.

True. I will keep this in mind.

>>>> +       if (!strbuf_read_file(&actual_hex, git_path_bisect_expected_rev(), 0))
>>>> +               return 0;
>>>
>>> What exactly is this trying to do? Considering that strbuf_read_file()
>>> returns -1 upon error, otherwise the number of bytes read, if I'm
>>> reading this correctly, is_expected_rev() returns false if
>>> strbuf_read_file() encounters an error (which is fine) but also when
>>> it successfully reads the file and its content length is non-zero
>>> (which is very odd).
>>>
>>>> +       strbuf_trim(&actual_hex);
>>>> +       return !strcmp(actual_hex.buf, expected_hex);
>>>
>>> Thus, it only ever gets to this point if the file exists but is empty,
>>> which is very unlikely to match 'expected_hex'. I could understand it
>>> if you checked the result of strbuf_read_file() with <0 or even <=0,
>>> but the current code doesn't make sense to me.
>>>
>>> Am I misunderstanding?
>>
>> Definitely not. Thanks for pointing it out. :) It went off my head
>> that strbuf_read_file returns the bytes it reads. Also the code
>> comment regarding strbuf_read_file does not mention it which probably
>> misguided me. I should also send a fixing patch so that someone else
>> does not fall into this like I did.
>
> Out of curiosity, did the test suite pass with this patch applied?
> This is such an egregious bug that it's hard to imagine the tests
> passing, but if they did, then that may be a good indication that
> coverage is too sparse and ought to be improved.

Yes the test suite passed perfectly. I have inculcated the habit of
running the whole test suite before sending patches. Yes some parts of
a test suite seem to be missing. How about I do it in the end? By this
I won't have to setup yet another coverage tool for shell script. I
can use the coverage tool by GNU to test the coverage after bisect is
a C code. Till that time the patches can reside in the pu branch.

Regards,
Pranit Bauva

      reply	other threads:[~2016-06-11 12:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08 15:24 [PATCH 1/2] bisect--helper: `is_expected_rev` shell function in C Pranit Bauva
2016-06-08 15:24 ` [PATCH 2/2] bisect--helper: `check_expected_revs` " Pranit Bauva
2016-06-09 21:54   ` Eric Sunshine
2016-06-10  7:52     ` Pranit Bauva
2016-06-09 21:33 ` [PATCH 1/2] bisect--helper: `is_expected_rev` " Eric Sunshine
2016-06-09 21:39   ` Eric Sunshine
2016-06-10 13:39   ` Pranit Bauva
2016-06-10 19:14     ` Eric Sunshine
2016-06-11 12:18       ` Pranit Bauva [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

  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=CAFZEwPMqwtw061O0QVRGf+dqpxKjp1jRvFE5CUEayEiUhxWveQ@mail.gmail.com \
    --to=pranit.bauva@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=larsxschneider@gmail.com \
    --cc=sunshine@sunshineco.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.
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).