C and MISRA, blues... (arithmetic shifts)

On Fri, 25 Apr 2008 12:52:32 GMT, "Richard Phillips"
<raphillips@ntlworld.com> wrote:

>
>This is IMO exactly how MISRA should be used.
>I've been obeying MISRA in my coding at work for years (well, sort of), 
>while there are some things I think are very good (e.g. it makes you think 
>very carefully about casting and potential overflows, it doesn't like magic 
>numbers, etc etc), there are some things I get annoyed at, such as:
>
>* You're not supposed to use "goto".  Avoiding this when you're learning to 
>write code is good practise, but it's very useful in a limited set of 
>circumstances, if used properly.  I remember a manager of mine telling a 
>work colleague once that using "goto" was bad practise, I then showed my 
>colleague my copy of K+R which basically put him right.

IMHO, gotos are fine for jumping forward, but jumping backwards makes
it very hard to follow the program logic. Some looping control
structure can be used to repeat previously executed code. 

I have used this principle since the FORTRAM IV days, in which the
only block control structure was the DO-loop :-).

Paul

"Hans-Bernhard Br&#4294967295;ker" <HBBroeker@t-online.de> wrote in message news:futai4$ine$03$1@news.t-online.com...
> Wilco Dijkstra wrote:
>
>> There is no compiler that doesn't correctly implement signed arithmetic.
>
> That's beside the point --- shifting is not an arithmetic operation.

With arithmetic I meant all operators, including logical, relational, additive,
conversions etc.

> Nor is there even a definition of "correct" in place for shifting negative numbers.  If there were, there would never 
> been a need to invent the terms "arithmetic shift" and "logical shift".

The correct way to shift a signed number is to use an arithmetic shift.
The correct way to shift an unsigned number is to use a logical shift.
This stuff is pretty trivial and well defined. No compiler gets this wrong.

>> Nobody could get away with creating a compiler that can't compile existing
>> code.
>
> The problem is not with compiling the code --- it's what the compiled code will actually do.

You obviously compile to execute... It's well defined what a compiler will do.
If it didn't give the right answer the compiler would be considered broken.

Wilco 

Hans-Bernhard Br�ker schrieb:
> Nils wrote:
> 
>> However, it does not work if value is negative because  (-7/2) != 
>> (-7>>1). 
> 
> You can't know that.  You can't know if two things are unequal without a 
> reliable source defining the value for either of them.  -7>>1 causes 
> undefined behaviour in a C program.  So every assumption about its 
> result is wrong by default.

Yes, you're formally right of course. I have no reference except what 
works in practice.

Name me one CPU/system that:

  a. Does signed arithmetic in one's complement.
  b. a c-compiler exists for that architectue.
  c. Has any significance except nostalgia/historic reasons.

Yes, I'm nitpicking, but so are you :-)

Nils

Wilco Dijkstra wrote:
> "Chris H" <chris@phaedsys.org> wrote:
>
... snip ...
> 
>> I do have an email  where a user says:
>>
>> "We have moved from abc compiler to XYZ compiler. We used to
>> compile with abc and get no errors. We now using xyz compiler
>> we get lots of errors. We think this is because your xyz compiler
>> is more strict than the abc compiler.
>>
>> Please can you supply us a version of the xyz compiler with a
>> less strict parser."
> 
> Sounds fairly typical of a customer indeed. It's impossible to
> even try to talk them into fixing their code, as it works on any
> other compiler they tried. So you've got to fix the compiler or go
> out of business. Not a hard choice...

If your errors/warnings emit a number, and then haul up an error
message via an index into an auxiliary file, you can soften those
messages as much as you wish without doing anything special.  That
is also language independant.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

Nils wrote:
> Name me one CPU/system that:
> 
>  a. Does signed arithmetic in one's complement.
>  b. a c-compiler exists for that architectue.
>  c. Has any significance except nostalgia/historic reasons.
> 
> Yes, I'm nitpicking, but so are you :-)

If so, you just lost this nit-picking contest. ;->

"significance except nostalgia/history" is completely worthless as a 
nit-picking tool.  It's  an impossibly vague phrase that, if you really 
look at it, means nothing at all.

Hans-Bernhard Br�ker schrieb:
> Wilco Dijkstra wrote:
> 
>> There is no compiler that doesn't correctly implement signed arithmetic.
> 
> That's beside the point --- shifting is not an arithmetic operation.

Oh well.

But why does for example the java language explicitly defines a signed 
right-shift operator? I think the language designers learned from the 
c-language and didn't wanted to make the same mistake again. After all a 
compiler for a hypotetical CPU that can't do the arithmetic shift can 
simulate the operation.

