From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Mon, 01 Jul 2019 04:11:20 -0700 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BA79130832DA; Mon, 1 Jul 2019 11:11:14 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.36.118.14]) by smtp.corp.redhat.com (Postfix) with ESMTP id B421C1001B21; Mon, 1 Jul 2019 11:11:11 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 0/3] MdePkg/BaseLib: Base64Decode: Make it follow its specification From: "Laszlo Ersek" To: devel@edk2.groups.io, zhichao.gao@intel.com Cc: Michael D Kinney , Liming Gao , Marvin Hauser References: <20190628035746.24160-1-zhichao.gao@intel.com> Message-ID: Date: Mon, 1 Jul 2019 13:11:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Mon, 01 Jul 2019 11:11:19 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/01/19 13:02, Laszlo Ersek wrote: > On 06/28/19 05:57, Gao, Zhichao wrote: > (2a) SourceLength has nothing to do with Destination. The comment should > be updated -- making sure that (Source + SourceLength) do not overflow > MAX_ADDRESS is worthwhile, but the comment is misleading. Let me re-state that. Usually, when you expect the caller to provide an array of bytes, identified by base address and size, the burden to provide an *actual array* is on the caller. If the caller does not conform to the function specification, the behavior is undefined, and it's on the caller. Therefore, checking MAX_ADDRESS overflows is *generally* dubious, in my opinion, because a valid array can never overflow MAX_ADDRESS. If we want to be paranoid about this, I guess we can keep implement MAX_ADDRESS checks, but then we should both document and implement them correctly. Second, it is usually good to specify whether overlap between input and output is permitted. If we want to be paranoid, we can check that explicitly again. I don't necessarily suggest that we implement an overlap check, but we should likely specify in the leading comment that overlap is not permitted. (This is similar to the "restrict" keyword from C99.) Thanks Laszlo