From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=b9dtmDOb; spf=pass (domain: linaro.org, ip: 209.85.221.65, mailfrom: leif.lindholm@linaro.org) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by groups.io with SMTP; Wed, 18 Sep 2019 09:16:19 -0700 Received: by mail-wr1-f65.google.com with SMTP id r5so9179wrm.12 for ; Wed, 18 Sep 2019 09:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fHCss4c2egZAMOzc8qVHVU7pWQy3XpnXRwvSy7Ko0G0=; b=b9dtmDOb+zkdXO0pXFZ9+rRoUJgbaJj7edjNndeCvJJFRnR+a8DsllhJS0PDJFd3mq 2MLkXd0b+lCSOOqd+u82cIQrzPKbFPoQWOuHXq+Yxq6zILGcAgXmGML7QLdDLUrsI8EB 6Pek7zXLL/8a0OsG6JJZAlfZO1+BvSNcGdEjyzmkKgf9M2xKU1RCQkD/K4SNItUgMDei aosIMixnL/nqbO3VHvhONfZ7vF9kY3r8t/yW2BpV92kVUhbKtqaNgVO4Gu8aCvIGYH59 ivBZehHedYGecQG40UwlQTAAvf9cLtDLnRJ2SKYthZWeNb4CtyN1ymtIuX/sQQIPcJMn mrxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=fHCss4c2egZAMOzc8qVHVU7pWQy3XpnXRwvSy7Ko0G0=; b=uP1hFMQf6BlJ0ekund+lReeMz7bkHqN9cYSMRF++CEwnnfGeHVn7JpWWEdAcClC4FH n8+jv1nXw+cjwEP0XIc+OBzIrqJzp4g4Vkpcq83PGIHjlOC9E32dQaQOOdP6qFs6w9HV vCVbthqKZcBpGgBP5bqlxw7pI5G5DiD7uONHIn5muYiOIldnzjavoK4sg0Gt2bXo3vXC reqeezbQVdebfMz0RmoOISLZbvPhORXekGfYTosw8cGdPZUxPX8TCSjwN+Uqh1hpHfc+ /q+enaoYSxObDz88rtsrFXF8zLqyasUrOaryRNLgr403tTYRy4eOkXPECs7MFqRB06g6 36Kw== X-Gm-Message-State: APjAAAUjEI99KPQbKx3YQUgXXAqfggweBAfnTrG8S4+ljmCEaf9f06iJ BvsoYeSfD5JenCr9ZaS9rW2dQxjmyJ0= X-Google-Smtp-Source: APXvYqyqtUob/MmUuIGBF890+vv2uyK9IScm5djuv1SW+zkSxYSU0Ge2JjuPr6XWGZ9I4EXSz0VO0w== X-Received: by 2002:adf:e48a:: with SMTP id i10mr3677977wrm.311.1568823377389; Wed, 18 Sep 2019 09:16:17 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id m16sm2127710wml.11.2019.09.18.09.16.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Sep 2019 09:16:16 -0700 (PDT) Date: Wed, 18 Sep 2019 17:16:14 +0100 From: "Leif Lindholm" To: devel@edk2.groups.io, afish@apple.com Cc: lersek@redhat.com, "Ni, Ray" , Achin Gupta , Anthony Perard , Ard Biesheuvel , "You, Benjamin" , "Zhang, Chao B" , "Bi, Dandan" , David Woodhouse , "Dong, Eric" , "Dong, Guo" , "Wu, Hao A" , "Carsey, Jaben" , "Wang, Jian J" , "Wu, Jiaxin" , "Yao, Jiewen" , Jordan Justen , Julien Grall , "Gao, Liming" , "Ma, Maurice" , Mike Kinney , "Fu, Siyuan" , Supreeth Venkatesh , "Gao, Zhichao" Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID Message-ID: <20190918161614.GE28454@bivouac.eciton.net> References: <20190917194935.24322-1-lersek@redhat.com> <20190917194935.24322-2-lersek@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C2E3BE1@SHSMSX104.ccr.corp.intel.com> <1FFFA19B-454C-4B46-9DD0-339BB8011838@apple.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Sep 18, 2019 at 08:55:42AM -0700, Andrew Fish via Groups.Io wrote: > >> #ifndef STRICTER_UEFI_TYPES > >> typedef VOID *EFI_PEI_FV_HANDLE; > >> #else > >> struct EFI_PEI_FV_OBJECT; > >> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE; > >> #endif > > > > Technically, this would work well. > > > > However, if we wanted to allow new projects to #define > > STRICTER_UEFI_TYPES as their normal mode of operation (and not just for > > a sanity check in CI), then we'd have to update the UEFI spec too. > > > > Otherwise, code that is technically spec-conformant (albeit semantically > > nonsensical), like I mentioned up-thread, would no longer compile: > > I think helping people NOT write nonsensical code is good. It is > very good idea and I'd like to add it to the spec but as you point > out it would break a lot of existing code so I'm not sure it is > possible. I guess we could try to add a strict mode to the spec but > given the types are defined in tables that may be problematic. I think adding a strict mode to the specification should be doable - an important aspect is that this should[1] only break *builds* of existing code, never the execution of existing applications/drivers on firmware built to the strict mode. (Unless I'm missing something obvious.) [1] It is always possible *some* toolchain does something weird that is already wrong but not visible, and this change would expose the underlying fault. This is not necessarily bad. The specification could then describe the problematic types within #ifdef starements. Best Regards, Leif > We have coding standards that are more strict than what the C spec > allows. So I would see the STRICT_UEFI_TYPES as more of a enforce > the coding standard kind of thing? > > Thanks, > > Andrew Fish > > > EFI_HANDLE Foobar; > > UINT64 Val; > > > > Foobar = &Val; > > > > Thanks > > Laszlo > > > > > > > >