Op Mon, 23 Apr 2007 11:46:24 +0200 schreef Marcin Wolcendorf  
<w...@friko2.onet.pl>:
> Marcin Wolcendorf <w...@friko2.onet.pl> wrote:
>> On Sun, 22 Apr 2007 08:58:18 -0700, Arlet wrote:
>>
>> > On Apr 22, 12:44 pm, Marcin Wolcendorf <wolce...@friko2.onet.pl>
>> > wrote:
>> >
>> >> No. It doesn't. One of the rules states (I don't have them in front
>> >> of me), that you can't use signed constants (like -1U) to set
>> >> unsigned variables. -1U is a nice value of all 1s binary,
>> >> convenient for masking. Well, you can get
>> ...
>> >
>> > 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
> being converted to an unsigned type.) just as -1U does.

How about ~(0U) and -(1U) ?

> 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.



-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Hi,

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

> On Apr 23, 5:46 am, Marcin Wolcendorf <wolce...@friko2.onet.pl> wrote:
>> Marcin Wolcendorf <wolce...@friko2.onet.pl> 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 ;).

M.

On Mon, 23 Apr 2007 16:06:52 +0200, Boudewijn Dijkstra wrote:

> Op Mon, 23 Apr 2007 11:46:24 +0200 schreef Marcin Wolcendorf  
> <w...@friko2.onet.pl>:
>> Marcin Wolcendorf <w...@friko2.onet.pl> 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
>> being converted to an unsigned type.) just as -1U does.
> 
> How about ~(0U) and -(1U) ?

Haven't checked that. I'm afraid there will be no difference; I'll check
it tomorrow.

M.

On Mon, 23 Apr 2007 10:20:20 +0200, Boudewijn Dijkstra wrote:

> Op Sun, 22 Apr 2007 14:02:40 +0200 schreef Marcin Wolcendorf
> <w...@friko2.onet.pl>:
>> That's ... interesting. IMHO- it would _not_. It is enough to say to
>> technically inept boss, that 'it will make your code safer' and back it
>> up with 'GM, VW, Toyota and all the others agree on that' to
>> persuadehim to be '100% MISRA-C compliant, no deviations'.
> 
> There are two kinds of developers who create MISRA-compliant code: 1.
> Those who were told to by their pointy-haired boss; and 2. Those who
> understand the spirit of MISRA and think it can help them write better
> code.
> 
>  From I've gathered from this discussion so far, and disregarding the
> overlap between 1 and 2, a lot of people seem to be saying that group #1
> is big and therefore that MISRA is bad and/or useless.

Well, MISRA is a tool. IMHO there are two (at least) domains to describe
the tool: 
- safety,
- usefulness.
IMHO- this tool is unsafe, because it can be _easily_ used in unsafe way
(the pointy-haired boss...). And it is also useful- helping to make a
better code. Just like a razor. Give it to the monkey and give it to the
barber and see, what will happen ;).


>>> Sure, it is possible to be careful and not be MISRA-compliant, but
>>> should
>>> your boss trust _all_ his developers to be careful enough _all_ the
>>> time?
>>
>> The hint is - MISRA-C doesn't help to solve much. Especially, it won't
>> help with:
>> #define ONE 1
>> #define TWO 2
>> #define THREE 3
>> ...
>> up to 60 or something.
>>
>> I've seen that in '100% MISRA-C compliant' code. What is more- these
>> defines were used in the code for example to get to the data in CAN
>> frames.
>> All because 'you have to have all numeric constants #defined'. Now,
>> what will happen, if I change for example 42 to 24?
> 
> Just like with any set of rules, you can follow them to the letter, or
> you can try to follow the spirit of it.  Your example definately defeats
> the spirit of MISRA-C.

True. But, after all, I am paid for MISRA-C compliant code, not for code
that follows its spirit. Even if non-compliant code is commented, it's
clear, what it does- it is still not compliant ((uint16_t)(~0U) ? Does
anyone have any doubts what id does? And that it is safer that any
possible work-around?). The compliant code, however obscure, is still
compliant. Unfortunately, the 'faulty MISRA compliant' code is easier to
write, than truly compliant code. Which means, that, given poor
management, one will tend to write poor code as to increase his/hers
productivity. Yes, this is management issue. Can't separate them (MISRA
and management), sorry.

...
>> Of course, you should control what they do. MISRA can help you as
>> aguide here. It will mislead you as a ruleset, IMHO.
> 
> As has been said before in this discussion: "In the end, the programmer
> must not just follow the rules, but also understand the reasoning behind
> them, and must apply the same philosophy to the rest of his work. It
> should not come as a surprise that a set of guidelines can be subverted
> by a sufficiently motivated person."

I'd add here, that sometimes rules shall not be applied, as following
spirit may be against the letter.

M.

On Mon, 23 Apr 2007 12:41:44 +0100, Chris Hills wrote:

> In article <o...@ragnarok.lan>, Boudewijn Dijkstra 
> <b...@indes.com> writes
>>From I've gathered from this discussion so far, and disregarding the 
>>overlap between 1 and 2, a lot of people seem to be saying that group 
>>#1 is big and therefore that MISRA is bad and/or useless.
> 
> I agree. I see many people spending effort on trying to circumvent the 
> MISRA-C rules whilst technically sticking to them

And why, the hell, is that? 

> The rules are there for guidance.  They were put together by a group of 
> people with a hell of a lot of real experience in critical systems.

Yes, but IMHO guidance means- we don't have to follow blindly, we can lift
the rule if necessary.

> It saddens me to see so many people trying to find ways to beat the 
> rules rather than using them as guidance to write better code.

I am requested to have no MISRA-C warnings in my code (see any spirit
here?). Now, I have two ways of dealing with possible issues:
- make it compliant to the letter, forget the spirit,
- try to make it compliant to the spirit (hard way) and possibly make a
deviation (pain in the neck). 
Now, I mostly choose the second option (against my short-term interests).
So _sometimes_ I have to argue with my boss and convince him, that we
should deviate, and my code takes _sometimes_ longer to write. Those, who
follow the other way, are therefore easier to get along with, faster-
shortly- better. Do you really think this positively motivates me to
follow the spirit of MISRA?

>>
>>Just like with any set of rules, you can follow them to the letter, or 
>>you can try to follow the spirit of it.  Your example definately 
>>defeats the spirit of MISRA-C.
> 
> Exactly. You also see people being very stupid and doing things like the 
> defines above rather than using a deviation and expelling why they are 
> deviating.

Huh? Do you _really_ think there is _any_ reason to have those (now
deleted) defines _except_ MISRA 'compliance'?
Deviating is not easy. Takes time. Takes effort. Deadlines approaching.
Why should I take overtime to do it? 

...
> I find is sad that so many programmers spend time and effort trying to
> subvert the rules rather than trying to become more professional SW
> Engineers

Why? Why do this? What is in that for me? Will I be better payed? 

M.

Marcin Wolcendorf wrote:
> On Mon, 23 Apr 2007 06:47:55 -0700, Robert Adsett wrote:
>> Marcin Wolcendorf <wolce...@friko2.onet.pl> wrote:
>>
... snip ...
>>>
>>> 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.

Ignoring Misra, that is not as accurate as "unsigned = -1", which
will set all bits to one everywhere.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>;
 <http://www.securityfocus.com/columnists/423>;
 <http://www.aaxnet.com/editor/edit043.html>;
                            cbfalconer at maineline.net



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

In article <f0imuo$aer$1...@atlantis.news.tpi.pl>, 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...@friko2.onet.pl> wrote:
> >> Marcin Wolcendorf <wolce...@friko2.onet.pl> 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. 

I still don't see an integer constant expression with a negative value.  

OTOH any reason not to set up the variable during initialization (since 
it appears not to be const)?

some_variable = ~some_variable;

That should also get rid of the casts.

Robert

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

On Mon, 23 Apr 2007 14:20:53 -0400, CBFalconer wrote:

> Marcin Wolcendorf wrote:
>> On Mon, 23 Apr 2007 06:47:55 -0700, Robert Adsett wrote:
>>> Marcin Wolcendorf <wolce...@friko2.onet.pl> wrote:
>>>
...
>> 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.
> 
> Ignoring Misra, that is not as accurate as "unsigned = -1", which
> will set all bits to one everywhere.

Are there situations, when ~0 won't set all 1s? The only one I can think
of that late that could be dangerous is:
unsigned long long var = ~0;
Right?

M.

In article <f0imuo$aer$1...@atlantis.news.tpi.pl>, 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...@friko2.onet.pl> wrote:
> >> Marcin Wolcendorf <wolce...@friko2.onet.pl> 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

In article <f0ir03$lr5$2...@atlantis.news.tpi.pl>, Marcin Wolcendorf 
<w...@friko2.onet.pl> writes
>On Mon, 23 Apr 2007 12:41:44 +0100, Chris Hills wrote:
>
>> In article <o...@ragnarok.lan>, Boudewijn Dijkstra
>> <b...@indes.com> writes
>>>From I've gathered from this discussion so far, and disregarding the
>>>overlap between 1 and 2, a lot of people seem to be saying that group
>>>#1 is big and therefore that MISRA is bad and/or useless.
>>
>> I agree. I see many people spending effort on trying to circumvent the
>> MISRA-C rules whilst technically sticking to them
>And why, the hell, is that?
>> The rules are there for guidance.  They were put together by a group of
>> people with a hell of a lot of real experience in critical systems.
>
>Yes, but IMHO guidance means- we don't have to follow blindly, we can lift
>the rule if necessary.

I agree.

>> It saddens me to see so many people trying to find ways to beat the
>> rules rather than using them as guidance to write better code.
>
>I am requested to have no MISRA-C warnings in my code (see any spirit
>here?). Now, I have two ways of dealing with possible issues:
>- make it compliant to the letter, forget the spirit,
>- try to make it compliant to the spirit (hard way) and possibly make a
>deviation (pain in the neck).
>Now, I mostly choose the second option (against my short-term interests).

Good.

>So _sometimes_ I have to argue with my boss and convince him, that we
>should deviate, and my code takes _sometimes_ longer to write. Those, who
>follow the other way, are therefore easier to get along with, faster-
>shortly- better. Do you really think this positively motivates me to
>follow the spirit of MISRA?

Point taken.   Perhaps something can be added to the MISRA-C TC?


>>>Just like with any set of rules, you can follow them to the letter, or
>>>you can try to follow the spirit of it.  Your example definately
>>>defeats the spirit of MISRA-C.
>>
>> Exactly. You also see people being very stupid and doing things like the
>> defines above rather than using a deviation and expelling why they are
>> deviating.
>
>Huh? Do you _really_ think there is _any_ reason to have those (now
>deleted) defines _except_ MISRA 'compliance'?

Only for S-Boxes in DES systems.

>Deviating is not easy. Takes time. Takes effort. Deadlines approaching.
>Why should I take overtime to do it?

Life is a balance of many things.  MISRA-C is not a solution on it's 
own.

>> I find is sad that so many programmers spend time and effort trying to
>> subvert the rules rather than trying to become more professional SW
>> Engineers
>
>Why? Why do this? What is in that for me?

Being more professional.

>Will I be better payed?


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/