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

In message , Steve at fivetrees writes

Not so. There are no absolutes. There are occasions when the goto is useful. Not often which is why MISRA-C bans goto. It you think you have one of the few odd places where it is needed then deviate.

Yes. And these people spend their lives doing code analysis and looking at errors. The problem is "everybody knows" goto is bad... no one has actually shown any solid evidence that it is. Anecdotal yes but mathematical, statistical etc evidence: no.

I have seen some discussions by Les Hatton on this.

I couldn't agree more (but please don't mention "open-source" it gets the religious nutters going)

Actually those who are saying there is no proof that goto is bad understand more than you and I put together. They spend their lives on this sort of thing.

Whilst everyone has (should have) a gut feeling that go to is bad there is no empirical evidence as there is for other things. I would be delighted if you could provide some. Your anecdote above is just that. Not solid evidence.

Goto CAN be used safely. However those who would use it safely tend not to use it at all. Those who do use it do not use it well.

That was not the problem. In some cases to remove a goto the resulting structure is horribly convoluted and unreadable. It was readability and elegance of design. However these situations are few and far between

The structured programming revolution of the '70s has cleaned up to the point that few people have seen goto-based code. For proof by personal revelation, check

It's actually a good program for its day, pre Boehm and Jacopini. Trying to make a change, finding a certain place to put new code, is surprisingly hard -- not impossible, of course.

Donald Knuth's vindication of some goto statements is at

Mel.

Absolutely. And it's a small price to pay. Given a choice between goto and a flag (or state) variable or two, guess which one I'd choose ;). Not because of religion, but because of clarity.

Steve

See Donald Knuth (1974). "Structured Programming with Goto Statements". Computing Surveys 6 (4): 261=96301. (e.g.,

stephen

Many thanks. I will raise this at the next MISRA-C meeting.

Isn't the point that you "de-init" everything you init, so the returns after the failed cases are wrong?

It seems to me that you could benefit from some structure here:

int init_the_big_library_lebowsky (foo *bar) { static const struct { int (*init)(foo*); void (*de_init)(void); } sys[] =3D { {init_sub_system0, de_init_subsys0,}, {init_sub_system1, de_init_subsys1,}, /* ... */ }; int i;

for (i =3D 0; i < NELEMS(sys); i++) { if (! (*sys[i].init)(bar)) { // walk back "de-initialising" everything. while (--i >=3D 0) { (*sys[i].de_init)(); } return E_ERR; } }

return E_OK; }

I wouldn't quite adopt that style in production code, but I stand by the idea. The code only needs to be made right once and adding a new "sub system" is trivial.

(I neither tested it, nor proved it correct.) stephen

Basically if some application works fine when compiled by various compilers but not if compiler X is used, then it is compiler X that is wrong, not the source code. The C standard is not relevant if this kind of issue comes up, so handing out copies of the standard doesn't help (it might be seen as an insult by paying customers - they pay you to solve their problem, not to be told to rewrite their code).

The huge amount of existing source code defines the standard that compilers must adhere to, not the official C standard. It may not be ideal, but that is the way things are. I would like to see most implementation defined behaviours explicitly defined (as compilers agree on them anyway), various undefined behaviours defined and many common compiler extensions standardized. It seems unlikely the C/C++ committees will ever do the right thing...

You're quite right that all this does is replacing one kind of implementation defined behaviour with another - however any piece of non-trivial code relies on implementation defined behaviour given the C standard is so badly defined.

As I've explained before, you can rely on most implementation defined behaviours to be implemented identically on the vast majority compilers. So the whole exercise is pointless as signed shifts work correctly in the first place.

Wilco

In message , Wilco Dijkstra writes

Commercially this is true.

I agree. Basic is a good example of this. The world revolves around VB not ISO BASIC

Absolutely. You have to work with the tools available. Standard C is not "required" anywhere which is the problem. If it was legally required to have ISO-C compliant compilers then it would be a different matter.

Rewrite their code to a theoretical standard that is not implemented by the compilers.

I agree. The standard should be regularising what we have not going off at a tangent.

I agree... though there is a light at the end of the tunnel as 10 years on virtually no one has implemented C99. However as there are a lot of moves to be MISRA-C:2004 compliant the C panels have started to realise that unless they come back to the mainstream ISO-C will become as irrelevant as ISO BASIC. .

... snip stuff on arithmetic shifts ...

If you have to build something to run on some users equipment and compiled on his compilers, that is one thing. Usually you have the choice of tools. Today most C systems make valiant efforts to be standard compatible, usually to C95, and document their failures. Some of those failures are due to the hardware proper.

I can see no reason to shift signed variables, when unsigned is available. Every piece of code you write that adheres to the standard is that much more portable, and won't need rewriting for another application.