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

"Richard Phillips" <raphillips@ntlworld.com> wrote in message 
news:kukQj.59491$h65.48326@newsfe2-gui.ntli.net...
> * 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.
>
> * You're not supposed to exit from a controlled loop prematurely.

Avoiding "goto" means avoiding unstructured design (i.e. using only only 
closed structures - one start, one end, any other context signalled by 
other means than programme flow).

Exiting a control loop prematurely is not a case of a goto - it's still 
a case of one start, one end. It just avoids a layer of indenting and 
promotes readability.

Things like jump tables are not lists of gotos - they're a list of 
(derefenced, if you insist) function pointers.

Summary: avoiding goto as a design concept is a Good Thing. Avoiding 
gotos as a means of implementing good structure is simply 
misunderstanding the point. I've seen (possibly on this ng) someone 
defending goto on the basis that CPUs only know about branches and jumps 
anyway. Follocks.

 It's *not* about implementation. It's about design. If you use gotos to 
implement an IF THEN ELSE ENDIF structure, I could care less. It's still 
structured.

Bottom line: uncontrolled program flow is a Bad Thing. If you can't look 
at a chunk of code and know the answer to the question "How did I get 
here?" - warning!

Steve
(another 2c poorer) 

"Stefan Reuther" <stefan.news@arcor.de> wrote in message 
news:futb8o.e8.1@stefan.msgid.phost.de...
> Nils wrote:
>> But do you do if you need them anyway? I need *lots* of them, so in
>> despair I've just created this monster of unreadable code:
>>
>> int ArithmeticShiftRight (int value, unsigned int shift)
>> {
>      /* Not sure whether that passes your MISRA checker: */
>      return (int) ((unsigned long long) value >> shift);
>> }
>
> That aside, MISRA usually allows you to deviate from a rule if you 
> have
> a good reason. This is to make you think about whether you really need
> it. Arithmetic shifts would be a good thing to answer "yes" to that
> question.
>
> The function could finally even look like this:
>  int ArithmeticShiftRight (int value, unsigned int shift)
>  {
>  #if ((-1) >> 1) == -1
>     return value >> shift;
>  #else
>  #  error Port me!
>  #endif
>  }
> which would make your code portable under all practical definitions
> known to me.

I totally agree - I do exactly this as a matter of routine. I strongly 
encourage the use of macro-level platform traps which say "if this isn't 
the platform I made allowances for and assumptions about, then yell - 
don't just compile incorrectly".

Steve

On 2008-04-25, Nils <n.pipenbrinck@cubic.org> wrote:
> Hans-Bernhard Br&#4294967295;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?

For the same reason that CPUs have a logical shift right and an
arithmatic shift right instruction: despite the claim to the
contrary, shifting is considered by almost everybody to be an
arithmetic operation.

-- 
Grant Edwards                   grante             Yow!  I was giving HAIR
                                  at               CUTS to th' SAUCER PEOPLE
                               visi.com            ... I'm CLEAN!!

Steve at fivetrees wrote:
> 
... snip ...
> 
> Avoiding "goto" means avoiding unstructured design (i.e. using
> only only closed structures - one start, one end, any other
> context signalled by other means than programme flow).
> 
> Exiting a control loop prematurely is not a case of a goto -
> it's still a case of one start, one end. It just avoids a layer
> of indenting and promotes readability.
> 
> Things like jump tables are not lists of gotos - they're a list
> of (derefenced, if you insist) function pointers.
> 
> Summary: avoiding goto as a design concept is a Good Thing.
> Avoiding gotos as a means of implementing good structure is
> simply misunderstanding the point. I've seen (possibly on this
> ng) someone defending goto on the basis that CPUs only know
> about branches and jumps anyway. Follocks.

Not according to me.  Consider the following function outline:

