| Re: [cdt-dev] False positives with Codan using Avr-gcc toolchain |
Hi Chris,
This actually looks like a bug in Codan.
Expressions of the form
({ <statements> })
are a GCC extension called "statement-expressions" [1]. Their
semantics is that they evaluate to the value of the _expression_
in the last statement (or void if the last statement is not an
_expression_ statement).
('__extension__' is just a GCC builtin that prevents certain
warnings from being issued [2]. CDT treats it as a macro with
an empty expansion.)
It is therefore incorrect to give a "statement has no effect"
warning for the last statement in a statement-_expression_, since
in this case the value of the _expression_ in the statement is
actually used.
Codan already has some logic to avoid giving this warning in
such cases, but it's buggy and some cases like yours slip
through the cracks. I filed a bug for this [3] and will provide
a patch for it soon.
Regards,
Nate
[1] http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
[2] http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=433357
________________________________
> Date: Wed, 23 Apr 2014 23:56:30 +0100
> From: cdabone@xxxxxxxxx
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] False positives with Codan using Avr-gcc toolchain
> _______________________________________________ cdt-dev mailing list>
> Hi,
>
> I've just started developing with Eclipse and the Avr-GCC (WinAVR)
> toolchain and I get a few false positives with codan. They're
> irritating and out of harmony (I like clean code) so I'm trying to
> alleviate them where possible. For those that don't know, one aspect of
> Avr-GCC is a flash memory management library that uses some C
> extensions to move RAM type initialisation into flash (avr/pgmspace.h
> header) and manage it all via a set of macros. One specific macro for
> managing strings (so you can pass info back and forth through a serial
> port etc) is PSTR(s) which expands thus:
>
> # define PSTR(s) (__extension__({static char __c[] PROGMEM = (s); &__c[0];}))
>
> That "&__c[0];" is getting interpretted as a Codan warning "Statement
> has no effect {0}" when it's actually the return value of the PSTR
> macro (why not just regular macros? why have __extension__ in there? If
> it needs to be a function, be a useful function and return the pointer
> it's generating)
>
> I'd like to supress it either by fixing the avr toolchain (beyond me
> today) or supress the error in this instance (add an exception to
> codan's generation of this message).
>
> So 1) does codan unwrap macros before evaluating exceptions?
>
> I'd like to add an exception to the error that filters out the
> _expression_: "(__extension({*}))" or should I filter "PSTR(*)"?
>
> I'm new to the "__extension__" keyword, so I'm not entirely sure how
> that's evaluated in avr-gcc (and if someone says lmgtfy I'll slap them,
> because if it was that simple, i wouldn't be here asking the question)
> - the manual's a little thin in that regard
>
> in anticipation
>
> Chris
>
> cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev