From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 34DAD20988474 for ; Thu, 19 Jul 2018 03:38:25 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7E2AE400E9A3; Thu, 19 Jul 2018 10:38:24 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-95.rdu2.redhat.com [10.10.120.95]) by smtp.corp.redhat.com (Postfix) with ESMTP id 114782156700; Thu, 19 Jul 2018 10:38:21 +0000 (UTC) To: Ard Biesheuvel , "Carsey, Jaben" Cc: edk2-devel-01 , "Ni, Ruiyu" , "Dong, Eric" , "Gao, Liming" , "Wu, Jiaxin" , "Yao, Jiewen" , "Zeng, Star" , "Kinney, Michael D" , "Fu, Siyuan" , "Zhang, Chao B" References: <20180718205043.17574-1-lersek@redhat.com> From: Laszlo Ersek Message-ID: <16c160e8-4f7c-b63a-6f2a-e05aff4f206f@redhat.com> Date: Thu, 19 Jul 2018 12:38:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 19 Jul 2018 10:38:24 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 19 Jul 2018 10:38:24 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH 0/6] UefiLib: centralize OpenFileByDevicePath() and fix its bugs X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 10:38:26 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/19/18 02:07, Ard Biesheuvel wrote: > On 19 July 2018 at 06:15, Carsey, Jaben wrote: >> Reviewed-by: Jaben Carsey >> >> One question (do hold up push). Is there a reason to use the former over the latter? I use latter and I see you use the former. >> >> ASSERT(EFI_ERROR (Status)); >> ASSERT_EFI_ERROR (Status); >> > > The former asserts that an error has occurred, the latter does the opposite. Right -- the latter is actually a misnomer; that macro should have always been called "ASSERT_NO_EFI_ERROR" :) > It seems Laszlo is using this to ensure we don't end up in the error > handling path if no error occurred. Sort of -- the way I put it for myself was, ensure that we don't exit on the error path without returning an error status to the caller. So it's less about control flow, and more about setting (or recognizing) error statuses at all locations that jump to the error path. But I guess that's just both sides of the same coin. :) Thanks Laszlo