AaronBallman wrote: > This functionality only uses the...
Thank you for the explanation, that was really helpful! > The most conservative option is just to refuse to play: if you turn on the > -f... flag and the compiler encounters an indirect call through a function > pointer of T(*)() type, that's an error. You can stop using the flag, or you > can fix your declaration to use the C syntax that hasn't been deprecated > since 1989. I think this is almost defensible but unfortunately there are still some obscure edge cases where functions without prototypes cannot be replaced by a vararg function even though C23 (and C++) allow `void(...)` as a function type. Have you explored this route and decided against it because of user issues? Maybe this experimental feature is fine to use as a forcing function where we don't support ancient idioms with it (e.g., maybe we also say "no implicit function declarations" and "no implicit int" etc for this feature). > When we first encountered this issue, my guess was that concrete cases we'd > most likely see are not in fact code written in K&R C style, but code written > recently by people unclear on the differences between (pre-23) C and C++ and > perhaps unaware that (void) is even a thing--but that's what they actually > meant. So my initial suggestion to @Prabhuk was to just act as if that's what > they'd written, because of all the ways above in which you just can't be sure. That's a reasonable intuition but having worked on the diagnostics for functions without prototypes in C, it turns out that there's a pretty good split between people who write `()` not knowing it doesn't mean `(void)` and people who write `()` expecting K&R C semantics. https://github.com/llvm/llvm-project/pull/210846 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
