EmbeddedRelated.com
Forums
Memfault State of IoT Report

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

Started by Nils April 24, 2008
"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)

Memfault State of IoT Report