From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (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 2642821CF1D13 for ; Tue, 13 Feb 2018 09:49:39 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 595434084FEF; Tue, 13 Feb 2018 17:55:29 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-17.rdu2.redhat.com [10.10.120.17]) by smtp.corp.redhat.com (Postfix) with ESMTP id F08F621411B6; Tue, 13 Feb 2018 17:55:27 +0000 (UTC) To: Andrew Fish , Bret Barkelew Cc: Mike Kinney , Sean Brogan , "edk2-devel@lists.01.org" , "Gao, Liming" References: <20171219193625.16060-1-michael.d.kinney@intel.com> <656eb64b-3265-f021-ff4f-df2ed6b7c752@redhat.com> <868954f3-f368-073c-9e62-d11440e719c9@redhat.com> <20838843-EB3C-4EA1-8D05-65AF847FB642@apple.com> From: Laszlo Ersek Message-ID: Date: Tue, 13 Feb 2018 18:55:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20838843-EB3C-4EA1-8D05-65AF847FB642@apple.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Tue, 13 Feb 2018 17:55:29 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Tue, 13 Feb 2018 17:55:29 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [Patch] MdePkg/BaseSafeIntLib: Add SafeIntLib class and instance X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 17:49:39 -0000 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit On 02/13/18 18:15, Andrew Fish wrote: > > >> On Feb 13, 2018, at 8:56 AM, Bret Barkelew >> > wrote: >> >> In response to the original question, I would content that our goal >> should be "a". We should be allowing universal detection of errors >> without the caller having to carry this detection code itself. >> >> The analog would be the safe string functions: if a buffer overflow >> occurs, they don't find a way to "fix" the operation, but they >> faithfully report an error. >> >> As such, I believe from my review that these functions work as intended. >> > > Bret, > > I think Lazlo's point is that undefined behavior[1]  can cause the math > function to break in the future and that we have to be very pedantic in > how it is coded. That's *exactly* my point, yes. > Per the C standard it is legal for the compiler to > optimized away undefined behavior[2], and clang is very aggressive about > warning on undefined behavior and then updating the optimizer to remove > the code in a future release. Thank you for the independent confirmation :) (I'm reading and answering your email after sending my previous one.) > For example the BaseTool compression code > broke with Xcode 9 recently due to the presence of an illegal 32-bit > shift that was only hit when the optimizer inlined the function. While > the compiler tries to emit warnings, or at least traps, for undefined > behavior what we have seen with the Link Time Optimization is the code > can just get removed. Huge kudos for this example! > > [1] - Kind of clangs point of view on undefined behavior in > C: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html > [2] - Example of undefined behavior in clang that emits a trap. > Dereferencing NULL is undefined behavior in C so clang emits a trap, and > optimizes way the code after the trap.  > > ~/work/Compiler>cat undefined.c > > int > main () > { >   int *Yikes = 0; > >   *Yikes = 1; >   return 0; > } > > ~/work/Compiler>clang -S -Os undefined.c > ~/work/Compiler>cat undefined.S > .section__TEXT,__text,regular,pure_instructions > .macosx_version_min 10, 12 > .globl_main > _main:                                  ## @main > .cfi_startproc > ## BB#0: > pushq%rbp > Lcfi0: > .cfi_def_cfa_offset 16 > Lcfi1: > .cfi_offset %rbp, -16 > movq%rsp, %rbp > Lcfi2: > .cfi_def_cfa_register %rbp > ud2 > .cfi_endproc > > > .subsections_via_symbols and for this one. Thank you! Laszlo