Does anybody have any control statements that will take care of some info 
and warning statements Lint gives when processing CrossWorks code?  For 
example, the statement

if((P4IN & RESET) != RESET)

will cause PC-lint to give messages like:

Info 778 Constant expression evaluates to 0 in operation '&'
Info 774 Boolean within 'if' always evaluates to True

It is caused by one of the compiler include files that says:

#define P4IN_     (0x001C)  /* Port 4 Input */
const sfrb P4IN     = P4IN_;

I tried telling lint that "sfrb" really means an unsigned character
with the 
statement

-d"sfrb=unsigned char"

But then Lint thinks sfrb is a constant and thus generates the info 
messages.

Does anybody else use PC-lint with the CrossWorks compiler and know a way to 
suppress those kind of messages?  I have tried -esym(778, P4IN) but that has 
no effect.

Lou

Have you tried -d"sfrb=volatile unsigned char" ? The volatile
keyword 
should, in theory, tell PC Lint that this isn't a constant.

    -- Anders

Lou C wrote:

>Does anybody have any control statements that will
take care of some info 
>and warning statements Lint gives when processing CrossWorks code?  For 
>example, the statement
>
>if((P4IN & RESET) != RESET)
>
>will cause PC-lint to give messages like:
>
>Info 778 Constant expression evaluates to 0 in operation '&'
>Info 774 Boolean within 'if' always evaluates to True
>
>It is caused by one of the compiler include files that says:
>
>#define P4IN_     (0x001C)  /* Port 4 Input */
>const sfrb P4IN     = P4IN_;
>
>I tried telling lint that "sfrb" really means an unsigned
character with the 
>statement
>
>-d"sfrb=unsigned char"
>
>But then Lint thinks sfrb is a constant and thus generates the info 
>messages.
>  
>

-- 
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Try this, append a lint comment.

if((P4IN & RESET) != RESET) 	/*lint !e778 !e774*/


Stefan

-----Ursprgliche Nachricht-----
Von: msp430@msp4... [mailto:msp430@msp4...]Im Auftrag
von Lou C
Gesendet am: Dienstag, 7. Juni 2005 18:38
An: msp430@msp4...
Betreff: [msp430] PC-Lint with CrossWorks

Does anybody have any control statements that will take care of some info 
and warning statements Lint gives when processing CrossWorks code?  For 
example, the statement

if((P4IN & RESET) != RESET)

will cause PC-lint to give messages like:

Info 778 Constant expression evaluates to 0 in operation '&'
Info 774 Boolean within 'if' always evaluates to True

It is caused by one of the compiler include files that says:

#define P4IN_     (0x001C)  /* Port 4 Input */
const sfrb P4IN     = P4IN_;

I tried telling lint that "sfrb" really means an unsigned character
with the 
statement

-d"sfrb=unsigned char"

But then Lint thinks sfrb is a constant and thus generates the info 
messages.

Does anybody else use PC-lint with the CrossWorks compiler and know a way to 
suppress those kind of messages?  I have tried -esym(778, P4IN) but that has 
no effect.

Lou




.

 
Yahoo! Groups Links



 

Thanks Anders, that did the trick!  Apparently, the volatile keyword must 
override the const keyword since the combination of the two does not make 
sense.

Lou

>
>Have you tried -d"sfrb=volatile unsigned char" ? The volatile
keyword
>should, in theory, tell PC Lint that this isn't a constant.
>
>     -- Anders
>
>Lou C wrote:
>
> >Does anybody have any control statements that will take care of some
info
> >and warning statements Lint gives when processing CrossWorks code?  For
> >example, the statement
> >
> >if((P4IN & RESET) != RESET)
> >
> >will cause PC-lint to give messages like:
> >
> >Info 778 Constant expression evaluates to 0 in operation
'&'
> >Info 774 Boolean within 'if' always evaluates to True
> >
> >It is caused by one of the compiler include files that says:
> >
> >#define P4IN_     (0x001C)  /* Port 4 Input */
> >const sfrb P4IN     = P4IN_;
> >
> >I tried telling lint that "sfrb" really means an unsigned
character with 
>the
> >statement
> >
> >-d"sfrb=unsigned char"
> >
> >But then Lint thinks sfrb is a constant and thus generates the info
> >messages.

