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

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

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.

... snip ...

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.

In message , Steve at fivetrees writes

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
  formatting link

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

In message , Steve at fivetrees writes

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:

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

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

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!

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

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

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...

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.

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.

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.

I never said goto should be used in this instance.

In most cases, yes. But see above.

Avoiding

Well said!! Agree with that 100%.

R.

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..

In message , Richard Phillips writes

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)

If we can raise the level of the masses by 1 or 2 points then that is a worth while goal.

I agree.

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.

There will always be an exception. Only Death and Taxes are inviolate.

If I read ISO 9899:1999 correctly, they have to be the same.

Im quite optimistic that, in year 18 after ISO C, pre-standard preprocessors have fallen into disuse :-)

Stefan

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

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

Hans-Bernhard Bröker schrieb:

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:

Nils

Absolutely NOT.

(Which C standard? )