shame on MISRA

No, it's not. While '&x[i]' requires the element i to exist (i.e. array x must have at least i+1 elements), 'x+i' doesn't. If your compiler can do array bounds checks, it will probably do that for '&x[i]', but not for 'x+i'.

Stefan

A simple, but perverse, way to do this would be to create a virtual machine, for example an x86 CPU emulator. The emulator would have to be written (once) to comply with MISRA rules. You can then take a random C program, compile it to x86 instructions, and add it as a static array to the emulator code.

This could be done within any set of rules that still leave enough power to construct a virtual machine, which is pretty much anything that still classifies as a programming language.

The answer, of course, was in the paragraph above, which you deleted: "MISRA and such are not intended to be proof against the bad guys..."

John Perry

Hmm. &x[i] does not require that x has i+1 elements. In fact it is explicitly mentioned in the standard when x has exactly i elements.

I don't think the standard has changed the fact that for a pointer (or array name) x and an integer i that

x + i == i + x == &x[i] == &i[x]

Has it?

-Rich

You're quite completely wrong there. &x[i] is required by the standard to be exactly the same as x+i, because:

The C standard says that "x + i" and "&x[i]" have the same value. However, &x[i] is only valid if x has at least i elements (not necessarily (i + 1) - the address beyond the top of the array is also valid). The compiler should generate the expected code for &x[i] with out of range i, but it is not guaranteed.

However, any good C compiler, or other C analyser like lint, will interpret "&x[i]" and "x + i" differently, as they operate on a higher level than blind code generation. On an array access, they can do a certain amount of static range checking - some C compilers may even have the option for run-time range checking. The compiler may also be able to do better alias analysis and therefore generate better code with the array access (since it knows the range the resultant pointer could take).

All this is, of course, subservient to the golden rule of writing understandable code. If "i" is an index into the array "x", then the correct form is "&x[i]" - "x + i" does not say what you mean, and is therefore bad code.

David Brown wrote: [snip]

Correct.

Not really. "Any good C compiler" could recognize "x + i" as identical to "&x[i]". In fact, whether or not pointers are involved with data flow analysis, range checking could also be done.

My favorite is 3["Hello world"] == 'l'.

Well, maybe not my favorite, but one of my top 10. ;-)

-Rich

On Mar 28, 5:49 pm, Richard Pennington wrote: [...]

My favorite, which is actually in use in code somewhere, is similar to

digit = "0123456789ABCDEF"[value & 0x0F];

Regards,

-=Dave

... snip ...

#define true ('r' == 5["foobar"]) #define false !true

That is almost the only clear and portable way to convert into hex. Routine.

Indeed. C99 says "The unary & operator returns the address of its operand. [...] If the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator."

However, if I see that correctly, neither C90 nor C++98 make that exception, making "*(x+i)" a constraint violation if x has only i elements, even if the "&" operator is applied to it afterwards.

That aside, I would assume that a normal (=not bounds-checking) compiler generates the same machine code for &x[i] and x+i anyway.

Stefan

Perhaps I might I suggest fishing, golf, stamp collecting... ;-)

I've not seen this sort of thing before - what is the method called? I'd like to find out more about it.

... snip ...

No name, just portable translation, where you can't count on ASCII encoding. The same array can be used in both directions, if you either up (or down) shift the input, or extend the array to "0123456789abcdefABCDEF".

Recently they showed me a case when the strict compliance to MISRA provoked the mistake:

Original code:

foobar() { u8 variable;

variable = something;

/* Explicit type conversion is required by MISRA. This is because of the C convention: result of any integer operation is int

variable = (u8)(variable + 1); }

Later, the code was modified. It was decided that variable should be u16.

u16 variable;

But this line was not changed:

variable = (u8)(variable + 1);

So here is a bug. No warnings.

If this would be just:

variable = variable + 1;

There would be no bug.

//---------------------------------------

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

I believe you are mistaken about not allowing integers to be used as a switch argument. The C standard says the switch argument is required to be an integer expression. Perhaps you meant to say that integers shouldn't be used as the case identifiers.

However, I quite often have situations where a portion of a value is extracted and used as an index for a switch statement. I should define:

enum integer {zero, one, two, three,...}

switch(index) { case zero: break; ... }

etc.?

I also regularly write switch statements that are using a character as the switch index/argument. I should define:

enum alpha {a, b, c, d, e,...}?

Why no warnings? What compiler? I frequently write for 'SCDE' (Standard C Development Environment') on SVR4 (C 90) and also port stuff developed by others on GCC which often produces lots of warnings about "explicit cast required" for assignments and logical comparisons which the original authors failed to qualify with a cast. Evidently these things pass 'lint' and compile in GCC with no warnings (even at a high warning level). Most authors are dumbstruck by the need to explicitly cast (sometimes even numeric constants).

Regards,

Michael

The point being ?. Would you expect to get a usefull book for nothing that someone has spent considerable time and effort to produce, or should everything be open source and free ?. Of course, including all your own work.

Now that it's a sane price, have just downloaded the misra pdf version and am almost disappointed in that there's almost nothing that I can disagree with. Having seen so much controversy about it etc. In fact, it seems a bit lightweight, just good common sense practice that one would expect from any experienced embedded engineer.

The C++ version should be quite interesting...

Chris

Hopefully by the end of the year.