>Try this, append a lint comment.
>
>if((P4IN & RESET) != RESET) 	/*lint !e778 !e774*/

I tried that with no success.  I tried what Anders suggested and it seems to 
work well (see his posting).  Thanks for the response.

Lou

>Does anybody have any control statements that will
take care of some info
>and warning statements Lint gives when processing CrossWorks code?  For
>example, the statement
>
>if((P4IN & RESET) != RESET)
>
>will cause PC-lint to give messages like:
>
>Info 778 Constant expression evaluates to 0 in operation '&'
>Info 774 Boolean within 'if' always evaluates to True
>
>It is caused by one of the compiler include files that says:
>
>#define P4IN_     (0x001C)  /* Port 4 Input */
>const sfrb P4IN     = P4IN_;
>
>I tried telling lint that "sfrb" really means an unsigned
character with 
>the
>statement
>
>-d"sfrb=unsigned char"
>
>But then Lint thinks sfrb is a constant and thus generates the info
>messages.
>
>Does anybody else use PC-lint with the CrossWorks compiler and know a way 
>to
>suppress those kind of messages?  I have tried -esym(778, P4IN) but that 
>has
>no effect.

Hi,

> Thanks Anders, that did the trick!  Apparently,
the volatile 
> keyword must 
> override the const keyword since the combination of the two 
> does not make 
> sense.

Why ever do you think that it doesn't make sense to have a const
volatile?  volatile means "you need to re-read this after sequence
points" and const means "you can't write to that".  const
volatile "this is a read-only thing that changes beyond the compiler's
view of
the world".  As you were reading P1IN, it makes absolute sense that it
is const volatile underneath the hood.  sfrb and sfrw automatically
infer volatility, hence a const sfrb is a non-writable volatile object.
This is exactly what you need for P1IN (for instance).

-- Paul.

>Why ever do you think that it doesn't make sense to have a const
>volatile?  volatile means "you need to re-read
this after sequence
>points" and const means "you can't write to that". 
const volatile >"this is a read-only thing that changes beyond the
compiler's view of
>the world".  As you were reading P1IN, it makes absolute sense that it
>is const volatile underneath the hood.  sfrb and sfrw automatically
>infer volatility, hence a const sfrb is a non-writable volatile object.
>This is exactly what you need for P1IN (for instance).

I guess I thought "const" meant it was a constant, not that it was 
read-only.  Your definition makes it all clear now how things work.  
However, I can't help but say this use of const really is not grammatically

correct in the English language sense.  I mean const implies constant and if 
something is a constant, it cannot change.  It could have an initial value, 
but would always maintain that value throughout execution of the program.  
In that sense, a const value could literally be read from program FLASH 
since it is always a constant.  The book from which I learned C says,
"const 
is used to inform the compiler that the value of the variable that follows 
it may not be changed except for an initialization."  So, a volatile const 
would not make sense, hence my response.  So it looks like "const
volatile" 
is really saying "read-only varying value".

I know, programming languages do not have to obey English language rules.  
It is just taking me a while to get used to the variant meanings.

Lou

On Wed, 08 Jun 2005 12:21:31 -0500, Lou wrote:

>>Why ever do you think that it doesn't make
sense to have a const
>>volatile?  volatile means "you need to re-read this after sequence
>>points" and const means "you can't write to that". 
const volatile >>"this is a read-only thing that changes beyond the
compiler's view of
>>the world".  As you were reading P1IN, it makes absolute sense that
it
>>is const volatile underneath the hood.  sfrb and sfrw automatically
>>infer volatility, hence a const sfrb is a non-writable volatile object.
>>This is exactly what you need for P1IN (for instance).
>
>I guess I thought "const" meant it was a constant, not that it was

