shame on MISRA

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. Also trying to invert the rules was a useful test 
of the rule.
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <pdkj03hoi7j01b596qpk4s2ch0a2pit7d0@4ax.com>, Jack Klein 
<jackklein@spamcop.net> writes
>On Tue, 27 Mar 2007 09:38:01 +0100, Chris Hills <chris@phaedsys.org>
>wrote in comp.arch.embedded:
>
>   [snip]
>
>> There will be a TC and example suite soon and a MISRA-C V3 in a few
>> years. Hopefully it will have the same level of improvements between 2 &
>> 3 as 1 & 2
>
>   [snip]
>
>Chris, please be sure to post here when these things are available.
>Like most people, I do not visit the MISRA web site very often
>because, let's face it, it does not change very often.

Fair enough I will let you  allknow when they are available.

>Also, if you are looking for outside reviewers and/or beta users of
>the TC or new version, I am willing to participate.  Just email me at
>my completely undisguised address.

I use my real email address here so please send me you contact details

>I work, these days, in safety critical embedded control for medical
>devices, and we have incorporated a large part of MISRA C in our
>coding standards for several years now.  I'll supply my company
>affiliation via email if you want it.

OK Yes please.

I note you use "a large part of MISRA-C"   You look at MISRA-C and apply 
it to your development. Not al the rules will be applicable all the 
time.  As long as it makes you THINK about what you are doing and avoid 
some of the pitfalls of C then it has achieved it's purpose.

No one has ever said total conformance to MISRA-C at all times was going 
to be possible or in deed sensible all the time.   This is why some 
rules are "required" and some "advisory"


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

disident@rootshell.be wrote:
>>Yes, this is correct. You should not modify, alias or copy the pointers.
>>Work with arrays and indexes only.
> 
> 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. If your compiler can
do array bounds checks, it will probably do that for '&x[i]', but not
for 'x+i'.


  Stefan

On Mar 28, 5:34 pm, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

> > The bigger issue is that basically *any* random C program can be
> > converted into an equivalent program that complies with MISRA rules
> > (or any other set of similar rules, for that matter). This conversion
> > process can even be done fully automatically by a suitable tool. Of
> > course, simply rewriting code into a different syntactic form does
> > not, by itself, increase the safety.
> >"
>
> I had been unaware of this. How? Does this apply to all such sets of
> rules?

A simple, but perverse, way to do this would be to create a virtual
machine, for example an x86 CPU emulator. The emulator would have to
be written (once) to comply with MISRA rules. You can then take a
random C program, compile it to x86 instructions, and add it as a
static array to the emulator code.

This could be done within any set of rules that still leave enough
power to construct a virtual machine, which is pretty much anything
that still classifies as a programming language.

Colin Paul Gloster wrote:
> In news:9maOh.94188$ia7.33871@newsfe14.lga timestamped Tue, 27 Mar
> 2007 11:03:09 -0400, John Perry <jp@no.spam> posted:
> ...
> 
> "...and the fault with MISRA is...?
> 
> [..]"
> 
> If it does not prohibit the practices it is supposed to, then that is
> a problem.

The answer, of course, was in the paragraph above, which you deleted:
"MISRA and such are not intended to be proof against the bad guys..."

John Perry

Stefan Reuther wrote:
> disident@rootshell.be wrote:
>>> Yes, this is correct. You should not modify, alias or copy the pointers.
>>> Work with arrays and indexes only.
>> 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. If your compiler can
> do array bounds checks, it will probably do that for '&x[i]', but not
> for 'x+i'.
> 
> 
>   Stefan
> 

Hmm. &x[i] does not require that x has i+1 elements. In fact it is 
explicitly mentioned in the standard when x has exactly i elements.

I don't think the standard has changed the fact that for a pointer (or 
array name) x and an integer i that

x + i == i + x == &x[i] == &i[x]

Has it?

-Rich

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.

2) &*(pointer) is required to be equivalent to (pointer), expressly 
including that such an expression does not comprise a dereference of the 
pointer, i.e. it doesn't trigger any additonal requirements on the value 
of (pointer).

Richard Pennington wrote:
> Stefan Reuther wrote:
>> disident@rootshell.be wrote:
>>>> Yes, this is correct. You should not modify, alias or copy the 
>>>> pointers.
>>>> Work with arrays and indexes only.
>>> 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. If your compiler can
>> do array bounds checks, it will probably do that for '&x[i]', but not
>> for 'x+i'.
>>
>>
>>   Stefan
>>
> 
> Hmm. &x[i] does not require that x has i+1 elements. In fact it is 
> explicitly mentioned in the standard when x has exactly i elements.
> 
> I don't think the standard has changed the fact that for a pointer (or 
> array name) x and an integer i that
> 
> x + i == i + x == &x[i] == &i[x]
> 
> Has it?
> 

The C standard says that "x + i" and "&x[i]" have the same value. 
However, &x[i] is only valid if x has at least i elements (not 
necessarily (i + 1) - the address beyond the top of the array is also 
valid).  The compiler should generate the expected code for &x[i] with 
out of range i, but it is not guaranteed.

However, any good C compiler, or other C analyser like lint, will 
interpret "&x[i]" and "x + i" differently, as they operate on a higher 
level than blind code generation.  On an array access, they can do a 
certain amount of static range checking - some C compilers may even have 
the option for run-time range checking.  The compiler may also be able 
to do better alias analysis and therefore generate better code with the 
array access (since it knows the range the resultant pointer could take).

All this is, of course, subservient to the golden rule of writing 
understandable code.  If "i" is an index into the array "x", then the 
correct form is "&x[i]" - "x + i" does not say what you mean, and is 
therefore bad code.


> -Rich

David Brown wrote:
[snip]
> The C standard says that "x + i" and "&x[i]" have the same value. 
> However, &x[i] is only valid if x has at least i elements (not 
> necessarily (i + 1) - the address beyond the top of the array is also 
> valid).  The compiler should generate the expected code for &x[i] with 
> out of range i, but it is not guaranteed.
Correct.

> 
> However, any good C compiler, or other C analyser like lint, will 
> interpret "&x[i]" and "x + i" differently, as they operate on a higher 
> level than blind code generation.  On an array access, they can do a 
> certain amount of static range checking - some C compilers may even have 
> the option for run-time range checking.  The compiler may also be able 
> to do better alias analysis and therefore generate better code with the 
> array access (since it knows the range the resultant pointer could take).

Not really. "Any good C compiler" could recognize "x + i" as identical 
to "&x[i]". In fact, whether or not pointers are involved with data flow 
analysis, range checking could also be done.

> 
> All this is, of course, subservient to the golden rule of writing 
> understandable code.  If "i" is an index into the array "x", then the 
> correct form is "&x[i]" - "x + i" does not say what you mean, and is 
> therefore bad code.

My favorite is 3["Hello world"] == 'l'.

Well, maybe not my favorite, but one of my top 10. ;-)

-Rich

On Mar 28, 5:49 pm, 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];

Regards,

   -=Dave