From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@protonmail.com header.s=default header.b=uC+vPL++; spf=pass (domain: protonmail.com, ip: 185.70.40.132, mailfrom: vit9696@protonmail.com) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by groups.io with SMTP; Fri, 16 Aug 2019 16:34:12 -0700 Date: Fri, 16 Aug 2019 23:34:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1565998448; bh=s0Meco6+uETGmffkxEggVQSPtAIwV83mSgvvRePOIZs=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=uC+vPL++ftnt99jOk7BDz1SsJZVnSqBSyy5jtWNI/h5+g/0YtuCQgBf1lu5j+nSZS smhmbE3tBJJjylbdwGuwR5B1049j8y+IeBbjQj90T9OP/p8fMgy/vYWLwgeg4Fg388 j5f41uj2LuG/Yo8uPfNqEN0Kx3HUVavxnC3+aymo= To: Andrew Fish From: "Vitaly Cheptsov" Cc: devel@edk2.groups.io, Mike Kinney , "lersek@redhat.com" , "leif.lindholm@linaro.org" Reply-To: "vit9696@protonmail.com" Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro Message-ID: <93F6F587-E3FB-4B5F-AB92-4427071F7E15@protonmail.com> In-Reply-To: <308CCC50-2275-4E0F-B468-464F814C20A4@apple.com> References: <20190813081644.53963-1-vit9696@protonmail.com> <74D8A39837DF1E4DA445A8C0B3885C503F75D776@shsmsx102.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D1378@SHSMSX104.ccr.corp.intel.com> <8e766773-0b4e-e9bd-31a2-a858c7b476c9@redhat.com> <308CCC50-2275-4E0F-B468-464F814C20A4@apple.com> Feedback-ID: p9QuX-L1wMgUm6nrSvNrf8juLupNs0VSnzXGVXuYDxlEahFdWtaedWDMB9zpwGDklGt7kzs1-RBc0cqz327Gcg==:Ext:ProtonMail MIME-Version: 1.0 X-Spam-Status: No, score=-0.7 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT,HTML_FONT_LOW_CONTRAST, HTML_MESSAGE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Groupsio-MsgNum: 45869 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="---------------------8df7762b7d3d529f74f443f754eaf75e"; charset=UTF-8 -----------------------8df7762b7d3d529f74f443f754eaf75e Cc: devel@edk2.groups.io, Mike Kinney , "lersek@redhat.com" , "leif.lindholm@linaro.org" Content-Type: multipart/alternative; boundary="Apple-Mail=_69E30DBD-9296-474D-A72B-AE1EA553E194" Date: Sat, 17 Aug 2019 02:34:01 +0300 From: "vit9696@protonmail.com" In-Reply-To: <308CCC50-2275-4E0F-B468-464F814C20A4@apple.com> Message-Id: <93F6F587-E3FB-4B5F-AB92-4427071F7E15@protonmail.com> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) References: <20190813081644.53963-1-vit9696@protonmail.com> <65C2153C-7D59-490C-8DD2-A48FF0EEA8DE@protonmail.com> <74D8A39837DF1E4DA445A8C0B3885C503F75D776@shsmsx102.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D1378@SHSMSX104.ccr.corp.intel.com> <8e766773-0b4e-e9bd-31a2-a858c7b476c9@redhat.com> <68hLvq8FShystgMUNIiwFcdhiliZekTbWJgr_ZKZ7aM0LP4IJtym3sqpWqr8LL09RQWZhWR1PESzYBuEm4hxDg==@protonmail.internalid> <-oYbCGlXQcvXnnsL2bvwm0_mx-AEeT6WtLeV1BSw1EaJlVhkgz2DJB-HVThO2RqNbGASsqNeIq8Di8yMxklNEw==@protonmail.conversationid> <308CCC50-2275-4E0F-B468-464F814C20A4@apple.com> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro To: Andrew Fish X-Mailer: Apple Mail (2.3445.104.11) --Apple-Mail=_69E30DBD-9296-474D-A72B-AE1EA553E194 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andrew, Mike, Actually thanks for making me recheck it. I have just installed doxygen, a= nd can confirm that it can generate parameters for non-functional macros. T= his was my main reason for going with /// comment style, which is used for = all other plain macros. I have just submitted V3 version with this fixed. With C language modernisation I fully agree that it needs to be done reaso= nably, and that is why I also try to be very realistic on what people actua= lly use. For instance, one of the issues that caused several problems is th= e use of 1-sized arrays instead of flexible array members. A couple years a= go that was still there just because there still existed some compilers tha= t did not support [] syntax. Best wishes, Vitaly > 17 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3., =D0=B2 1:58, Andrew Fish =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 >=20 >=20 >> On Aug 16, 2019, at 2:40 PM, Vitaly Cheptsov via Groups.Io > wrote: >>=20 >> Mike, >>=20 >> I missed your message while writing mine, but I am afraid I disagree wi= th the functional macro usage for this feature. >>=20 >> I explicitly quoted C standard static_assert definition in one of my pr= evious messages, and I want EDK II to be as close to standard C as possible= . >>=20 >> This will avoid a lot of confusion for newcomers and will let us later = adopt a more flexible single and double argument interface when it gets sta= ndardised. >>=20 >> For these reasons altogether, I am not positive the macro could get a d= oxygen documentation as it is not designed to have any arguments in the fir= st place. >>=20 >=20 > Vitaly, >=20 > I don't understand your logic? It is always possible to write a comment = in C code? >=20 > In terms of the C standard and the EFI type system we kind of have a lon= g history of how the code ended up like it is. The (U)EFI spec defined its = own type system (and ABI) as a way of specifying interoperability so the co= de got built on top of that. 20 years ago we shied away from having and EFI= code base produce definitions of standard C things as we wanted to make it= easier to import chunks of code in OS loaders that needed to get ported to= EFI from lots of different vendors. Also one of the early compilers that w= e standardized on was VC2003 and that does not even fully support C99. For = some reason it seems VC2008 was also a popular target for some time. I don'= t think VC++ got around to C99 until 2013/2015. So that is kind how the edk= 2 ended up with its own type system.=20 >=20 > I'm all for modernization of the C code as long we are thoughtful about = compatibility. For example I still see that VS2008 is a supported BaseTools= /Conf/tools_def.template. >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 >> Best wishes, >> Vitaly >>=20 >> On =D1=81=D0=B1, =D0=B0=D0=B2=D0=B3. 17, 2019 at 00:04, Kinney, Michael= D > wrote: >>>=20 >>> Laszlo, >>>=20 >>> I agree that better comments/documentation of STATIC_ASSERT() >>> for EDK II usages is required. For example, EDK II defines >>> the ASSERT() macro which is based on the standard C function >>> assert(), but we still document it fully for EDK II usage. >>>=20 >>> /** >>> Macro that calls DebugAssert() if an expression evaluates to FALSE. >>>=20 >>> If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSERT_EN= ABLED >>> bit of PcdDebugProperyMask is set, then this macro evaluates the Boole= an >>> expression specified by Expression. If Expression evaluates to FALSE, = then >>> DebugAssert() is called passing in the source filename, source line nu= mber, >>> and Expression. >>>=20 >>> @param Expression Boolean expression. >>>=20 >>> **/ >>> #if !defined(MDEPKG_NDEBUG) >>> #define ASSERT(Expression) \ >>> do { \ >>> if (DebugAssertEnabled ()) { \ >>> if (!(Expression)) { \ >>> _ASSERT (Expression); \ >>> ANALYZER_UNREACHABLE (); \ >>> } \ >>> } \ >>> } while (FALSE) >>> #else >>> #define ASSERT(Expression) >>> #endif >>>=20 >>> I would like to see the macro documentation for >>> STATIC_ASSERT() with the Doxygen style description of the >>> parameters. The fact I asked if STATIC_ASSERT() supported >>> the 2nd message parameter should have been a trigger >>> for me to ask for the more complete macro comment block. >>> The fact that this macro can be directly mapped to >>> built in compiler name makes the implementation simple, >>> but other implementations are possible for compilers >>> that do not support this feature directly. This is why >>> the complete description of the EDK II version is required. >>>=20 >>> I would like to see a V3 with the complete description. >>>=20 >>> In general, I agree it is better if there is code that >>> uses a new feature in the code base, so the feature can >>> be tested. A second option we can consider going forward >>> is for unit test code to be submitted with a new feature, >>> so even if there are no consumers from the EDK II repos, >>> the feature can still be tested as the EDK II repos are >>> maintained. A third option is for community members to >>> provide Tested-by responses to the feature along with >>> statements in the Bugzilla that clearly documents how the >>> the feature was tested. >>>=20 >>> Best regards, >>>=20 >>> Mike >>>=20 >>> > -----Original Message----- >>> > From: devel@edk2.groups.io >>> > [mailto:devel@edk2.groups.io ] On Behal= f Of Laszlo Ersek >>> > Sent: Friday, August 16, 2019 12:39 PM >>> > To: vit9696@protonmail.com >>> > Cc: devel@edk2.groups.io ; leif.lindhol= m@linaro.org ; >>> > afish@apple.com >>> > Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add >>> > STATIC_ASSERT macro >>> > >>> > On 08/16/19 19:23, vit9696@protonmail.com wrote: >>> > > Laszlo, >>> > > >>> > > I have already mentioned that the documentation is >>> > sufficient as >>> > > _Static_assert is C standard >>> > >>> > Yes, in a release of the ISO C standard that edk2 does >>> > not target. >>> > >>> > In addition, edk2 already has several restrictions in >>> > place against standards-conformant code. (Such as bit- >>> > shifting of UINT64 values, initialization of structures >>> > with automatic storage duration, structure assignment, >>> > maybe more.) >>> > >>> > > so I do not plan to make a V3 for this patch. >>> > >>> > I find that regrettable. >>> > >>> > > The patch is merge ready. >>> > >>> > Such statements are usually made when people that >>> > comment on a patch arrive at a consensus. The patch may >>> > be merge-ready from your perspective and from Mike's. >>> > It is not merge-ready from my perspective. >>> > I hope I'm allowed to comment (constructively) on >>> > patches that aren't strictly aimed at the subsystems I >>> > co-maintain. >>> > >>> > > As for usage examples I have an opposing opinion to >>> > yours and believe >>> > > it is based on very good reasons. Not using >>> > STATIC_ASSERT in the >>> > > current release will make the feature optionally >>> > available and let >>> > > people test it in their setups. >>> > >>> > Not using STATIC_ASSERT in the current stable release >>> > makes the STATIC_ASSERT macro definition *dead code* in >>> > edk2 proper. I understand that edk2 is a "kit", and >>> > quite explicitly caters to out-of-tree platforms. >>> > That's not a positive trait of edk2 however; it's a >>> > negative one, in my judgement. Whatever we add to the >>> > core of edk2, we should exercise as diligently as we >>> > can *inside* of edk2. >>> > >>> > > In case they notice it does not work for them they >>> > will have 3 months >>> > > grace period to report it to us and consider making a >>> > change. >>> > >>> > That is what the feature freezes are for. The feature >>> > is reviewed before the soft feature freeze, merged (at >>> > the latest) during the soft feature freeze, and bugs >>> > can still be fixed during the hard feature freeze. The >>> > community is expected to test diligently during the >>> > hard feature freeze. >>> > Perhaps we should extend the hard feature freeze. >>> > >>> > My problem is not that the change is not "in your >>> > face". I'm all for avoiding regressions. My problem is >>> > that the code is dead and untestable without platform >>> > changes, even though it could be put to great use in >>> > core code at once. If you think that's too risky, this >>> > close to the stable tag, then one solution is to >>> > resubmit at the beginning of the next development cycle >>> > (again with additional patches that utilize the >>> > STATIC_ASSERT macro at once). Developers will then have >>> > close to three months to report and fix issues. >>> > >>> > Another solution would be to conditionally keep >>> > VERIFY_SIZE_OF, vs. >>> > using STATIC_ASSERT, for expressing the build-time >>> > invariants. The default would be STATIC_ASSERT. Should >>> > it break, people could immediately switch back to >>> > VERIFY_SIZE_OF, without disruption to their workflows. >>> > >>> > We've done similar things in OvmfPkg in the past. For >>> > example: >>> > - USE_LEGACY_ISA_STACK (commit a06810229618 / commit >>> > 562688707145), >>> > - USE_OLD_BDS (commit 79c098b6d25d / commit >>> > dd43486577b3), >>> > - USE_OLD_PCI_HOST (commit 4014885ffdfa / commit >>> > cef83a3050e5). >>> > >>> > > This will also give them 3 months grace period of >>> > VERIFY_SIZE_OF macro >>> > > removal in favour of STATIC_ASSERT. Making the change >>> > now will let >>> > > people do seamless transition to the new feature and >>> > will avoid >>> > > obstacles you are currently trying to create. >>> > >>> > Please stop making claims in bad faith. I'm not trying >>> > to "create obstacles". I'm a fan of STATIC_ASSERT. I'm >>> > not a fan of dead code. >>> > >>> > > Thus STATIC_ASSERT usage and VERIFY_SIZE_OF removal >>> > must both be >>> > > separate patchsets with potentially separate BZs. >>> > > >>> > > Thanks for understanding, >>> > >>> > Why are you presenting this as a done deal? The v2 >>> > patch was submitted three days ago, IIUC. >>> > >>> > Also, I wish we could have this discussion without >>> > condescension. >>> > >>> > Thanks, >>> > Laszlo >>> > >>> >=20 >>>=20 >>=20 >>=20 >>=20 --Apple-Mail=_69E30DBD-9296-474D-A72B-AE1EA553E194 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Andrew, Mike,

