On 08/16/19 19:23, vit9...@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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45850): https://edk2.groups.io/g/devel/message/45850 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
