Ooooo. Does that mean we get to start on DebugLibEx?

In all seriousness, I’m also in the camp of “can’t we just drop these assertions”?

- Bret
________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Laszlo Ersek via groups.io <lersek=redhat.com@groups.io>
Sent: Wednesday, May 13, 2020 2:16:12 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Vitaly Cheptsov <cheptsov@ispras.ru>
Cc: Andrew Fish <afish@apple.com>; Marvin Häuser <mhaeuser@outlook.de>; liming.gao <liming.gao@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH V4 00/27] Disabling safe string constraint assertions

Hi Mike,

On 05/12/20 20:18, Kinney, Michael D wrote:

> What if there is a
> DebugLib implementation of the DebugLib class that
> does not depend on DebugCommonLib.

There need not be a link failure in this case either, if the DebugLib
instance in question provides the DebugCommonLib API implementations too.

Anyway I don't want to obsess about this. I'm just sad there are zero
acceptable solutions apparently to the 100% valid problem statement that
Vitaly submitted last August, in TianoCore#2054. (Asserting properties
of untrusted external data is *asinine*.) But then, if Vitaly proposes
to update all DebugLib instances one by one, that gets shot down because
"too many DebugLib instances in platforms". And if Vitaly extracts the
common bits so that only the common bits have to be updated, that gets
shot down by "we don't support this kind of dependency, please update
all DebugLib instances instead".

Let's just be honest and call DebugLib frozen forever.

Laszlo