From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c09::22b; helo=mail-wm0-x22b.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8B3FA21E49032 for ; Wed, 14 Mar 2018 05:33:20 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id i194so3737968wmg.1 for ; Wed, 14 Mar 2018 05:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8DGdE3PigBbSTnk3JTM4xSeH/nKSYWY4InAzIKS8ivE=; b=b7KSTchiie9gNGcYqjinng4MO4GTkRZAZAM0QooVQcqL5XcORH3bz/7E62hi2DJozh re4UWrdsKE8UEJmz6U1ytPAvOA+1R3YzGRS5UlCMuQJ8deNqnVVOirRRJLvLl3cHwIq9 r7Qkp3AlvDpjESdK63TZ3cWINWJC/t/m4Lafk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8DGdE3PigBbSTnk3JTM4xSeH/nKSYWY4InAzIKS8ivE=; b=KscUYmpR8kmgURJP04izVbe4TB75pFPsw9YqNH75xtA4CoT9FxOu9+C9qbQiydQuZk H1ujLQFDlySh/Rk3954oDX/b5uHv7MyRBF+x0DZ4zRbZ8mJW25crsKhHml3xfFnmxp+w a+26uUKBRNnbd40GX0JXTYKWm5irtFo0U+MYi3AcRLLiMGr6AZcuQ9ZlP+lB6AroVq3B PoVrWs6chGoO/U687gVv2ORaa7bd6iPtRkz2jk2AwcRjrC8+MLCpXVsjP7Tn+bbblk6I fjSAwQB8NwPqeXqTOHicFOvX4kIcdy/nZzSCLzKJfiLOeFAcDhsYhPKgBjNdw5l2Ydss BgdQ== X-Gm-Message-State: AElRT7HGtp3s/39gHyCkB6oNQtANDB2xYiHun78G211FainNRodDm15S mQBg+VAzrxxUcTvJvuOYUvGYqA== X-Google-Smtp-Source: AG47ELtgydhEB9VLpJQ8oWtxulUfML/RKClM6ar/nkVGXZ5SZf0wFYLXY0b896fkuTvsnuyCIMGy9A== X-Received: by 10.28.245.9 with SMTP id t9mr1670094wmh.33.1521031181979; Wed, 14 Mar 2018 05:39:41 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id w74sm1135264wmd.27.2018.03.14.05.39.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Mar 2018 05:39:41 -0700 (PDT) Date: Wed, 14 Mar 2018 12:39:39 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: Girish Pathak , Evan Lloyd , Matteo Carlini , nd , "edk2-devel@lists.01.org" , Thomas Abraham , Arvind Chauhan Message-ID: <20180314123939.663ooxr53rirogj2@bivouac.eciton.net> References: <20171222190821.12440-1-evan.lloyd@arm.com> <20171222190821.12440-7-evan.lloyd@arm.com> <20180314122415.ohlblcrhzfvn22bl@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg: Add and update debug ASSERTS X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 12:33:21 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Mar 14, 2018 at 12:35:03PM +0000, Ard Biesheuvel wrote: > >> I guess Leif and I are in disagreement here. In particular, I think > >> his comment > >> > >> """ > >> ASSERT (FALSE)? (You already know Status is an EFI_ERROR, and a > >> console message saying ASSERT (Status) is not getting you out of > >> looking at the source code to find out what happened.) > >> """ > >> > >> is misguided, given that ASSERT_EFI_ERROR (Status) will actually print > >> the value of Status to the debug console. > > > > I don't have a strong enough opinion on this that it should be > > listened to if you both agree. > > > > It's just the "if error, then assert if error" that breaks up the > > parsing flow for me. Could it make sense to use ASSERT_RETURN_ERROR > > instead? > > > > So > > if (EFI_ERROR (Status)) { > > ASSERT_RETURN_ERROR (Status); > > } > > > > Do you mean using ASSERT_RETURN_ERROR() rather than ASSERT_EFI_ERROR()? Yes. > That doesn't make sense: the former is for RETURN_STATUS type > variables and the latter for EFI_STATUS Right, of course. Makes the text look nicer though :) Anyway, I'm OK with the original version. Just wish we had a less redundant-looking way to describe this. / Leif