Actually thanks for making me r= echeck it. I have just installed doxygen, and can confirm that it can gener= ate parameters for non-functional macros. This was my main reason for going= with /// comment style, which is used for all other plain macros. I have j= ust submitted V3 version with this fixed.

With C language modernisation I fully agree that i= t needs to be done reasonably, and that is why I also try to be very realis= tic on what people actually use. For instance, one of the issues that cause= d several problems is the use of 1-sized arrays instead of flexible array m= embers. A couple years ago that was still there just because there still ex= isted some compilers that did not support [] syntax.
<= br class=3D"">
Best wishes,
Vital= y

17 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3., =D0=B2 1:58, An= drew Fish <afish@apple.com= > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):



On Aug 16, 2019, at 2:40 PM, Vitaly Cheptsov via Groups.Io <= ;vit9696= =3Dprotonmail.com@groups.io> wrote:

Mike,=

I missed your message while writing mine, b= ut I am afraid I disagree with the functional macro usage for this feature.=

I explicitly quoted C standard static_asser= t definition in one of my previous messages, and I want EDK II to be as clo= se to standard C as possible.
=
This will avoi= d a lot of confusion for newcomers and will let us later adopt a more flexi= ble single and double argument interface when it gets standardised.

For these reasons altogether, I am not positive the= macro could get a doxygen documentation as it is not designed to have any = arguments in the first place.
=

