[cfe-dev] Is it possible to avoid FP when there is #ifdef in the code

[John Sully via cfe-dev]

Windows.h defines UNREFERENCED_PARAMETER() for this purpose.  When I'm not
working with code that includes that header I define it as:
 UNREFERENCED_PARAMETER(P) (void)(P)

Unfortunately I couldn't use the same definition as was used in windows.h
with clang without triggering another warning.

On Wed, Aug 26, 2015 at 11:37 PM, Daniel Marjamäki <cfe-dev at lists.llvm.org>
wrote:

>
> Hello!
>
> > I don't think it's fair to call this a false positive, unless the "XYZ"
> macro is defined.
>
> I also agree it is not fair to call this a false positive. But technically
> it is a false positive. You and I can see that the variable is used.
>
> Well.. I had not much hope it would be possible. But asked anyway.
>
> Adding a redundant (void)x should be ok.
>
> Thanks!
> Daniel Marjamäki
>
>
> ..................................................................................................................
> Daniel Marjamäki Senior Engineer
> Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden
>
> Mobile:                 +46 (0)709 12 42 62
> E-mail:                 Daniel.Marjamaki at evidente.se
>
> www.evidente.se
>
> ________________________________________
> Från: Gábor Horváth [xazax.hun at gmail.com]
> Skickat: den 27 augusti 2015 02:12
> Till: Vedant Kumar
> Kopia: Daniel Marjamäki; cfe-dev at lists.llvm.org
> Ämne: Re: [cfe-dev] Is it possible to avoid FP when there is #ifdef in the
> code
>
> On 26 August 2015 at 17:04, Vedant Kumar via cfe-dev <
> cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
> I don't think it's fair to call this a false positive, unless the "XYZ"
> macro is defined.
>
> The analyzer has to run the preprocessor to handle basic things like
> #include. Modifying the checker to do what you propose would require going
> from the AST -> source code, scanning for a preprocessor command, altering
> it, re-parsing it, re-running the checker etc.
>
> It would be easier to add a line like "(void) x;" to suppress the warning.
>
> Other possible workarounds (in case you have several unused variables):
> - You can use pragmas to disable some diagnostics for certain regions of
> code.
> - You can use compiler flags to disable some diagnostics for certain
> translation units.
> - You can always factor out platform dependent code to multiple files and
> have the #ifdef on includes.
>
> In general I do like that the compiler finds unused variables. Sometimes
> this uncovers real bugs. Sometimes it just helps to maintain readable code.
> IMHO it is better to have false positives than false negatives for this
> warning.
>
>
> best
> vedant
>
> On Aug 26, 2015, at 1:35 AM, Daniel Marjamäki via cfe-dev <
> cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
>
> >
> > Hello!
> >
> > Sometimes there are false positives when #ifdef is used and for instance
> usage of some macro/parameter is hidden.
> >
> > I am running Clang in a project where we get several such FPs.
> >
> > Example code:
> >
> > void f(int x) {
> >    // ..code..
> > #ifdef XYZ
> >    dostuff(x);
> > #endif
> >    // ..code..
> > }
> >
> > Warning:
> > 1.c:1:12: warning: unused parameter 'x' [-Wunused-parameter]
> > void f(int x) {
> >           ^
> >
> >
> > Is there anything that can be done in the unused-parameter checker to
> prevent such FP?
> >
> > For instance.. is it possible to see if there was a #ifdef in a function
> and disable the warning in that function.
> >
> > Best regards,
> > Daniel Marjamäki
> >
> >
> >
> ..................................................................................................................
> > Daniel Marjamäki Senior Engineer
> > Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden
> >
> > Mobile:                 +46 (0)709 12 42 62
> <tel:%2B46%20%280%29709%2012%2042%2062>
> > E-mail:                 Daniel.Marjamaki at evidente.se<mailto:
> Daniel.Marjamaki at evidente.se>
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.evidente.se&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=nRkKAYlatRp-Wgk-tAtmRg&m=PTXeK_fIRD2j8WdXUJM6t1ZgnTJCl_jei39eezo4pTA&s=KIaa8a7W1uU-ujhcrdhwjwrMYKCcDD71x-77CQL5wKs&e=
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=nRkKAYlatRp-Wgk-tAtmRg&m=PTXeK_fIRD2j8WdXUJM6t1ZgnTJCl_jei39eezo4pTA&s=yZgb9XCd-JGQ_HwN0wTip7nQwkawracR5TZckpNTNmU&e=
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150826/ecc24b3a/attachment.html>