ldionne wrote: > I am concerned that `-fstdlib-hardening=` may not map to libstdc++ preferred > enabling mechanism cleanly. There is a non-zero probability that GCC folks > would not add an option that just passes a `-D...` to cc1. Then this driver > option will feel like a libc++ specific feature using a generic name...
That's fair, I don't necessarily expect that libstdc++ is going to create modes that map to our modes. In that case, I think we should probably do a best effort mapping to the modes that libstdc++ is providing, since that's the best we can do. For example, `fast`, `extensive` and `debug` might all map to the same thing on libstdc++, but that's okay -- we're just allowing the user to express their intent more granularly. IMO, shipping a new feature where macros are the canonical way of controlling that feature is backwards. It provides a poor user experience and it is modules-hostile. I believe our long-term goal should be to provide a flag that users can use to select the level of hardening that they desire, understanding that this is implementation-dependent. We're on the same page that this flag doesn't do anything complicated. I think that's fine. The goal of this flag is to provide a nice and slick interface to hardening, and that is important because we're trying to lower the barrier as much as possible for people to use this feature. I'd even be fine with making this libc++ specific (although we'd drop the possibility of making this something more standardized across implementations), but I think that a compiler flag (as opposed to setting a macro) is really a must have for any serious adoption, so I'm quite attached to it. https://github.com/llvm/llvm-project/pull/78763 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
