LdB
Posts: 1143
Joined: Wed Dec 07, 2016 2:29 pm

Re: Writing clean code isn't hard!

Tue Jun 06, 2017 5:12 pm

Yeah I used to be able to do that and then a couple of clients went to the later version 2004.

Even things like post and pre-increment technically have to be in brackets for clarity
for (i = 0; i < 10; (i++)){
}

Everytime I see it it looks wrong :-)

You can see some samples from (https://www.misra.org.uk/forum/viewtopic.php?t=470)
Look carefully at them
(1) (*p)++; /* Compliant */
(2) a++; /* Compliant */
(3) my_struct.member++; /* Compliant */
(4) my_struct_ptr->member++; /* Compliant */
(5) a = b++; /* NOT Compliant */
(6) pop_value = buffer[--index]; /* NOT Compliant */
(7) buffer[index++] = push_value; /* NOT Compliant */
(8) *p1++ = *p2++; /* NOT Compliant */
(9) do { ... } while ((i--) > 0); /* NOT Compliant */
(10) sum += buffer[i++]; /* NOT Compliant */

However standards are standards I don't get a say. I can tell you how to really get around the standard, write the code on a normal C compiler but output assembler code to file. Wrapper the whole assembler code block in one C function call and give them the one line C code which will pass the Misra C .... don't tell them where you got the idea :-)
Last edited by LdB on Tue Jun 06, 2017 5:21 pm, edited 1 time in total.

jahboater
Posts: 4464
Joined: Wed Feb 04, 2015 6:38 pm

Re: Writing clean code isn't hard!

Tue Jun 06, 2017 5:21 pm

I agree - horrible! Perhaps "misra" is a contraction of "miserable" :)

I assume its because they have side effects.
Like foo( ++i, ++i ) would be bad for obvious reasons.
Last edited by jahboater on Tue Jun 06, 2017 5:23 pm, edited 1 time in total.

LdB
Posts: 1143
Joined: Wed Dec 07, 2016 2:29 pm

Re: Writing clean code isn't hard!

Tue Jun 06, 2017 5:22 pm

Yep in trying to remove what really is bad coding they block what most of us would consider pretty reasonable code.

I found it time consuming to get compliant code and had to cost it differently. So yeah if you get anyone who wants the standard you are now a little more aware.

User avatar
PeterO
Posts: 4732
Joined: Sun Jul 22, 2012 4:14 pm

Re: Writing clean code isn't hard!

Tue Jun 06, 2017 5:36 pm

https://en.wikipedia.org/wiki/MISRA_C
From the "criticisms" section at the bottom :
"A study at the TU Delft, by Cathal Boogerd and Leon Moonen, empirically assesses the value of MISRA C:2004. It comes to similar results:[21]

"From the data obtained, we can make the following key observations. First, there are 9 out of 72 rules for which violations were observed that perform significantly better (α = 0.05) than a random predictor at locating fault-related lines. The true positive rates for these rules range from 24-100%. Second, we observed a negative correlation between MISRA rule violations and observed faults. In addition, 29 out of 72 rules had a zero true positive rate. Taken together with Adams’ observation that all modifications have a non-zero probability of introducing a fault, this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable."
I always thought coding standards were written by poor programmers to make sure their code looked OK :D

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

jahboater
Posts: 4464
Joined: Wed Feb 04, 2015 6:38 pm

Re: Writing clean code isn't hard!

Tue Jun 06, 2017 5:53 pm