You've asked elsewhere why one would do binary arithmetic on signed 
intergers at the first place. I agree with you that you normally don't 
need that, but there are exceptions. Here is just one:

I have to work on a integer-only CPU and have performance-goals that I 
can't reach with soft-float. My problem calls for more than just integer 
arithmetic.

Requirements are tight, as usual. So what do I do? I write all my 
arithmetic with block-floating-point. That makes the difference in 
performance that brings me over my mips-limit that was negotiated. It 
makes my client happy as well. I do need some signed binary arithmetic 
to get the magic happen though.

Fortunately you can explain such niffy details to the code-review guy 
and get a grant for a misra-warning, but it is cunmbersome to do it 
again and again.

Nils

Richard Phillips schrieb:

> This is IMO exactly how MISRA should be used.
> I've been obeying MISRA in my coding at work for years (well, sort of), 
> while there are some things I think are very good (e.g. it makes you think 
> very carefully about casting and potential overflows, it doesn't like magic 
> numbers, etc etc), there are some things I get annoyed at (...)

100% agree. But I think you miss a very important "real world" part of 
the entire MISRA thing:

You can't simply write "code should not suck" into a contract. If you 
write a piece of code for a company that does safety-critical stuff 
you'll better have some way to measure the code-quality.

This saves both parties of the contract and makes sure you don't get 
into an endless "please change this, I don't like that either, we got a 
warning here, what do you do there" loop.

Noone want's that. It is a efficient way to burn money and make sure 
that the final product never sees the light of day if you don't define 
some kind of standard. In my case that's MISRA with the bullshit omitted 
and some other bullshit added  Since I deliver code the recommendation 
becomes a duty. With all pros and cons.

Btw. I dig most of the recommendations. And I didn't had much problems 
to adopt my code. It was pretty good when I started to care about 
compliance.

There have been some things that made my code more unreadable. Some 
changes even came with a performance costs, but on the other hand I had 
to refactor and re-thing several functions that I would haven't touched.

I came up with a much easier and more performant way to express the same 
thing. And this is good.

   Nils

Hans-Bernhard Br�ker schrieb:
> Nils wrote:
>> Name me one CPU/system that:
>>
>>  a. Does signed arithmetic in one's complement.
>>  b. a c-compiler exists for that architectue.
>>  c. Has any significance except nostalgia/historic reasons.
>>
>> Yes, I'm nitpicking, but so are you :-)
> 
> If so, you just lost this nit-picking contest. ;->
> 
> "significance except nostalgia/history" is completely worthless as a 
> nit-picking tool.  It's  an impossibly vague phrase that, if you really 
> look at it, means nothing at all.

Jep! I have to agree. I just wanted to make sure you don't bring 
obsolete russian architectures into the discussion that do trenary 
arithmetic :-)


Ok. Ignore point c. Any answer to points a and b of my list?

Nils <-- enjoys this nit-picking.

Nils wrote:
> Hans-Bernhard Br�ker schrieb:
>
... snip ...
>
>> You can't know that.  You can't know if two things are unequal
>> without a reliable source defining the value for either of them. 
>> -7>>1 causes undefined behaviour in a C program.  So every
>> assumption about its result is wrong by default.
> 
> Yes, you're formally right of course. I have no reference except
> what works in practice.
> 
> Name me one CPU/system that:
>   a. Does signed arithmetic in one's complement.
>   b. a c-compiler exists for that architectue.
>   c. Has any significance except nostalgia/historic reasons.
> 
> Yes, I'm nitpicking, but so are you :-)

Yes, you are, but no, he's not.  Shifts on negative values are
undefined behaviour on any system.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


** Posted from http://www.teranews.com **

"Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> wrote in message 
news:MO7Qj.70230$kN5.49223@newsfe1-gui.ntli.net...
> MISRA has some good rules
> but there are a lot of bad ones as well. It's best to pick a subset - 
> the last
> time I looked at it I threw out more than half of the rules.

I totally agree; that's exactly my attitude. MISRA is good, defensive 
common sense designed by a committee ;).

Re the OP's issue: I'd isolate myself from the underlying language 
(whatever it may be) by decomposition - by encapsulating the function in 
a subroutine. A shift is a trick for a fast integer divide or mulitply 
by 2. So I'd write something like:

int  fast_divide_by_two( int )

and in the simplest case, I'd use a shift. On MISRA, I'd use something 
more complex - but it'd still be readable, since my intention is clear. 
(Hell, use a macro if you prefer. Hell, factor it out and make it 
platform-specific. Hell, so long as it's clear, I don't care about 
complex - I can always decompose it out.)

/me now poorer by 2c

Steve