Re: shame on MISRA

In article <f0imuo$aer$1@xxxxxxxxxxxxxxxxxxxx>, Marcin Wolcendorf
says...
Hi,

On Mon, 23 Apr 2007 06:47:55 -0700, Robert Adsett wrote:

On Apr 23, 5:46 am, Marcin Wolcendorf <wolce...@xxxxxxxxxxxxxx> wrote:
Marcin Wolcendorf <wolce...@xxxxxxxxxxxxxx> wrote:
On Sun, 22 Apr 2007 08:58:18 -0700, Arlet wrote:

Just use ~0U

True :).
I can't recall the reason, why I didn't use it.

Yeah, now I can. It just doesn't matter. If I use ~0U it will trigger
MISRA-C rule 10.1 (An integer constant expression with negative value is

Maybe I'm being exceptionally dense this morning but What integer
constant expression with a negative value?

Well, having ~0U is not quite enough; I want to use it :). So I did:
uint16_t some_variable = (uint16_t)(~0U);
(effectively- all #defines, ...) to have 0xffff in some_variable. It was
enough to trigger the rule.

being converted to an unsigned type.) just as -1U does. No difference
from MISRA-C check point of view. It is a better way- logical operators
only, and this is a logical value- but it is not enough.

Is this an automated check against the rules or a hand check?

It is an automated check. I'm not sure enough that my mind won't bend the
rule, to do a hand check, sorry ;).

OK I ran a test using the following


extern unsigned char variable1;
extern unsigned int variable2;
extern unsigned short variable3;

variable2 = -1;
variable2 = ~0U;
variable2 = ~(unsigned int)0U;
variable3 = ~0U;

I'm not using typedefs just to keep conflicting types clear and I've got
the warning for that in the MISRA rules turned off since I'm using
standard libraries and that rule is WAY to noisy then.


I get the following errors

|
variable2 = -1;
test2.c 46 Note 960: Violates MISRA 2004
Required Rule 10.1, Prohibited Implicit Conversion: Signed versus
Unsigned

test2.c 46 Warning 570: Loss of sign
(assignment) (int to unsigned int)

|
variable2 = ~0U;
test2.c 47 Note 960: Violates MISRA 2004
Required Rule 10.5, Operators '~' and '<<' require recasting to
underlying
type for sub-integers

|
variable3 = ~0U;
test2.c 49 Note 960: Violates MISRA 2004
Required Rule 10.5, Operators '~' and '<<' require recasting to
underlying
type for sub-integers

test2.c 49 Warning 569: Loss of information
(assignment) (32 bits to 16 bits)

The ~0U doesn't give a 10.1 error which is the way I expected things to
be. I think your tool is broken. The 10.5 error is easily cast around
(see the third assignment) but I don't see the justification for the
rule. It looks more like a way of breaking type checking than an useful
method to prevent errors.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

.

Relevant Pages

  • Re: Adding gpib support to Matlab on Linux ?
    ... gpib.c:219: warning: assignment makes pointer from integer without a cast ...
    (comp.soft-sys.matlab)
  • compiling dcraw, a raw file to ppm convertor
    ... dcraw.c:479: warning: assignment makes pointer from integer without a cast ...
    (comp.sys.sgi.admin)
  • Re: Adding gpib support to Matlab on Linux ?
    ... gpib.c:219: warning: assignment makes pointer from integer without a cast ...
    (comp.soft-sys.matlab)
  • RE: GD library
    ... causes a "prerequisite not found" warning to be issued. ... GD.xs:455: warning: cast to pointer from integer of different size ... GD.xs:855: warning: assignment makes pointer from integer without a cast ... GD.xs:1213: error: invalid lvalue in assignment ...
    (RedHat)
  • [git patches 2/2] warnings: use uninitialized_var()
    ... used uninitialized" warning fixes, in misc-2.6.git#gccbug. ... 'uninit-var', you will receive BOTH 'uninit-var' and 'warnings' ... struct cyclades_port *info; ... unsigned int cur_frag, entry; ...
    (Linux-Kernel)