Sounds reasonable. Probably we should warn on this construct (it is suspicious and may be a mistype) but it looks like such warning may be safely turned off by default.
Warning on redefinition of 'inline' looks useful, redefining it is indeed prety often. For instance, PHP sources it and I know a real case when linker complains confused developers. BTW Microsoft C complains on keyword redefinition including 'inline'. Thanks, --Serge 2014-12-13 1:46 GMT+06:00 Arthur O'Dwyer <[email protected]>: > > Serge: I think Joerg was suggesting that > > #define foo foo > > should never warn (even when "foo" is a keyword or reserved > identifier), because it is pretty much a no-op. > Whether "foo" is identical to "inline" makes no difference; what > matters is that it's being #define'd to itself. > > –Arthur > > > On Fri, Dec 12, 2014 at 9:10 AM, Serge Pavlov <[email protected]> wrote: > > Probably, on the other hand the pattern '#define inline' often make > > troubles, - code with inline functions starts producing link errors when > > 'inline is removed by such define. > > > > Are there objection to excluding the pattern '#define inline' to this > > warning? It would require different -W flag. > > > > Thanks, > > --Serge > > > > 2014-12-12 21:02 GMT+06:00 Joerg Sonnenberger <[email protected]>: > >> > >> On Fri, Dec 12, 2014 at 04:48:40PM +0600, Serge Pavlov wrote: > >> > Thank you for feedback. > >> > > >> > I removed warning on #undef keyword, and changed wording in r224100. > >> > >> Similar, it should not warning about #define inline inline, which is > >> also a very common pattern. > >> > >> Joerg > > > > > > _______________________________________________ > > cfe-commits mailing list > > [email protected] > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