Vitaly,=

I don't understand your logic? It is always= possible to write a comment in C code?

In t= erms of the C standard and the EFI type system we kind of have a long histo= ry of how the code ended up like it is. The (U)EFI spec defined its own typ= e system (and ABI) as a way of specifying interoperability so the code got = built on top of that. 20 years ago we shied away from having and EFI code b= ase produce definitions of standard C things as we wanted to make it easier= to import chunks of code in OS loaders that needed to get ported to EFI fr= om lots of different vendors. Also one of the early compilers that we stand= ardized on was VC2003 and that does not even fully support C99. For some re= ason it seems VC2008 was also a popular target for some time. I don't think= VC++ got around to C99 until 2013/2015. So that is kind how the edk2 ended= up with its own type system. 

I'm all= for modernization of the C code as long we are thoughtful about compatibil= ity. For example I still see that VS2008 is a supported BaseTools/Conf= /tools_def.template.

Thanks,

Andrew Fish
<= br class=3D"">

Best wishes,
Vitaly

= On =D1=81=D0=B1, =D0=B0=D0=B2=D0=B3. 17, 2019 at 00:04, Kinney, Michael D &= lt;michael.d.kinney@intel.com> wrote:
Lasz= lo,

I agree that better comments/documentation= of STATIC_ASSERT()
for EDK II usages is required. For exampl= e, EDK II defines
the ASSERT() macro which is based on the st= andard C function
assert(), but we still document it fully fo= r EDK II usage.

