shame on MISRA

Richard Pennington wrote:
> 
... snip ...
> 
> My favorite is 3["Hello world"] == 'l'.

#define true ('r' == 5["foobar"])
#define false !true

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



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

Dave Hansen wrote:
> Richard Pennington <r...@pennware.com> wrote:
> [...]
>>
>> My favorite is 3["Hello world"] == 'l'.
>>
>> Well, maybe not my favorite, but one of my top 10. ;-)
> 
> My favorite, which is actually in use in code somewhere, is similar to
> 
>    digit = "0123456789ABCDEF"[value & 0x0F];

That is almost the only clear and portable way to convert into
hex.  Routine.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



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

Hans-Bernhard Br&#4294967295;ker <HBBroeker@t-online.de> wrote:
> Stefan Reuther wrote:
>> disident@rootshell.be wrote:
>>> a = &x[i] is absolutely equivalent to a=x+i (assuming i is an integer
>>> and a&x are pointers of the same type).
> 
>> No, it's not. While '&x[i]' requires the element i to exist (i.e. array
>> x must have at least i+1 elements), 'x+i' doesn't. 
> 
> You're quite completely wrong there.  &x[i] is required by the standard 
> to be exactly the same as x+i, because:
> 
> 1) x[i] is required to be completely equivalent to *(x+i).  The [] 
> operator is actually defined by this very property.

Indeed. C99 says "The unary & operator returns the address of its operand.
[...] If the operand is the result of a [] operator, neither the & operator
nor the unary * that is implied by the [] is evaluated and the result is as
if the & operator were removed and the [] operator were changed to a +
operator."

However, if I see that correctly, neither C90 nor C++98 make that exception,
making "*(x+i)" a constraint violation if x has only i elements, even if the
"&" operator is applied to it afterwards.

That aside, I would assume that a normal (=not bounds-checking) compiler
generates the same machine code for &x[i] and x+i anyway.


  Stefan

"Chris Hills" <chris@phaedsys.org> wrote in message 
news:W+j$TdDdxpCGFAy1@phaedsys.demon.co.uk...
> In article <2xgOh.9590$JZ3.5423@newssvr13.news.prodigy.net>, Vladimir 
> Vassilevsky <antispam_bogus@hotmail.com> writes
>>
>>
>>Chris Hills wrote:
>>
>>
>>> See  http://www.phaedsys.demon.co.uk/chris/mistrayc/MISTRAYC.pdf
>>> for a REAL programmers guide for people who do not want their 
>>> creativity  limited.
>>
>>Though it is not too creative just to take MISRA and revert every rule 
>>upside down.
>>
>>VLV
>
> I just did it for fun.

Perhaps I might I suggest fishing, golf, stamp collecting...
;-) 

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:460B0955.F4219F08@yahoo.com...
> Dave Hansen wrote:
>> Richard Pennington <r...@pennware.com> wrote:
>> [...]
>>>
>>> My favorite is 3["Hello world"] == 'l'.
>>>
>>> Well, maybe not my favorite, but one of my top 10. ;-)
>>
>> My favorite, which is actually in use in code somewhere, is similar 
>> to
>>
>>    digit = "0123456789ABCDEF"[value & 0x0F];
>
> That is almost the only clear and portable way to convert into
> hex.  Routine.

I've not seen this sort of thing before - what is the method called? I'd 
like to find out more about it. 

Tom Lucas wrote:
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>> Dave Hansen wrote:
>>
... snip ...
>>>
>>> My favorite, which is actually in use in code somewhere, is similar
>>> to
>>>    digit = "0123456789ABCDEF"[value & 0x0F];
>>
>> That is almost the only clear and portable way to convert into
>> hex.  Routine.
> 
> I've not seen this sort of thing before - what is the method called?
> I'd like to find out more about it.

No name, just portable translation, where you can't count on ASCII
encoding.  The same array can be used in both directions, if you
either up (or down) shift the input, or extend the array to
"0123456789abcdefABCDEF".

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



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

Recently they showed me a case when the strict compliance to MISRA 
provoked the mistake:

Original code:

foobar()
{
u8 variable;

variable = something;

/*
Explicit type conversion is required by MISRA. This is because of the C 
convention: result of any integer operation is int
*/

variable = (u8)(variable + 1);
}

Later, the code was modified. It was decided that variable should be u16.

u16 variable;

But this line was not changed:

variable = (u8)(variable + 1);

So here is a bug. No warnings.

If this would be just:

  variable = variable + 1;

There would be no bug.

//---------------------------------------

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Vladimir Vassilevsky wrote:
> 
> Recently they showed me a case when the strict compliance to MISRA 
> provoked the mistake:
> 
> Original code:
> 
> foobar()
> {
> u8 variable;
> 
> variable = something;
> 
> /*
> Explicit type conversion is required by MISRA. This is because of the C 
> convention: result of any integer operation is int
> */
> 
> variable = (u8)(variable + 1);
> }
> 
> Later, the code was modified. It was decided that variable should be u16.
> 
> u16 variable;
> 
> But this line was not changed:
> 
> variable = (u8)(variable + 1);
> 
> So here is a bug. No warnings.
> 

Why no warnings? What compiler?  I frequently write for 'SCDE' (Standard C Development
Environment') on SVR4 (C 90) and also port stuff developed by others on GCC which
often produces lots of warnings about "explicit cast required" for assignments and
logical comparisons which the original authors failed to qualify with a cast. Evidently
these things pass 'lint' and compile in GCC with no warnings (even at a high warning
level).  Most authors are dumbstruck by the need to explicitly cast (sometimes even
numeric constants).

Regards,

Michael

Colin Paul Gloster wrote:

> The Ada standard is available for gratis.

The point being ?. Would you expect to get a usefull book for nothing 
that someone has spent considerable time and effort to produce, or 
should everything be open source and free ?. Of course, including all 
your own work.

Now that it's a sane price, have just downloaded the misra pdf version 
and am almost disappointed in that there's almost nothing that I can 
disagree with. Having seen so much controversy about it etc.  In fact, 
it seems a bit lightweight, just good common sense practice that one 
would expect from any experienced embedded engineer.

The C++ version should be quite interesting...

Chris

In article <pKROh.17989$NK3.11439@newsfe6-win.ntli.net>, ChrisQuayle 
<nospam@devnul.co.uk> writes
>Colin Paul Gloster wrote:
>
>> The Ada standard is available for gratis.
>
>The point being ?. Would you expect to get a usefull book for nothing 
>that someone has spent considerable time and effort to produce, or 
>should everything be open source and free ?. Of course, including all 
>your own work.
>
>Now that it's a sane price, have just downloaded the misra pdf version 
>and am almost disappointed in that there's almost nothing that I can 
>disagree with. Having seen so much controversy about it etc.  In fact, 
>it seems a bit lightweight, just good common sense practice that one 
>would expect from any experienced embedded engineer.
>
>The C++ version should be quite interesting...

Hopefully by the end of the year.

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