this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable."
Thats worrying :-(
I hope the software in my car was written before misra came about.

I found CERT to be much more reasonable and actually helpful ...
https://www.securecoding.cert.org/confl ... g+Standard

For an example of its style: "Avoid in-band error indicators while designing interfaces." is one of its recommendations, and we have seen a few times in these forums the cost of getchar() returning EOF.

LdB
Posts: 1143
Joined: Wed Dec 07, 2016 2:29 pm

Re: Writing clean code isn't hard!

Wed Jun 07, 2017 2:31 am

I had not ever seen the criticism, which is pretty funny given the whole drive of the standard and the committee behind it. Anecdotally I would say the bug ratio is higher because many programmers are forced to use a style they are not comfortable with (I know I am for one). So the standard has to first make up ground from a negative position of programmer error. I definitely make errors when coding in MISRA C that I wouldn't make if I could code in my normal style.

I would agree with Peter O but I will get growled at, so I will take the diplomatic approach and say not all C/C++ standards are equal :-)

Now can I have my write-only register and volatile fixed please committee people, pretty please with sugar on top.

User avatar
PeterO
Posts: 4732
Joined: Sun Jul 22, 2012 4:14 pm

Re: Writing clean code isn't hard!

Wed Jun 07, 2017 6:53 am

LdB wrote:Now can I have my write-only register and volatile fixed please committee people, pretty please with sugar on top.
Only if I can have my "lets talk about the finer points of C programming" thread back !
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

YCN-
Posts: 246
Joined: Fri Jun 10, 2016 3:18 pm

Re: Writing clean code isn't hard!

Wed Jun 07, 2017 8:06 am

LdB wrote: Volatile doesn't apply to a memory space in C it's dealt with by the optimizer, if you like it's a command to do with optimizing to the type it's assigned to.

So you have to apply volatile to every which way you access the memory space.
Do you have any official sources that back you up ? I'd never heard of it and I tried to find more info about what you're saying but couldn't.
For now I've seen a lot of drivers that uses volatile pointers for memory registers. I do it too and I never faced any bugs, I might possibly be lucky. But in the same time I'm really wondering if I'm wrong, and I'd like to have official stuff explaining this to me. In my mind if you do :

Code: Select all

volatile int * A; 
Then map it to memory or whatever, then the whole memory space is volatile hence from A[0] to where it was kalloc/malloc/mmaped (and cast to volatile int * when malloced) , I don't see why sudenly it wouldn't be volatile anymore.If it's volatile by definition at execution time the value of A[x] will be read where it really is.
In my mind we're doing what you're saying for two reason, the first one is for clarity, it's more understandable when registers are named with theire "functionnal name". The other one is that if you didn't volatile stuff inside the structure developpers can forget to declare volatile the struct whereas when doing volatile inside of it you're sure that it's gonna be.

For instance whether I do

Code: Select all

struct A_v {
       volatile int B;
       volatile int C;
}
or

Code: Select all

struct A {
       int B;
      int C;
}
and declare the register as follow :

Code: Select all

volatile struct * A my_register ;
struct A_v * my_register2;
It should be the same ? Am I wrong?

YCN-
Last edited by YCN- on Wed Jun 07, 2017 1:50 pm, edited 1 time in total.

LdB
Posts: 1143
Joined: Wed Dec 07, 2016 2:29 pm

Re: Writing clean code isn't hard!

Wed Jun 07, 2017 1:44 pm

You are strictly wrong they are not the same and in some situations on some compilers the difference is fatal. However you are also most likely right :-)

I can't tell you if and how they are different until you show me how you intend to use the pointers there is a subtlety here. However in general If an aggregate type is volatile, the effect is the same as making all members volatile so they are likely the same. The problem in never the definition it is the use that causes the problem, things like the C standard explicitly stating that a program’s behavior is undefined if you access a volatile object through an unqualified pointer.

For a solid reference on volatile I would highly recommend Prof John Regehr
https://blog.regehr.org/archives/28
He for example does a lot of the checking on the Linux source driver files.

After reading the article you may now want to look at a version of your code you probably use

struct A {
int B;
int C;
};

volatile struct A* A;

void test (void) {
while ((*A).B == 0) { };
}

What do you expect the code of function test to produce and is your result guaranteed?
I would hope that most compilers do what we expect with that because it is a rather trivial example but there are notable exceptions.