/**
Macro that c= alls DebugAssert() if an expression evaluates to FALSE.

If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSE= RT_ENABLED
bit of PcdDebugProperyMask is set, then this macro= evaluates the Boolean
expression specified by Expression. If= Expression evaluates to FALSE, then
DebugAssert() is called = passing in the source filename, source line number,
and Expre= ssion.

@param Expression Boolean expression.
**/
#if !defined(MDEPKG_NDEBUG)#define ASSERT(Expression) \
do { \
if (DebugAssertEnabled ()) { \
if (!(Expression)) { \
_ASSERT (Expression); \
ANALYZER_UNREACHABLE (); \} \
} \
} while (FALSE)
#else
#define ASSERT(Expression)
#endif<= br class=3D"">
I would like to see the macro documentation fo= r
STATIC_ASSERT() with the Doxygen style description of theparameters. The fact I asked if STATIC_ASSERT() supported
the 2nd message parameter should have been a trigger
for me to ask for the more complete macro comment block.
Th= e fact that this macro can be directly mapped to
built in com= piler name makes the implementation simple,
but other impleme= ntations are possible for compilers
that do not support this = feature directly. This is why
the complete description of the= EDK II version is required.

I would like to s= ee a V3 with the complete description.

In gene= ral, I agree it is better if there is code that
uses a new fe= ature in the code base, so the feature can
be tested. A secon= d option we can consider going forward
is for unit test code = to be submitted with a new feature,
so even if there are no c= onsumers from the EDK II repos,
the feature can still be test= ed as the EDK II repos are
maintained. A third option is for = community members to
provide Tested-by responses to the featu= re along with
statements in the Bugzilla that clearly documen= ts how the
the feature was tested.

