From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lersek@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 (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 9C5611A1EEE
 for <edk2-devel@ml01.01.org>; Wed,  5 Oct 2016 14:25:08 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
 (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id 262AA680E5;
 Wed,  5 Oct 2016 21:25:08 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-104.phx2.redhat.com
 [10.3.116.104])
 by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 u95LP5J7032462; Wed, 5 Oct 2016 17:25:06 -0400
To: "Carsey, Jaben" <jaben.carsey@intel.com>, Andrew Fish <afish@apple.com>,
 Daniil Egranov <daniil.egranov@arm.com>
References: <VI1PR0802MB2624250A5104FB1507DE9D5980C50@VI1PR0802MB2624.eurprd08.prod.outlook.com>
 <CB6E33457884FA40993F35157061515C54A83D0A@FMSMSX103.amr.corp.intel.com>
 <CS1PR84MB02296692A81E42EAC23D4B24D4C40@CS1PR84MB0229.NAMPRD84.PROD.OUTLOOK.COM>
 <e74e37f9-50ad-fbda-33db-28b79d6aae30@arm.com>
 <93F01BC9-4B02-467E-B900-65C6775BB0F3@apple.com>
 <6ac805ec-66c2-a291-7852-3429efa018cd@arm.com>
 <9F98A80B-A3F4-4956-9D84-33C166384EB6@apple.com>
 <CB6E33457884FA40993F35157061515C54A843F0@FMSMSX103.amr.corp.intel.com>
Cc: edk2-devel-01 <edk2-devel@ml01.01.org>,
 Leif Lindholm <Leif.Lindholm@arm.com>
From: Laszlo Ersek <lersek@redhat.com>
Message-ID: <83e81892-7359-e998-1e61-154af3013269@redhat.com>
Date: Wed, 5 Oct 2016 23:25:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CB6E33457884FA40993F35157061515C54A843F0@FMSMSX103.amr.corp.intel.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.5.110.38]); Wed, 05 Oct 2016 21:25:08 +0000 (UTC)
Subject: Re: Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform
X-BeenThere: edk2-devel@lists.01.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: EDK II Development  <edk2-devel.lists.01.org>
List-Unsubscribe: <https://lists.01.org/mailman/options/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=unsubscribe>
List-Archive: <http://lists.01.org/pipermail/edk2-devel/>
List-Post: <mailto:edk2-devel@lists.01.org>
List-Help: <mailto:edk2-devel-request@lists.01.org?subject=help>
List-Subscribe: <https://lists.01.org/mailman/listinfo/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 21:25:08 -0000
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 10/05/16 23:15, Carsey, Jaben wrote:
> All,
> What are your thoughts about Tapan's suggestion to move the protocol location to the only function that needs it?

As I wrote elsewhere in the thread, that will eliminate the assert, but
it will break ShellOpenFileByName() for good (under the same
circumstances where the assert is triggered now).

Is a non-functional ShellOpenFileByName() acceptable, if the platform
doesn't provide the collation protocol? In other words, is it okay to
fail to open any file by name just because we can't compare the filename
against NULL because the collation protocol is missing?

Thanks
Laszlo