>read-only.  Your definition makes it all clear now how things work.  
>However, I can't help but say this use of const really is not
grammatically 
>correct in the English language sense.  I mean const implies constant and if

>something is a constant, it cannot change.  It could have an initial value, 
>but would always maintain that value throughout execution of the program.  
>In that sense, a const value could literally be read from program FLASH 
>since it is always a constant.

>  <above text remains for context>

>The book from which I learned C says,
>
>   "const is used to inform the compiler that the
>    value of the variable that follows it may not
>    be changed except for an initialization."
>
>So, a volatile const would not make sense, hence my response.

If you read Paul's comment and the above comment closely, you will
find them _possibly_ congruent.  The issue is that "the book" you
mention fails a little on completeness.  Perhaps it could have said:

>   "const is used to inform the compiler that
the
>    value of the variable that follows it may not
>    be changed __by compiler generated code where
>    this declaration is visible_ except for an
>    initialization."

That may have made it more pointed.

Jon

Lou, 

> I guess I thought "const" meant it was a
constant, not that 
> it was read-only.

Const is a qualifier that prohibits the client from changing it.  THAT
DOES NOT MEAN THAT ITS VALUE DOES NOT CHANGE!  I wrote the caps and I
meant it.  It is a common misconception that something declared
"const"
in some way is non-changing.  This is NOT the case.  Consider:

void change_through_ptr(int *x)
{
  *x = 99;
}

void take_some_ptrs(int *x, const int *y)
{
  printf("*x = %d, *y = %d\n, *x, *y);
  change_through_ptr(x);
  printf("*x = %d, *y = %d\n, *x, *y);
}

void main(void)
{
  int q = 22;
  take_some_ptrs(&q, &q);
}

This will print:

22 22
99 99

Although y points to something that take_some_ptrs cannot change,
changing *x will also change *y.  This is valid C.  Thus something
"const" means "you can't write that here" not that
"you can never write
it and it'll never change".

>  Your definition makes it all clear now how 
> things work.  
> However, I can't help but say this use of const really is not 
> grammatically correct in the English language sense.  

It's inherited from C++ into ANSI C IIRC.  It's just over-use of
the
some new keyword, like the lexical element 0 is overworked in C.

> I mean 
> const implies constant and if something is a constant, it 
> cannot change.

ANSI C++ allows you to optimize out something declared "const" if
the
const is global and has an initializer as its value truly can never
change (modulo errors).

> It could have an initial value, but would 
> always maintain that value throughout execution of the program.  
> In that sense, a const value could literally be read from 
> program FLASH since it is always a constant.  The book from 
> which I learned C says, "const is used to inform the compiler 
> that the value of the variable that follows it may not be 
> changed except for an initialization."  

In some cases it's right.  In most cases that's wrong.

> So, a volatile const 
> would not make sense, hence my response.  So it looks like 
> "const volatile" 
> is really saying "read-only varying value".

The const is used as a qualifier that inadvertently stops you writing
somewhere.  It is no more than that.

> I know, programming languages do not have to obey
English 
> language rules.  
> It is just taking me a while to get used to the variant meanings.

Wait until you get on to C++ mutable and then figure out whether C++ in
all its forms is a neat language...

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

Lou C wrote:

>Thanks Anders, that did the trick!  Apparently, the
volatile keyword must 
>override the const keyword since the combination of the two does not make 
>sense.
>  
>

Well, to me they do -- but I guess it's because I read "const" as
"read 
only".

In fact, if you take a look at the IO header files that are provided by 
your compiler then chanses are that all read-only IO ports are declared 
as "const volatile". (Well, if you're using our compiler then
they are.)

    -- Anders Lindgren, IAR Systems

-- 
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.