Chris H wrote:> 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.Well said!! Agree with that 100%. R.
C and MISRA, blues... (arithmetic shifts)
Started by ●April 24, 2008
Reply by ●April 26, 20082008-04-26
Reply by ●April 26, 20082008-04-26
Steve at fivetrees wrote:> "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".I agree with the idea but be careful of the implementation. The math executed in #if ((-1) >> 1) == -1 is done so with the preprocessor and not the runtime environment. They may not be the same. I have seen two or three run time test routines written to identify compiler features and how they work. This would be a good place to use this type of code. I will try to track down a url reference. Walter..
Reply by ●April 26, 20082008-04-26
In message <PzDQj.70642$kN5.46880@newsfe1-gui.ntli.net>, Richard Phillips <raphillips@ntlworld.com> writes>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.This is what we were hoping for. It is a bit like Pavlovs dogs. (Bell rings-> get food:dogs salivate. evetualy dogs salivate when bell rings even if no food) If people keep getting MISRA-C errors flanged they will eventually stop writing code with MISRA-C errors in it (as much as any one write bug free SW) This saves time and effort and produces safer more reliable code faster. Static analysis such as PC-Lint will have a similar effect. BTW you should use a static analyser that checks MISRA rules not a tool that ONLY checks for MISRA rules. (See section 4.3)>So I think on the whole, MISRA has perhaps been more useful than I give it >credit for.If we can raise the level of the masses by 1 or 2 points then that is a worth while goal.> But I stand by my original arguement though; blindly following >the rules (as I've seen done) is NOT "advisory"!I agree. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●April 26, 20082008-04-26
In message <gIDQj.112578$5i5.4642@newsfe6-gui.ntli.net>, Richard Phillips <raphillips@ntlworld.com> writes>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.That is blind faith some 35 years on. The language and SW Engineering have moved a long way since then. Also C was designed as a language for expert programmers. Incidentally you do not use K&R C... There have been TWO Major revisions of C since K&R1 Things were changed to "improve" them but nothing was removed simply to keep backward compatibility even if it was not a good idea for general use. Some things in C are banned outright for safety critical or high reliability code but they are still in the base language standard.>The one case I've encountered where it's "needed"There will always be an exception. Only Death and Taxes are inviolate. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●April 26, 20082008-04-26
Walter Banks wrote:> Steve at fivetrees wrote: >>"Stefan Reuther" <stefan.news@arcor.de> wrote in message >>> #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". > > I agree with the idea but be careful of the implementation. > The math executed in > #if ((-1) >> 1) == -1 > is done so with the preprocessor and not the runtime > environment. They may not be the same.If I read ISO 9899:1999 correctly, they have to be the same. 6.10.1p3: "The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6, except that all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header <stdint.h>." 6.6p11: "The semantic rules for the evaluation of a constant expression are the same as for nonconstant expressions." Im quite optimistic that, in year 18 after ISO C, pre-standard preprocessors have fallen into disuse :-) Stefan
Reply by ●April 26, 20082008-04-26
On Fri, 25 Apr 2008 16:34:35 +0100, Chris H <chris@phaedsys.org> 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...I have only been working for more than three decades in the IT sector, so I am youngster compared to many in this NG, but the only time I have seen bad goto spaghetti code, was a factory management package written in the late 1970's in COBOL. Of course, the situation might have been much worse in the 1960's, but why make such fuss about gotos in this millennium ? Paul
Reply by ●April 26, 20082008-04-26
Walter Banks wrote:> I agree with the idea but be careful of the implementation. > The math executed in > #if ((-1) >> 1) == -1 > is done so with the preprocessor and not the runtime > environment. They may not be the same.It's way worse than that. Shifting negative values at runtime causes undefined behaviour. I.e. even if they come out the same in the test, it can suddenly behave differently in the actual program, but only if you called gettimeofday() within 2 seconds before computing (-1)>>1. And you'ld have no leg to stand on if you complained about it to the compiler maker. Undefined behaviour means that _all_ bets are off.
Reply by ●April 26, 20082008-04-26
Hans-Bernhard Br�ker wrote:> Walter Banks wrote: >> I agree with the idea but be careful of the implementation. >> The math executed in >> #if ((-1) >> 1) == -1 >> is done so with the preprocessor and not the runtime >> environment. They may not be the same. > > It's way worse than that. Shifting negative values at runtime causes > undefined behaviour. I.e. even if they come out the same in the test, > it can suddenly behave differently in the actual program, but only if > you called gettimeofday() within 2 seconds before computing (-1)>>1. And > you'ld have no leg to stand on if you complained about it to the > compiler maker. Undefined behaviour means that _all_ bets are off.'(-1) >> 1' is implementation-defined, not undefined. Implementations that define it as 'exec("/usr/games/nethack")' are rare. '1 >> (-1)' is undefined. Stefan
Reply by ●April 26, 20082008-04-26
Hans-Bernhard Br�ker schrieb:> It's way worse than that. Shifting negative values at runtime causes > undefined behaviour. I.e. even if they come out the same in the test, > it can suddenly behave differently in the actual program, but only if > you called gettimeofday() within 2 seconds before computing (-1)>>1. And > you'ld have no leg to stand on if you complained about it to the > compiler maker. Undefined behaviour means that _all_ bets are off.No - it is not undefined behaviour, it is implementation-defined behaviour. This is a big difference because any ISO-compliant compiler has to define how they handle these cases. And these behavious don't change just because you've called gettimeofday(). You can trust these definitions. The GCC manual has a nice list of them: http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/C-Implementation.html#C-Implementation Nils
Reply by ●April 26, 20082008-04-26
In message <4811F36B.FD35B43D@yahoo.com>, CBFalconer <cbfalconer@yahoo.com> writes>Richard Phillips wrote: >> >... snip ... >> >> 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. > >The only 'required' rules are those of the C standard. >Absolutely NOT. (Which C standard? ) -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/