int foo( /* whatever */ ) {
   int errmk = 0;
   FILE *f1, *f2, *fw;

   if      (!(f1 = fopen(f1name, "r")) {
      errmk = 1; goto f1bad;
   }
   else if (!(f2 = fopen(f2name, "r")) {
      errmk = 2; goto f2bad;
   }
   else if (!(fw = fopen(fwname, "w")) {
      errmk = 3;  goto fwbad;
   }
   else {
      /* files open, play appropriate games */
   }
   fputs(fwendln, fw);
   fclose(fw);
fwbad:
   fclose(f2);
f2bad:
   fclose(f1);
f1bad:
   return errmk;
}
 
There are lots of undetected errors left, that is an outline.  Yes,
there are other ways to handle it.  

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

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

In message <6_6dnY2wrOW5-4_VnZ2dnUVZ8uGdnZ2d@pipex.net>, Steve at 
fivetrees <steve@NOSPAMTAfivetrees.com> writes
>"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 ;).

I agree... It would be perfect but the others on the committee get in my 
way :-)

The MISRA-C* rules are Engineering Guidance NOT a religion.  You can 
deviate any or all of them as long as you can put up a good deviation 
that will make sense to a jury in court in 3 years time....

No I am not using scare tactics. I am trying to point out that 
deviations should not be something that (like source code) that you and 
the programmer next to you thinks makes sense now but makes no sense to 
some one else 3 weeks later. ALL Deviations should be reviewed ater a 
period of time to see if the still make sense.

* Please not "MISRA" but MISRA-C or you will confuse it with MISRA-C++ 
launched on 5th June at the Safety Critical Systems Club event in London
http://www.scsc.org.uk/diary.html?opt=detail&id=70

I can say this as the MISRA-C++ is actually finished and going to / is 
at the printers. CAVEAT:- I had nothing to do with this one! :-)

Also there are the MISRA-Guidelines (parts 1-8) published 1994 and the 
MISRA-Safety-Analyasis, and the MISRA-Autocode standards (three parts 
issued so far.) There will also be a MISRA-Languages document on common 
problems across languages


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <SuCdnb4TBovD9I_VnZ2dnUVZ8uadnZ2d@pipex.net>, Steve at 
fivetrees <steve@NOSPAMTAfivetrees.com> writes
>"Richard Phillips" <raphillips@ntlworld.com> wrote in message
>news:kukQj.59491$h65.48326@newsfe2-gui.ntli.net...
>> * 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.
>>
>> * You're not supposed to exit from a controlled loop prematurely.
>
>Avoiding "goto" means avoiding unstructured design (i.e. using only only
>closed structures - one start, one end, any other context signalled by
>other means than programme flow).

However as with all things there are a few exceptions where got is the 
cleanest solution.  In those cases you need to deviate and be able to 
stand up in court in 3 years time with your deviation.


Intestinally the "goto" is bad" came from a paper by Dykstra  (not Wilco 
:-) and AFAIK no one has really challenged it but just taken it as read. 
I know some people are doing some work into it to see if it really is 
that bad.

I suspect the trouble will be that 90% of those who want to use goto are 
the sort of people who will write appalling code anyway and 90% of those 
who think goto should be banned would only ever use it very sensibly.

So it is a self fore filling prophesy:

90% of those who want to use it should not
90% of those who could use it properly will not.

The group who want to use it and would use it properly are now a very 
small number.



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H wrote:
> In message <kukQj.59491$h65.48326@newsfe2-gui.ntli.net>, Richard
> Phillips <raphillips@ntlworld.com> writes
>>
>> 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.
>
> This is true.
>
>> 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.
>
>
> Maybe. IT was AFAIK Dykstra who said goto was bad and no one has
> challenged that with a convincing strategy for using goto. Mainly
> because the majority who do use it tend to miss use it.  So it should
> not normally be used but...
>
>> * You're not supposed to exit from a controlled loop prematurely.
>>
>> * ...  Hmm, actually I could go on for a while.  Suffice to say,
>> there are a few things...!
>
> All of the MISRA rules are good *some* of the time. Where they are not
> it is up to you to come up with a project specific reason why not.

This is fair enough.  I can see the sense behind most rules some of the 
time!

>
>> I've seen some tidy well-written code turned inside out and made
>> semi-unreadable by trying to make it MISRA compliant.
>
> I know what you mean it is the "tick the box" brigade who want to say
> we are MISRA compliant without actually using any Engineering thought
> on it.

Like I say, in my company, even though I know realise that we are allowed to 
deviate (and deviations should be documented), when I first joined I 
certainly had a different impression.  I know I wasn't the only one because 
I could see some of the crazy things others were doing in the name of MISRA. 
To my knowledge though I don't think we produce a "MISRA compliance and 
deviations" doc per project, perhaps I will suggest this next week to my 
manager!

>
>>  If it makes code more
>> complicated (and more error-prone) then it's doing the opposite of
>> what's intended.
>
> Hence MIStRAy-C A spoof on MISRA-C
>
> http://www.phaedsys.demon.co.uk/chris/mistrayc/

Thanks, I'll take a look at that...