Best regards,

Mike

> -----Original Message-----
> From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On B= ehalf Of Laszlo Ersek
> Sent: Friday, August 16, 2019 12:3= 9 PM
> To: vit9696@protonmail.= com
> Cc: <= /span>devel@edk2.groups.= io; leif.lindholm@linaro.org;
> afish@apple.com
> Sub= ject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC= _ASSERT macro
>
> On 08/16/19 19:23, vit9696@protonmail.com wrote:
> > Laszlo,
> >
> > I have already mentioned that the = documentation is
> sufficient as
> > _= Static_assert is C standard
>
> Yes, in a= release of the ISO C standard that edk2 does
> not target= .
>
> In addition, edk2 already has sever= al restrictions in
> place against standards-conformant co= de. (Such as bit-
> shifting of UINT64 values, initializat= ion of structures
> with automatic storage duration, struc= ture assignment,
> maybe more.)
>
> > so I do not plan to make a V3 for this patch.
>
> I find that regrettable.
>
> > The patch is merge ready.
>
> Such statements are usually made when people that
>= ; comment on a patch arrive at a consensus. The patch may
>= ; be merge-ready from your perspective and from Mike's.
> = It is not merge-ready from my perspective.
> I hope I'm al= lowed to comment (constructively) on
> patches that aren't= strictly aimed at the subsystems I
> co-maintain.
>
> > As for usage examples I have an opposin= g opinion to
> yours and believe
> > i= t is based on very good reasons. Not using
> STATIC_ASSERT= in the
> > current release will make the feature optio= nally
> available and let
> > people t= est it in their setups.
>
> Not using STA= TIC_ASSERT in the current stable release
> makes the STATI= C_ASSERT macro definition *dead code* in
> edk2 proper. I = understand that edk2 is a "kit", and
> quite explicitly ca= ters to out-of-tree platforms.
> That's not a positive tra= it of edk2 however; it's a
> negative one, in my judgement= . Whatever we add to the
> core of edk2, we should exercis= e as diligently as we
> can *inside* of edk2.
>
> > In case they notice it does not work for the= m they
> will have 3 months
> > grace = period to report it to us and consider making a
> change.<= br class=3D"">>
> That is what the feature freezes are = for. The feature
> is reviewed before the soft feature fre= eze, merged (at
> the latest) during the soft feature free= ze, and bugs
> can still be fixed during the hard feature = freeze. The
> community is expected to test diligently dur= ing the
> hard feature freeze.
> Perhaps = we should extend the hard feature freeze.
>
= > My problem is not that the change is not "in your
> f= ace". I'm all for avoiding regressions. My problem is
> th= at the code is dead and untestable without platform
> chan= ges, even though it could be put to great use in
> core co= de at once. If you think that's too risky, this
> close to= the stable tag, then one solution is to
> resubmit at the= beginning of the next development cycle
> (again with add= itional patches that utilize the
> STATIC_ASSERT macro at = once). Developers will then have
> close to three months t= o report and fix issues.
>
> Another solu= tion would be to conditionally keep
> VERIFY_SIZE_OF, vs.<= br class=3D"">> using STATIC_ASSERT, for expressing the build-time
> invariants. The default would be STATIC_ASSERT. Should
> it break, people could immediately switch back to
> VERIFY_SIZE_OF, without disruption to their workflows.
>
> We've done similar things in OvmfPkg in the past. = For
> example:
> - USE_LEGACY_ISA_STACK (= commit a06810229618 / commit
> 562688707145),
> - USE_OLD_BDS (commit 79c098b6d25d / commit
> dd434= 86577b3),
> - USE_OLD_PCI_HOST (commit 4014885ffdfa / comm= it
> cef83a3050e5).
>
> = > This will also give them 3 months grace period of
> V= ERIFY_SIZE_OF macro
> > removal in favour of STATIC_ASS= ERT. Making the change
> now will let
> &= gt; people do seamless transition to the new feature and
>= will avoid
> > obstacles you are currently trying to c= reate.
>
> Please stop making claims in b= ad faith. I'm not trying
> to "create obstacles". I'm a fa= n of STATIC_ASSERT. I'm
> not a fan of dead code.
>
> > Thus STATIC_ASSERT usage and VERIFY_SIZ= E_OF removal
> must both be
> > separa= te patchsets with potentially separate BZs.
> >
> > Thanks for understanding,
>
> Why are you presenting this as a done deal? The v2
>= patch was submitted three days ago, IIUC.
>
> Also, I wish we could have this discussion without
>= condescension.
>
> Thanks,
> Laszlo
>
> 




--Apple-Mail=_69E30DBD-9296-474D-A72B-AE1EA553E194-- -----------------------8df7762b7d3d529f74f443f754eaf75e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBmBAEBCAAQBQJdVz1qCRBPsoxt7Hy0xQAKCRBPsoxt7Hy0xZ7DCACaKXb6 avEC4uA9Dciob3QmLvkbgoT+rHnNAPZLemFJxLcmvAuW+75kh35n5NdCyAXm Y75B4sETE12zrsk8UfB0o71fWrquQjWPRUF4QQMcqtJgSAiGJz96IQvAzbq7 u66GECIQW5szwKoJnLZiGMtBBDw4d91EEKAdYcbKZVuHB+trfc3FYDS4waDH hMEs6AV6jwWtj4PdedAA7nQv+lYpHOfMCmie4EBHfakAwhfqivV89os8hLvL KZkwp1NM/xWkeK017F4YUawyoo4J5C1u9JL38lHfE9cA/fZGT1+EL0UvQ2tF +m+YAHYbg7gNLBGBbISZAL0akWXd7tCHAcN2 =E2zc -----END PGP SIGNATURE----- -----------------------8df7762b7d3d529f74f443f754eaf75e--