r224012 - Emit warning if define or undef reserved identifier or keyword.

Serge Pavlov sepavloff at gmail.com
Fri Dec 12 12:00:33 PST 2014


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 <arthur.j.odwyer at gmail.com>:
>
> 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 <sepavloff at gmail.com> 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 <joerg at britannica.bec.de>:
> >>
> >> 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
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141213/d34547ad/attachment.html>


More information about the cfe-commits mailing list