From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 6D4B2941858 for ; Wed, 15 Nov 2023 10:02:28 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=sGywvwooyYvh4U33PMNtmfVbDe6dVvBMOr2pFsIlAE0=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1700042547; v=1; b=VVHjmIy88NLqr8B3JD0wP6AIJpxEB3WkNUPX23Iwh/XWZDqzVwai3G9quemah1i5XSgktc0O i4Gtys6VQq/uSE/8/HOqq87EgzV2xdsCF/dU4jlQZVIhNkQl68vf3PRXbDZ4MvTc7Z5e9r9Cfe1 SQ5Y8a2BDax/wngW9Y12VB/U= X-Received: by 127.0.0.2 with SMTP id 3nd1YY7687511xgAtV1yp2U7; Wed, 15 Nov 2023 02:02:27 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.9921.1700042546515557124 for ; Wed, 15 Nov 2023 02:02:26 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-522-nCUbIJCQPri6z-w_qVTNSw-1; Wed, 15 Nov 2023 05:02:22 -0500 X-MC-Unique: nCUbIJCQPri6z-w_qVTNSw-1 X-Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8E2E13C14767; Wed, 15 Nov 2023 10:02:21 +0000 (UTC) X-Received: from [10.39.192.211] (unknown [10.39.192.211]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 46F9C5028; Wed, 15 Nov 2023 10:02:20 +0000 (UTC) Message-ID: Date: Wed, 15 Nov 2023 11:02:19 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v2 4/5] MdeModulePkg/Bus/Pci/PciBusDxe: Fix NULL_RETURNS Coverity issue To: Ranbir Singh , "Kinney, Michael D" Cc: "devel@edk2.groups.io" , "Andrew Fish (afish@apple.com)" , "quic_llindhol@quicinc.com" , Michael Kubacki , "Ni, Ray" , Veeresh Sangolli References: <20231107061959.113213-1-rsingh@ventanamicro.com> <20231107061959.113213-5-rsingh@ventanamicro.com> <5a7f3c56-d18f-9e4c-0e70-9113923ee36d@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: hB2q4rVjcEfcOz8yY0ZKBcDmx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=VVHjmIy8; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 11/14/23 17:53, Ranbir Singh wrote: > Generally speaking, there now seems to be different views coming from > you and Laszlo. Yes. > We might have to wait for some sort of agreement to be > reached. I don't insist on CpuDeadLoop() *specifically*. Only the following two generic points matter to me: (1) Stop abusing ASSERT (both because it is compiled out of RELEASE builds, and because it is conceptually unsuitable for catching data- and environment-dependent error conditions). ASSERT must only be used for stating (well, "asserting") algorithmic invariants. (2) Upon detecting an algorithmic invariant failure, call *some* API that, at the same time: (2.a) prevents execution from continuing, (2.b) *cannot* be removed from RELEASE builds, (2.c) informs all static analysis tools we use that execution cannot continue past that point. For (2), Mike seems to have an additional requirement: (2.d) make the implementation customizable by the platform, including any information shown to, or logged for, the user (or supervisor software). I have nothing against that additional requirement. My concern is that "perfect" is going to get in the way of "good enough" once again. Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#111248): https://edk2.groups.io/g/devel/message/111248 Mute This Topic: https://groups.io/mt/102438320/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-