The problem with the Pi USB register definition I gave you is the bitfields are themselves interesting under C. The definition I gave you is not something I created it is a reference code (designware.h) and contains the definitions pertaining to the DesignWare USB OTG controller from Designware and provided by Synopsys. They do it because they need to cover the code could be compiled on a number of different compilers. I suspect they have had troubles like all of us in the embedded market have and it's better to be safe than sorry.

I saw an article earlier this year by Andrew Kelley where he was sending that reference code thru a Clang compiler which they never would have expected.
http://andrewkelley.me/post/a-better-wa ... ields.html

Likely you don't use the word enough to run into the problems and that is a good thing and why we would like some of this stuff clarified in the standard. I don't think we should have to write volatile abominations just in case we use a different compiler that treats the situation differently.

jahboater
Posts: 4464
Joined: Wed Feb 04, 2015 6:38 pm

Re: Writing clean code isn't hard!

Thu Jun 08, 2017 8:15 am

Back to posting clean code ...
Perhaps we need a sticky like this:-

https://stackoverflow.com/help/mcve

Minimal, Complete, and Verifiable examples.

YCN-
Posts: 246
Joined: Fri Jun 10, 2016 3:18 pm

Re: Writing clean code isn't hard!

Thu Jun 08, 2017 8:29 am

LdB wrote:You are strictly wrong they are not the same and in some situations on some compilers the difference is fatal. However you are also most likely right :-)
Ahah thanks for the links, I'm reading them now. As you said I would rather feel "safe than sorry"!

YCN-

User avatar
stefanv
Posts: 36
Joined: Wed Oct 19, 2016 12:08 pm
Location: Ontario, Canada
Contact: Website

Re: Writing clean code isn't hard!

Thu Jun 08, 2017 5:06 pm

PeterO wrote:
stefanv wrote:
PeterO wrote:Adding a totally pointless prototype just before the actual function stops the warning message!
I think that the compiler is correct in complaining. What if you were to call this function from another file? Then you would need the prototype (in a header file #Included by both). The real issue here is that you are writing global functions. If you really are taking care to define the function before using it in the same file, then presumably the function is only intended to be used in that file, and should be declared static. What the compiler is really complaining about, and rightly so, is that, "this function could be used globally, but there's no prototype allowing that to be done safely".

Stefan
(programming in C since '86)
I take your point about making functions static if they aren't used globally, but I still prefer the compiler not to complain about things that could be a problem until it actually finds some code where they are an problem. It should not be trying to second guess about code it hasn't seen ! It is essentially saying "You've defined this function as a global, but I've not seen it used that way yet but I'm still going to complain about it even if you don't ever use it that way".

PeterO
The compiler can't know that it isn't a problem since it can't know if you're using the function in file B while it's compiling file A. One of the side effects of separate compilation.
Stefan Vorkoetter: Programmer, hobbyist, amateur watchmaker, pilot, and collector of fountain pens, slide rules, calculators, and watches.

User avatar
PeterO
Posts: 4732
Joined: Sun Jul 22, 2012 4:14 pm

Re: Writing clean code isn't hard!

Thu Jun 08, 2017 5:19 pm

stefanv wrote:One of the side effects of separate compilation.
Now that I've gotten use to the right way to do it I don't have a problem with this any more,.. Move along... Nothing to dee here ;) .

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
stefanv
Posts: 36
Joined: Wed Oct 19, 2016 12:08 pm
Location: Ontario, Canada
Contact: Website

Re: Writing clean code isn't hard!

Thu Jun 08, 2017 5:23 pm

I think it boils down to: Writing clean code isn't hard; cleaning dirty code is. :-)

BTW, the project I've been working on during the course of my career was originally written in B, then ported to C shortly before I came along (but still looked very B-like), and has recently been made C++ compliant.
Stefan Vorkoetter: Programmer, hobbyist, amateur watchmaker, pilot, and collector of fountain pens, slide rules, calculators, and watches.

Return to “C/C++”