From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-7.2 required=5.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 6719320193 for ; Thu, 16 Jun 2016 20:47:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754381AbcFPUrs (ORCPT ); Thu, 16 Jun 2016 16:47:48 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33282 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754022AbcFPUrr (ORCPT ); Thu, 16 Jun 2016 16:47:47 -0400 Received: by mail-wm0-f66.google.com with SMTP id r5so14171977wmr.0 for ; Thu, 16 Jun 2016 13:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dz4wBqIjJjDa4/zAvh9xQaPZaPvEUFAiWXvTh3gd3R8=; b=TqSSkX49jHzWIQp+rhTQrTScwFMLrIFWsnFWxDacBFunaJ9sBhRsZ6F7XHPLQOY2WZ SybO0TugSJeMaQxJUkff0JH8b2sauuwZZiuYH1A+TUK42bQH3LRaTvYZa9uyPlhryn+t lOCv77t23f4bZryNXrd/wj7i2rr6dQe6I4BJAV7BQZuWjyH76znUSptxytohLT8ltm1F q94cEKg5oSge5GRKE8Z1UIn23hCS15hKoiZChbrvy7i0PbRy/Jyq5MTbfXdnmWruAXAH qzR0NkppGVhOBfgRY1kaudBj/ejYqOnLz3Nn/EYEX2UTxW87XjjsPCListZ/H/H4OY4u WSWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dz4wBqIjJjDa4/zAvh9xQaPZaPvEUFAiWXvTh3gd3R8=; b=BWOCuwlix9murX8YloaqYmbRXmLwdB61a3TXMe3aJyQhYVN4TbaHkTOTjUqQaKNSSV UznqmW02pOlHojfAS+Z5LNKIhN0ofaRTHw+1YYVDfQd2PsaW9EZRorFKfX6LPYQDs+gT xkhFTBVh1HI7PhDOpNw25CCZjIhQPMMGy9z6cQP0od+X5skCr7+vRfSX6Dl/MCk4Q8gA xIeWhZrfSw3UpOUBmXpnnv2D9f4ev7YkCmiV/E1YShW1IsiWAMz8YpsBqwCEzBO4x6TX p88ONVG+9gPbbddM4oocEvO3iHI+X+QpcRL/zSQF0oXGNk/rlwR4YANNBSaecekToUf1 tuyg== X-Gm-Message-State: ALyK8tJ3ULSrEDkTSu/7m/uuT83JBFnw3yEXW5jJ48Dni1BHQQEatkvYdvuguprcbCojCtxn0u7tPjxpEK+Z/Q== X-Received: by 10.195.17.138 with SMTP id ge10mr1529775wjd.94.1466110065586; Thu, 16 Jun 2016 13:47:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.25.197 with HTTP; Thu, 16 Jun 2016 13:47:45 -0700 (PDT) In-Reply-To: References: <20160607205454.22576-1-pranit.bauva@gmail.com> <20160615140026.10519-1-pranit.bauva@gmail.com> <20160615140026.10519-6-pranit.bauva@gmail.com> From: Christian Couder Date: Thu, 16 Jun 2016 22:47:45 +0200 Message-ID: Subject: Re: [PATCH v2 5/6] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C To: Pranit Bauva Cc: Eric Sunshine , Git List , Christian Couder , Lars Schneider , =?UTF-8?Q?Torsten_B=C3=B6gershausen?= Content-Type: text/plain; charset=UTF-8 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Jun 16, 2016 at 9:25 PM, Pranit Bauva wrote: > Hey Eric, > > On Fri, Jun 17, 2016 at 12:46 AM, Eric Sunshine wrote: >> On Thu, Jun 16, 2016 at 3:05 PM, Pranit Bauva wrote: >>> On Thu, Jun 16, 2016 at 2:44 AM, Eric Sunshine wrote: >>>> On Wed, Jun 15, 2016 at 10:00 AM, Pranit Bauva wrote: >>>>> Reimplement `is_expected_rev` & `check_expected_revs` shell function in >>>>> C and add a `--check-expected-revs` subcommand to `git bisect--helper` to >>>>> call it from git-bisect.sh . >>>>> [...] >>>>> Signed-off-by: Pranit Bauva >>>>> --- >>>>> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c >>>>> @@ -162,13 +162,44 @@ static int bisect_reset(const char *commit) >>>>> +static int is_expected_rev(const char *expected_hex) >>>>> +{ >>>>> + struct strbuf actual_hex = STRBUF_INIT; >>>>> + int res; >>>>> + >>>>> + if (strbuf_read_file(&actual_hex, git_path_bisect_expected_rev(), 0) < 0) { >>>>> + strbuf_release(&actual_hex); >>>>> + return 0; >>>>> + } >>>>> + >>>>> + strbuf_trim(&actual_hex); >>>>> + res = !strcmp(actual_hex.buf, expected_hex); >>>>> + strbuf_release(&actual_hex); >>>>> + return res; >>>>> +} >>>> >>>> Not worth a re-roll, but this could be re-structured to avoid having >>>> to remember to release the strbuf at all exits: >>>> >>>> struct strbuf actual_hex = ...; >>>> int res = 0; >>>> >>>> if (strbuf_read_file(...) >= 0) { >>>> strbuf_trim(...); >>>> res = !strcmp(...); >>>> } >>>> strbuf_release(...); >>>> return res; >>>> >>>> Alternately: >>>> >>>> if (strbuf_read_file(...) < 0) >>>> goto done; >>>> >>>> strbuf_trim(...); >>>> res = !strcmp(...); >>>> >>>> done: >>>> strbuf_release(...); >>>> return res; >>>> >>>> which is a bit less compact. >>> >>> I will avoid this for the reason that I will have to create a label >>> for a lot of functions. If I choose to do this for one function, I >>> think it would be more appropriate to do the same for other functions. >>> There would be a lot of functions in future which would be in the same >>> scenario and creating a separate label for each of them would be quite >>> tedious. What do you think? >> >> Not sure what you're talking about. Label names are not shared across >> functions. Anyhow, the first suggestion I presented above is more >> concise than the 'goto' version. > > Yes I am aware of the fact that labels aren't shared across functions. > What I meant by "separate label" was that I will have to make a label > "fail" in each function. But I recently noticed that its used quite a > lot so I think it would be okay to use it. Will re-roll with using > labels and goto. My opinion is that if there is a more concise version without labels and gotos, it's better to use it, so I would suggest Eric's first suggestion which is: > struct strbuf actual_hex = ...; > int res = 0; > > if (strbuf_read_file(...) >= 0) { > strbuf_trim(...); > res = !strcmp(...); > } > strbuf_release(...); > return res; Thanks, Christian.