On Jun 21, 2023, Qing Zhao <qing.z...@oracle.com> wrote: > I see that you have testing case to check the above built_in_trap call > is generated by FE. > Do you have a testing case to check the trap is happening at runtime?
I have written such tests, using type-punning, but I don't think our testing infrastructure could take trapping as success and other results as failure. > So, when -ftrivial-auto-var-init presents, what’s the behavior for the > hardened Boolean auto variables? Good question. This option was not even available when hardbool was designed and implemented. (tests) The deferred_init internal function initializes with bit-patterns 0x00 or 0xfe, regardless of type, when the data lives in memory, and otherwise forces the 0x00 bit pattern for booleans, variable-sized types, types that cannot be accessed with a single mode or for modes that don't have a set pattern. It's hard for me to tell what "correct" or "expected" would be here. Enumerators don't seem to be given special treatment. Checked enumerators, constrained integral subtypes, none of these would get well-formed values or even checking at the assignments. If I were to design this option myself, I'd probably arrange for it to handle booleans (including hardened booleans) by zero-initializing as false and pattern-initializing as true, though I realize that this could be very confusing if one chose to use 0xfe as the value for false and/or 0x00 as the value for true. I'd probably have arranged for the front-end to create the initializer value, because expansion time is too late to figure it out: we may not even have the front-end at hand any more, in case of lto compilation. But with the current description and implementation, I guess the behavior is correct, if not ideal: the bit patterns refer to the representation, rather than to the language interpretation of the value. When it comes ot integral types, they may match, but floating-point, fixed fractional types, offsets and multipliers, even boolean member of larger structs... not so much: the effect is that of a memset, rather than that of an assignment of zero or of the pattern to a variable. Now, I acknowledge that the decision to make implicit zero-initialization of boolean types set them to the value for false, rather than to all-bits-zero representation, is a departure from common practice of zero-initialization yielding logical zero. That was unusual enough that I thought it worth mentioning in the docs. > This might need to be documented and also handled correctly. I suppose the place to document this distinction between logical values and representation would be under -ftrivial-auto-var-init. That's likely where someone using that option would look for guidance on how it interacts with unusual types, and where exceptions to general expectations WRT initialization would go. Do you concur? That said, it probalby makes sense to refer to / mention that -ftrivial-auto-var-init does not special-case hardened booleans in the hardened booleans documentation. I wonder if there are other conflicting options I'm not even aware of. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
