Andrew, That’s actually what got me here. EccCheck runs as part of our CI now (but it didn’t when I wrote these tests a year ago). I need to either figure out how to get this code to pass EccCheck in a reasonable way, or just not contribute the tests and say “go to Mu for the tests, if you want them”. Skipping the contribution isn’t a desirable outcome at all for a number of reasons, not the least of which is that we (MS and others) are trying encourage all contributions to come with tests, so the process of writing them needs to be simple and painless. - Bret From: Andrew Fish Sent: Thursday, September 24, 2020 7:48 PM To: edk2-devel-groups-io; Bret Barkelew Cc: Ken Taylor Subject: [EXTERNAL] Re: [edk2-devel] ECC: Won't somebody PLEASE think of the... test structures. Bret, I’ve had this issue with EFI code too. It will compile with for DEBUG and RELEASE as the optimizer removes the memcpy/memset. So you only see a build failure when you compiler NOOPT (and there are no intrinsic libs). I mostly see this in platform code when I try to compile a single driver/lib NOOPT and it fails to link due to the missing intrinsic. The easy to enforce this is to compile with optimizations enabled and don’t enable intrinsic libs. Not sure if that is really practical from the test point of view. Seems the tool caught the coding style violation so I guess we could try to “make running that tool easier”. Maybe hooking into patchcheck.py, making some kind of githook, or adding a git command? Thanks, Andrew Fish On Sep 24, 2020, at 7:25 PM, Bret Barkelew via groups.io > wrote: So for context, this is a new host-based test that should only run within a platform OS, so intrinsics aren’t the big deal that they would be in FW code. But we do need to figure out how to simultaneously adhere to the coding convention while enabling test authoring. Or we chose to not enforce quite as many things for tests. I’d prefer the first. - Bret From: Ken Taylor Sent: Thursday, September 24, 2020 6:57 PM To: devel@edk2.groups.io; Bret Barkelew Subject: [EXTERNAL] RE: ECC: Won't somebody PLEASE think of the... test structures. If the structure is a non-static local variable, most compilers will silently inject an intrinsic call to memcpy in function initialization. This leads to an intermittent linker error. If the compiler you use automatically supports an intrinsic memcpy in the given architecture or optimizes out the memcpy, it will build for you and you won’t know you need to link to an intrinsic support library in order to build cross platform. This leads to code that builds for you, but not for me. Regards, -Ken. From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bret Barkelew via groups.io Sent: Thursday, September 24, 2020 6:23 PM To: devel@edk2.groups.io Subject: [edk2-devel] ECC: Won't somebody PLEASE think of the... test structures. ERROR - EFI coding style error ERROR - *Error code: 5007 ERROR - *There should be no initialization of a variable as part of its declaration ERROR - *file: //home/corthon/_uefi/edk2_qemu_ci/edk2/MdeModulePkg/Library/VariablePolicyLib/VariablePolicyUnitTest/VariablePolicyUnitTest.c ERROR - *Line number: 333 ERROR - *Variable Name: MatchCheckPolicy EccCheck no likey: SIMPLE_VARIABLE_POLICY_ENTRY ValidationPolicy = { { VARIABLE_POLICY_ENTRY_REVISION, sizeof(VARIABLE_POLICY_ENTRY) + sizeof(TEST_VAR_1_NAME), sizeof(VARIABLE_POLICY_ENTRY), TEST_GUID_1, TEST_POLICY_MIN_SIZE_NULL, TEST_POLICY_MAX_SIZE_NULL, TEST_POLICY_ATTRIBUTES_NULL, TEST_POLICY_ATTRIBUTES_NULL, VARIABLE_POLICY_TYPE_NO_LOCK }, TEST_VAR_1_NAME }; But you can’t init this structure separately without addressing each field. Can a brother get an override? - Bret <95B370A7BEED49AAB797022E8F260C8F.png>