>
>> I had a chat with a manager of mine about this once and he said
>> that MISRA was basically a guide, obey it if you can, but if there
>> is a problem with doing this then all that was needed was to
>> document the non-compliances.  For me, this is a far more sensible
>> approach.
>
> I personally believe this is the way it is meant to be used.

Makes sense to me, but I think there seems to be some misunderstanding out 
there.

>
>> Sort out
>> the obvious clangers, but don't turn good neat code into jumbled
>> unreadable rubbish just to satisfy MISRA!!
>
> Any suggestions on how the MISRA team can stop people doing this All
> methods must be legal under the UN human rights and Geneva
> conventions. Water-boarding or stringing up by their thumbs for 
> recalcitrant programmers and managers  may be deserved and satisfying
> but we can't writ it in to a coding standard :-)
>
>> The problem is there is some misunderstanding here.  MISRA lists
>> it's rules as "recommended" and "required" (or something like that),
>> which makes it sound like "required" rules MUST be obeyed, which
>> doesn't appear to be the case from what I now understand.
>
> It was required and advisory. IE those that should normally be used
> and those which are useful a lot of the time.
>
> Any suggestions for a different nomenclature?

Hmm, I'd have to have a copy of the MISRA guidelines in front of me to 
answer this properly, perhaps I'm being unfair on the guidelines because 
I've tended to look at the rules themselves rather than read the doc from 
cover to cover, if I had maybe I'd have a different impression.  Perhaps 
"required" and "advisory" are defined in there properly somewhere?
However, that said, "required" to me suggests I must obey at all times, it's 
"required" without deviation!  "Advisory" suggests to me what you say 
"required" actually means.
I'll have a read of the guidelines on Monday and have a think about this, if 
I'm going to suggest an alternative I want to make sure I put some thought 
into it...

Paul Keinanen wrote:
> 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

I was deliberately unspecific in my original post, but the one situation 
I've found a goto is a perfect solution is neatly getting out of deeply 
nested conditional code (i.e. jumping forward!).  I've found that this 
situation occurs often when dealing with communications.  Without using 
goto, you need lots of extra code to get back out.

R. 

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

Fair point.  I suppose MISRA does give a useful yardstick when measuring the 
"quality" of code.  I'll confess I hadn't looked at it from this viewpoint.

One thing I will say which you've touched upon here, is that I've tightened 
up on my code quality (not that it was deliberately bad before!) because I'm 
aware that MISRA might not like something.  I tend to write code that is 
MISRA-compliant (most of the time) without even really thinking about it 
now.
So I think on the whole, MISRA has perhaps been more useful than I give it 
credit for.  But I stand by my original arguement though; blindly following 
the rules (as I've seen done) is NOT "advisory"!

R. 

Steve at fivetrees wrote:
> "Richard Phillips" <raphillips@ntlworld.com> wrote in message
> news:kukQj.59491$h65.48326@newsfe2-gui.ntli.net...
>> * 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.
>>
>> * You're not supposed to exit from a controlled loop prematurely.
>
> Avoiding "goto" means avoiding unstructured design (i.e. using only
> only closed structures - one start, one end, any other context
> signalled by other means than programme flow).

Sorry, I think that's just wrong.  If K+R think it's ok and include it in 
the language, I think there must be some point to it.
The one case I've encountered where it's "needed" is deeply nested 
conditional code.  Often encoutered in communications, where you need to 
test lots of conditions before a packet of data is "accepted".  If the data 
is rejected at the final check, goto gets you right back out gracefully 
without lots of extra checking code.

>
> Exiting a control loop prematurely is not a case of a goto - it's
> still a case of one start, one end. It just avoids a layer of
> indenting and promotes readability.
>

I never said goto should be used in this instance.

> Things like jump tables are not lists of gotos - they're a list of
> (derefenced, if you insist) function pointers.
>
> Summary: avoiding goto as a design concept is a Good Thing.

In most cases, yes.  But see above.

Avoiding
> gotos as a means of implementing good structure is simply
> misunderstanding the point. I've seen (possibly on this ng) someone
> defending goto on the basis that CPUs only know about branches and
> jumps anyway. Follocks.
>
> It's *not* about implementation. It's about design. If you use gotos
> to implement an IF THEN ELSE ENDIF structure, I could care less. It's
> still structured.
>
> Bottom line: uncontrolled program flow is a Bad Thing. If you can't
> look at a chunk of code and know the answer to the question "How did
> I get here?" - warning!
>
> Steve
> (another 2c poorer)