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

Oh, but it is. Casting from signed to unsigned operates modulo (UINT_MAX+1) (C99 6.3.1.3p2).

It's the other way round that isn't well-defined. The result of casting an unsigned number above INT_MAX to integer is implementation-defined.

The same thing. The conversion is independent on representation.

int foo( /* whatever */ ) { int errmk = 0; FILE *f1, *f2, *fw; if (!(f1 = fopen(f1name, "r")) { errmk = 1; } else { if (!(f2 = fopen(f2name, "r")) { errmk = 2; } else { if (!(fw = fopen(fwname, "w")) { errmk = 3; } else { /* Files open */ fputs(fwendln, fw); fclose(fw); }; fclose(f2); }; fclose(f1); }; return errmk; }

Unless you are using a 40-character wide screen, that version is at least as good as your "goto" version. I've seen people claim that they "need" goto's to write good code - I've never actually had the need of one in anything I've written. I've done other "bad" things, such as "return" in the middle of loops, but I think "goto" is a bit more unstructured than that. Once you start doing things like jumping in and out of variable scopes with goto, you are asking for trouble (inefficient code, or even incorrect code). I don't mean to say that all goto's are wrong - just that you'd better have a much better excuse than that function before using it.

They are supposed to be and likely are the same.

I know at least one commercial compiler that has the preprocessor right and the run time wrong. It was released by a company that should know better and has been doing this for quite a few years.

Their license doesn't allow benchmark information to be released without their permission.

w..

I know that, but I didn't write that. I suspect I snipped in the wrong places. Yes, my above answer is nonsense.

Same silly reply from me. Sorry for the foul-up.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.


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

Since MISRA is organized around C90/95, that standard.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.


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

... snip ...

(I have taken liberties reformatting your quote above.)

Well, I did say mine was an outline. In practice I would probably write that the way you did. I guess I wasn't too clear, but I was trying to illustrate a clear way of using goto with forward jumps.

I'm lazy and don't use it, but I consider goto clearer than break.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.


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

I can't speak for the original poster, but for some signal processing applications, arithmetic-right-shift as a 'division by power of two' is better than an explicit actual division by a power of two *because* of the consistent round-to-negative-infinity behaviour. Round-towards-zero, which is the standard for signed integer division in C, produces an uneven quantization interval around zero, compared to that between all other adjacent integers. This results in significantly (3dB RMS) more noise than properly-rounded ASR, unless you go to the bother of adding a negative rounding constant when the number is negative.

Cheers,

--
Andrew

Only in C. They're well defined by the processor architecture manuals of all processors that provide them, and that I am aware of. Probably many others besides. What's more, these behaviours are, in my experience, consistent. Since we're all some-time assembly language programmers here in c.a.e, I am not at all surprised that we bridle that expected behaviour is not supported by the standard. I know that it bugs me.

Cheers,

--
Andrew

Then you have a complete lack of understanding of the subject and the standards.

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

Liberties indeed - it is rare that I would write a statement of the form "if (x) y;" without brackets, and I consider it downright foolish to omit the brackets when using "else". The scope for getting your else's out of synchronisation with your if's is just far too great.

A forward goto is often a choice for breaking out of nested loops, where a break won't work. Personally, I'd prefer to split the code into a separate function (if you have a situation like this, your function is probably too long anyway) and use a return from within the loop, but that's a matter of choice.

Which just so happens to be the subject matter.

... snip ...

I can smell the exclamation marks after 'indeed'. :-) However, look at it again. Notice that the elses are tightly associated with the appropriate ifs. At any point following indentation up exposes the controlling statement. I maintain it is hard to misread the flow. It is also vertically compact, which I consider an advantage (and was the primary reason for the reformat).

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.


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

I have. Old MPW C did a 16-bit signed shift as unsigned, using some special 68K operation. I forget the details. That's when I discovered they were undefined.

Isn't integer division of negative dividends allowed to truncate to zero or to truncate less. (-1/2 == 0 or ==-1).

--
	mac the naïf

Alex Colvin schrieb:

There was an issue with this as well. I remember having worked on a MetroWerks compiler in my game-development days that made signed divisions different to any other compiler.

Those guys also messed up switches with negative cases and other stuff as well though. It seems to me like they had big problems with signed/unsigned in general.

Don't know how MetroWerks is today. Back 8 years it was a horrible piece of junk.

Nils

Don't confuse "undefined by the standard" with "undefined, period". One of the differences between good tools and merely useful tools is the quality of the documentation. Amongst other things, this includes defining undefined behaviour. It's worth going through to make yourself aware of any areas where the compiler works in a way you don't expect, so you can watch out for those particular cases when undefined behaviour slips in by mistake. Of course, merely reading through that portion increases awareness of undefined aspects in the first place which can only be a good thing.

I have hazy memories of the release notes for an old SCO compiler including a note to the effect of "The previous version did this in the undefined case where ..., the new version does something else instead", but can't be bothered digging out the manuals to find an exact reference now.

--
Andrew Smallshaw
andrews@sdf.lonestar.org

It was in C90 and successors. As of C99, it's required to truncate towards zero. I have serious doubts that was a good idea.

Ooh. That's truly horrible - but the underlying logic isn't, it's just coded horribly.

I'd probably write that as:

int foo( /* whatever */ ) { int errmk = 0; FILE *f1, *f2, *fw; BOOL f1_open = FALSE, f2_open = FALSE, fw_open = FALSE;

if ( errmk == 0 ) { if ( !( f1 = fopen( f1name, "r" )) errmk = 1; else f1_open = TRUE; }

if ( errmk == 0 ) { if ( !( f2 = fopen( f2name, "r" )) errmk = 2; else f2_open = TRUE; }

if ( errmk == 0 ) { if ( !(fw = fopen( fwname, "w" )) errmk = 3; else fw_open = TRUE; }

if ( errmk == 0 ) { /* files open, play appropriate games */ fputs( fwendln, fw ); }

if ( fw_open ) fclose( fw ); if ( f2_open ) fclose( f2 ); if ( f1_open ) fclose( f1 ); return( errmk ); }

Note that I've defended myself from code changes - I can move things around, and the initial tests and the final closures are independent of any such changes.

Note also that I just can't be doing with this opening-brace-on-end-of-line heresy: braces should visually line up, and that's the end of it ;).

YMMV ;).

Steve

There are plenty of ways of doing exactly this without using gotos (e.g. state machines). I've not used a goto in nearly 30 years, and I pride myself on clean, readable code. I do a lot of comms, so I know whereof you speak - but I think you're missing a load of tricks (e.g. separate validation from use - decompose).

Again: it's about the logic, not necessarily the implementation.

Steve

Sorry, but I disagree. There are always - ALWAYS - logically-equivalent structured alternatives to goto, which will not bite your ass anywhere near as badly.

Ignoring the "intestinally": you're kidding!

I've said this elsewhere, but the acid test is: if you can't look at a section of code and know how you got there, WARNING. Therein is the danger of goto. You say that people are seriously questioning this? FFS... are they questioning synchronous logic design too?

Agreed.

Ah - you mean a self-fulfilling prophecy.

No. 2 or 3 years back I had to review the code of a certain engineer who was not subject to normal peer review on the basis of his, errr, "adherence to open-source methods". Turned out this was a smokescreen. His main() was over

2000 lines long, and was peppered with gotos. Summary - he was a crap coder. I see this a lot - crap coders are crap coders, period. There are good reasons for objecting to goto - Dijkstra was no fool. Those who use goto simply don't understand the subject very well.

Steve (ducking and running)