public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Sean" <sean.brogan@microsoft.com>
To: Liran Alon <liran.alon@oracle.com>,devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH] OvmfPkg/PvScsiDxe: Fix VS2019 build error because of implicit cast
Date: Tue, 31 Mar 2020 15:54:27 -0700	[thread overview]
Message-ID: <7506.1585695267608228111@groups.io> (raw)
In-Reply-To: <30a57406-0c09-043f-6b19-7e6e94afcb44@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

I agree that safeintlib is not doing anything too interesting in this case but that's not really the point.  The argument for it is that it becomes the central point of code to check for safe conversions and an indicator that the developer was thoughtful about this conversion and didn't just cast to avoid the compiler complaining.  If everyone starts putting their own checks in place it leads to more code reviews, diversity in solutions, and opportunities for bugs.  All that said those are soft reasons for the change and that is up to you.

@Laszlo - On the ASSERT part, I have a different view point and am more curious about yours.  For release builds, I don't want to see CpuDeadLoops anywhere unless I am ok with the device being returned/refunded.  Our error path would be to exit the function with an error code and potentially log a ReportStatusCode.   I don't think you should continue in an invalid state as that just makes resolving the bug much much harder.    Given that the system can boot to at least a menu without this driver, it seems that failing out of the function would provide a better "RELEASE" experience.

Finally, given that this is contained in OVMF I am fine with whatever makes the most sense for your platform and usecase.

Thanks
Sean

[-- Attachment #2: Type: text/html, Size: 1372 bytes --]

  reply	other threads:[~2020-03-31 22:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31 11:04 [PATCH] OvmfPkg/PvScsiDxe: Fix VS2019 build error because of implicit cast Liran Alon
2020-03-31 15:53 ` [edk2-devel] " Sean
2020-03-31 21:56   ` Laszlo Ersek
2020-03-31 22:13     ` Liran Alon
2020-03-31 22:17       ` Liran Alon
2020-03-31 22:54         ` Sean [this message]
2020-04-01 11:02           ` Laszlo Ersek
2020-04-01  8:36         ` Laszlo Ersek
2020-04-01  8:50           ` Ard Biesheuvel
2020-04-01 11:47             ` Laszlo Ersek
2020-04-01  8:22       ` Laszlo Ersek
2020-04-01 14:46 ` Laszlo Ersek

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-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7506.1585695267608228111@groups.io \
    --to=devel@edk2.groups.io \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox