From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.66; helo=nwk-aaemail-lapp01.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 67F042116DA37 for ; Fri, 12 Oct 2018 11:51:00 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9CIlH80023551; Fri, 12 Oct 2018 11:50:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=0eNyAilmTw7CwiSPVcnu5ztI4AbVt2A9oE+n0gjtQJU=; b=p5Ncw9xXyBMsyBnOczJymv884km0GJDDiBgVWrQsNsyJhwxLdWVPVh2iqagtWRmpg+zw N0Oo08EHQjOiz/etP0KOemp/kfPZPiL6KwEtIvxsJsrgIW1AvOeNyFC2NjeiH6nNkqOK L2sSZmPG3El42dFe8zMFw0uDnO37GX4EYc7xFF+ZFSaSDkkFdFxYTntN8h280+/ma9n0 oMn0dVxztwzdifFPxviAPdWbyF+irt9bi+3nRsD8tErDZQd2u//FuvumuR7iS6scC+n6 8uAAngXIEDT6JWdNoC32b0AFxvTYzdK3iNZjzKDmnYIeDalmwe5Be0GcbNhFoC6dDdB3 uQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2mxv09ndju-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Oct 2018 11:50:58 -0700 MIME-version: 1.0 Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PGI00G0Y1OX4080@ma1-mtap-s03.corp.apple.com>; Fri, 12 Oct 2018 11:50:57 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGI004001K5BX00@ma1-mmpp-sz09.apple.com>; Fri, 12 Oct 2018 11:50:57 -0700 (PDT) X-Va-A: X-Va-T-CD: 07a9f7dd315dc6000695a0402a47d12d X-Va-E-CD: bfb2777e4756679b1ba5aaadc995d351 X-Va-R-CD: 6a64947708146bea7411e6a6f5086601 X-Va-CD: 0 X-Va-ID: 1bb453f0-49c4-464c-8b55-d55f63409c8a X-V-A: X-V-T-CD: 13715775cfe6ed78bc954dbcb503dbb2 X-V-E-CD: bfb2777e4756679b1ba5aaadc995d351 X-V-R-CD: 6a64947708146bea7411e6a6f5086601 X-V-CD: 0 X-V-ID: 92ff290d-74c2-4bce-9eea-99e5a46054e2 Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGI001001E0PD00@ma1-mmpp-sz09.apple.com>; Fri, 12 Oct 2018 11:50:57 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-12_13:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp25.corp.apple.com-10000_instance1 Received: from [17.234.241.37] (unknown [17.234.241.37]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PGI00JGV1OUX460@ma1-mmpp-sz09.apple.com>; Fri, 12 Oct 2018 11:50:57 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: <180aa195-2e56-06a6-ef66-747e6c3210f7@redhat.com> Date: Fri, 12 Oct 2018 11:50:39 -0700 Cc: Leif Lindholm , stephano , edk2-devel@lists.01.org Message-id: <8D8324EA-9CE4-4479-B948-56086A6F9ECD@apple.com> References: <20181012132718.mgpg3f42hjulcwfk@bivouac.eciton.net> <180aa195-2e56-06a6-ef66-747e6c3210f7@redhat.com> To: Laszlo Ersek X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-12_13:, , signatures=0 Subject: Re: TianoCore Community Meeting Minutes X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 18:51:00 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Oct 12, 2018, at 9:07 AM, Laszlo Ersek wrote: > > On 10/12/18 15:27, Leif Lindholm wrote: >> On Thu, Oct 11, 2018 at 10:43:57AM -0700, stephano wrote: > >>> Switching to Standard C Types >>> ----------------------------- >>> Both Shawn and Nate mentioned that the current system has been in place for >>> a long time and some people prefer the current setup. I can start an email >>> discussion around this issue specifically if anyone feels strongly that we >>> should be using standard types. >> >> So, I don't think we made it this far down the agenda on the US-EU >> call. >> >> One way would be to simply explicitly permit it, possibly with the >> constraint that every module needs to pick one and stick with it, >> unless people object. >> >> I think we'll want to discuss this in a US-EU call as well. > > I'm playing devil's advocate here -- because, in general, I'm a fan of > sticking with standard C as much as possible --, but I see a big > obstacle in the way. > > That obstacle is "Table 5. Common UEFI Data Types", in the UEFI spec. > Until a good portion of that table is expressed in terms of standard C > types as well (expanding upon the current definitions), possibly in an > edk2-level spec (i.e. not necessarily in the UEFI spec itself), I think > there's no chance to enable standard C types in edk2 *meaningfully*. > > Because, as soon as you have to call a PI or UEFI interface, you'll have > to stick with the PI/UEFI spec types anyway. > Lazlo, Given there is also a C ABI for each supported processor architecture in the UEFI spec it should be possible to define the EFI types in terms of C types. The only potential issue is I'm not sure BOOLEAN maps to bool in all cases? https://github.com/tianocore/edk2/blob/master/MdePkg/Include/X64/ProcessorBind.h#L188 So typedef __int64 UINT64; or typedef long long INT64; becomes: typedef int64_t INT64; Thus we could move the definition of UINT64, INT64, UINT32, INT32, UINT16, INT16, UINT8, INT8, CHAR, and CHAR16 to Base.h and have ProcessorBind.h just define the C standard types for a given architecture. The tricky part is when there are different answers to the question are you using a standard C lib. Basically the definitions in MdePkg/Include/X64/ProcessorBind.h could conflict with stdint.h. Almost seems like you would need a build flag to control if you use stdint.h. I think the bigger question is what problem are we trying to solve? If some one is programming with uint32_t are they going to expect printf(), memcpy(), etc. We solve that problem today StdLib? I guess we only have an option of the full pedantic C lib (I can't remember if StdLib depends on the shell?), or nothing. Are we trying to define a light weight C lib that works in the firmware code? How much of the C lib do we need to make that useful? Thanks, Andrew Fish PS Speaking of printf() != Print() or DEBUG()... I see a lot of people botching Print() in EFI. It would nice if we could get compiler warnings for miss use. You can add printf warnings to any functing in int my_printf (void *my_object, const char *my_format, ...) __attribute__ ((format (printf, 2, 3))); It would be awesome if we could add edk2_print to at least gcc and clang. Given they are open source projects anything is possible. Not sure how this works on VC++? > >>> Using Git Submodules (like we do with OpenSSL) >>> -------------------- >> >> We didn't make it here either. What would we use it _for_? >> I think the openssl case makes a lot of sense, but what else? > > We embed a bunch of other projects (libraries, mainly): > - Oniguruma > - Brotli > - fdt > - LZMA SDK > - ... > > Thanks > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel