On Wed, 28 Mar 2007 11:31:31 +0200, Boudewijn Dijkstra wrote:

> Op Tue, 27 Mar 2007 22:32:58 +0200 schreef <d...@rootshell.be>:
>> And the official position of
>> my employer is not clean.
>> And also clients of my employer think that _every_ MISRA deviation is
>> dangerous and terrible. And what I claim is that MISRA people are
>> guilty about this situation.
> 
> MISRA would be dead today if it didn't help developers to be careful about  
> what they write and to solve mistakes at an early stage.  Especially if  
> missing a deadline means endangering the jobs of hundreds of people.

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 persuade him to
be '100% MISRA-C compliant, no deviations'. 

> 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? 
You have to trust your developers; they are the ones to go by the rules anyway.
If you don't trust they know, what they are doing, how can you trust they'll
follow the rules? How can you trust they will not circumvent rules? Of course,
you should control what they do. MISRA can help you as a guide here. It will
mislead you as a ruleset, IMHO.

M.

On Sun, 22 Apr 2007 10:44:17 +0000 (UTC), Marcin Wolcendorf
<w...@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
>rid of complaints in two ways:
>- write 0xFFFFFFFFU instead of -1U (how many Fs do you see? 8? 7? 9? If someone
>  removes one F will you be able to spot it easily? IMHO- no, you will not.
>  Even, if you have it #defined),

I sometimes use 0xFFFFffff which is with a constant width font quite
readable :-).

Paul

On Sun, 22 Apr 2007 17:06:52 +0300, Paul Keinanen wrote:

> On Sun, 22 Apr 2007 10:44:17 +0000 (UTC), Marcin Wolcendorf
> <w...@friko2.onet.pl> wrote:
> 
>>- write 0xFFFFFFFFU instead of -1U (how many Fs do you see? 8? 7? 9? If
>>someone
>>  removes one F will you be able to spot it easily? IMHO- no, you will
>>  not. Even, if you have it #defined),
> 
> I sometimes use 0xFFFFffff which is with a constant width font quite
> readable :-).

Well, if you can do it, good for you :). I can't. All hex constants have
to be written in caps. What is more- supporters for MISRA 'no matter what'
_and_ the caps rule - given this example - were unable to say, how many Fs
they see. Yet, they still argue, that this is just a 'minor
inconvenience'. MISRAtitis, I'd say. No 'common sense' here...

M.

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
> rid of complaints in two ways:
> - write 0xFFFFFFFFU instead of -1U (how many Fs do you see? 8? 7? 9? If someone
>   removes one F will you be able to spot it easily? IMHO- no, you will not.
>   Even, if you have it #defined),
> - add a signed variable, initialise it with -1U, and convert it explicitly to
>   unsigned in expression (superfluous variable does not add to visibility).
> Now, both ways are clumsy, hard to read and look like a dirty hack IMHO.
> What would you say?

Just use ~0U

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

~0 works pretty well for these purposes

-- 
	mac the naïf

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. 

M.

Op Sun, 22 Apr 2007 14:02:40 +0200 schreef Marcin Wolcendorf  
<w...@friko2.onet.pl>:
> On Wed, 28 Mar 2007 11:31:31 +0200, Boudewijn Dijkstra wrote:
>> Op Tue, 27 Mar 2007 22:32:58 +0200 schreef <d...@rootshell.be>:
>>> And the official position of
>>> my employer is not clean.
>>> And also clients of my employer think that _every_ MISRA deviation is
>>> dangerous and terrible. And what I claim is that MISRA people are
>>> guilty about this situation.
>>
>> MISRA would be dead today if it didn't help developers to be careful  
>> about what they write and to solve mistakes at an early stage.  
>> Especially if missing a deadline means endangering the jobs of hundreds 
>> of people.
>
> 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.

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

> You have to trust your developers; they are the ones to go by the rules  
> anyway.  If you don't trust they know, what they are doing, how can you
> trust they'll follow the rules?
> How can you trust they will not circumvent rules?

How can you trust a lawyer not to exploit a hole in the law?

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


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

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

M.

In article <o...@ragnarok.lan>, Boudewijn Dijkstra 
<b...@indes.com> writes
>Op Sun, 22 Apr 2007 14:02:40 +0200 schreef Marcin Wolcendorf 
><w...@friko2.onet.pl>:
>> On Wed, 28 Mar 2007 11:31:31 +0200, Boudewijn Dijkstra wrote:
>>> Op Tue, 27 Mar 2007 22:32:58 +0200 schreef <d...@rootshell.be>:
>>>> And the official position of
>>>> my employer is not clean.
>>>> And also clients of my employer think that _every_ MISRA deviation is
>>>> dangerous and terrible. And what I claim is that MISRA people are
>>>> guilty about this situation.
>>>
>>> MISRA would be dead today if it didn't help developers to be careful 
>>>about what they write and to solve mistakes at an early stage. 
>>>Especially if missing a deadline means endangering the jobs of 
>>>hundreds  of people.
>>
>> 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.

I agree. I see many people spending effort on trying to circumvent the 
MISRA-C rules whilst technically sticking to them

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.

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.

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

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.


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


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

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

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

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

Robert