[PATCH] D123955: [C2x] Disallow functions without prototypes/functions with identifier lists

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Apr 20 09:09:57 PDT 2022


aaron.ballman marked 2 inline comments as done.
aaron.ballman added inline comments.


================
Comment at: clang/lib/Parse/ParseDecl.cpp:6667
+    // have an identifier list.
+    HasProto = ParamInfo.size() || getLangOpts().requiresStrictPrototypes() ||
+               getLangOpts().OpenCL;
----------------
aaron.ballman wrote:
> rsmith wrote:
> > Hm, so `-fstrict-prototypes` causes us to treat `void f()` as `void f(void)`? That's not normally how our `-fstrict-` flags work: normally they mean "strictly enforce this language rule, even though that may result in programs having UB that we could define away with a more permissive rule". (For example, `-fstrict-aliasing`, `-fstrict-float-cast-overflow`, `-fstrict-enums`, `-fstrict-overflow`, `-fstrict-vtable-pointers`, `-fstrict-return` all work like that.) I wonder if a different flag name would work better, eg `-fno-unprototyped-functions`. Is `-fstrict-prototypes` a GCC flag that we're trying to be compatible with, or our own invention?
> > 
> > If you can't find a better name, I'm not dead set against the current one, but it does seem a little inconsistent.
> > Hm, so -fstrict-prototypes causes us to treat void f() as void f(void)?
> 
> Yup, the idea is that it is strictly enforcing that all functions have a prototype.
> 
> >  Is -fstrict-prototypes a GCC flag that we're trying to be compatible with, or our own invention?
> 
> It's our invention, and I'm not strongly tied to the name. It's the one that came up during the RFC and I suspect it's influenced by the name of the warning group `-Wstrict-prototypes`.
> 
> I think `-fno-` would be a bit of a weird way to spell the flag as that usually disables something rather than enables it. I'll switch to `-fforce-prototypes` because that's basically what this does. WDYT?
After a bunch of off-list discussion with @tahonermann and @erichkeane, we landed on `-fno-knr-functions` as the proposed new name for the flag.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123955/new/

https://reviews.llvm.org/D123955



More information about the cfe-commits mailing list