engineering ethics (it was [SOLVED] funny CC)

[tggzzz]

cannot expain why

and can you explain why MISRA-C must be applied ?

e.g.
why on the why do I have to do a lot of "code refactoring" (which is extremely boring) in order to
1) replace multiple "return" with just one "return" at the end of the function body ?
2) remove "break" and "continue" ?

my boss, our customers, fanny people in avionics
but yes, if you can employ me, I will change my job 

If you are working in avionics and you don't viscerally understand why MISRA or something similar is mandated, then you would benefit from researching what has been found to be common causes of programming error. Or move to a different industry.

Consider reading comp.risks, or its archive at http://catless.ncl.ac.uk/Risks For the last 30 years it has been a low-volume high-quality discussion of the ways in which technology fails in the real world, especially computer-based technology.

[0xdeadbeef]

This is more idiomatic c:

        while(p_btree->context.queue) { ... }

In fact, I never compare against NULL or 0, and even when assigning a null pointer, I prefer to just use a 0, which is what NULL is defined as, anyway, unless a maniac did something else.

In c++11, nullptr solves the annoying problem of overloaded functions that might take a pointer or an integer, so I'd use that in that circumstance.

Usually NULL is defined as void pointer ((void*)0) and in most environment with coding rules, the direct assignment or comparison between pointer and integer is forbidden or at least considered dangerous.
E.g. code checking tools like PC-Lint will give you a warning/error for this (depending on its settings).
Also generally, conditionals are considered to be boolean, so "if (pointer)" is a double coding rule violation while "if (pointer != NULL)" is a boolean and a comparison between two pointers and thus OK.
Note that languages with stricter syntax as Java generally only allow booleans to be used as conditionals. The lack of a true boolean type in C is usually considered a flaw.

[legacy]

If you are working in avionics and you don't viscerally understand why MISRA

I know what I need to know: I have to do source code refactoring
instead of ranting against MISRA + DO178/A + MIL STD rules 

but the question is to you, can YOU explain to me ?
people usually react with rants against the idiomatic violation
and I want to know if they have a reasonable explanation

[legacy]

"if (pointer)" is a double coding rule violation while "if (pointer != NULL)" is a boolean and a comparison between two pointers and thus OK

exactly, we have converted the C language into "strong type"
there are constraints about that (practically QAC rules)

[grumpydoc]

Usually NULL is defined as void pointer ((void*)0) and in most environment with coding rules, the direct assignment or comparison between pointer and integer is forbidden or at least considered dangerous.

In C converting "0" to a pointer guaranteeably gives a null pointer so strictly convolutions such as (void *)0 are not needed *except* in the case of function parameters where there is no prototype i scope (i.e old K&R C because prototypes should be mandatory these days).

Personally I prefer to use plain 0 or (type *)0 and avoid (void *)0 unless the function is prototyped that way.

[grumpydoc]

That's doesn't surprise me that the coding standard ask to use keyword instead of "==" or "&&" just to prevent any possible error, that does not surprise me that you HAVE to explicitly check for "while(xxx notEqual NULL)" instead of "while(xxx)"

As pointed, look at the MISRA-C reference, and find people that work on avionic software development, they are really strict on the coding standard.

Yes, Avionics is "different"

MISRA-C (at least the 2004 guidelines which is the only version that I can find online) does mandate explicit tests against 0 - i.e  if(x == 0)..., rather than if (x)..... but nowhere can I see it mandating turning C into some other language by providing insane #defines for logical operators.

I've never used MIRSA on a project but glancing through the rules in the 2004 guidelines there is little that I would object to and most seems perfectly sensible - indeed the sort of thing I wrote into coding standards when I was involved in that sort of thing. No unions is about the only rule I really went "huh?" at.

[Jeroen3]

I've read some of that 2004 misra too. They are very right in most cases. But some are damn well annoying. Like only using /* */, are you kidding?

Doesn't OP's style of coding violate rule number 1.1?
But to be honest, it's not the worst style of coding I've seen. I've seen some people write code, but they named all variables and functions "henk" with some digits.
There is also: http://www.ioccc.org/

[Godzil]

I've read some of that 2004 misra too. They are very right in most cases. But some are damn well annoying. Like only using /* */, are you kidding?

No they are not kidding, the C++ style comment (the infamous //) have numerous problem, that a lot of text editor at time (and even now) could break your code just by putting a stupid CR/CRLF/LF at the wrong place, especially in a comment.

It's a really good habbit to use /* */ instead of // and keep // for really short comment or not use them at all.

There are clearly a lot of coding standard that forbid the use of //

[Phoenix]

I've read some of that 2004 misra too. They are very right in most cases. But some are damn well annoying. Like only using /* */, are you kidding?

It's actually because // isn't part of C90 (which MISRA-C 2004 uses). MISRA-C 2012 uses C99 which has //, but with restrictions on how it's used.

[djacobow]

Usually NULL is defined as void pointer ((void*)0) and in most environment with coding rules, the direct assignment or comparison between pointer and integer is forbidden or at least considered dangerous.

In C converting "0" to a pointer guaranteeably gives a null pointer so strictly convolutions such as (void *)0 are not needed *except* in the case of function parameters where there is no prototype i scope (i.e old K&R C because prototypes should be mandatory these days).

Personally I prefer to use plain 0 or (type *)0 and avoid (void *)0 unless the function is prototyped that way.

Which was my point, too. I much prefer to see the plain 0.

By the way, in c++ (not c) NULL is generally NOT defined as (void *)0, but just as regular old 0. Many of us compile c code with c++ compilers, or compilers that are in c++ mode, so it's worth knowing.

[0xdeadbeef]

Comparing or assigning different types is considered dangerous and bad style. A static code checker like PC-Lint will complain about assigning an integer to a pointer without a cast - as it will complain assigning different pointer types. Depending on how strict your coding rules are and what possible platforms you have to consider even assigning an immediate to an integer without a cast can be forbidden. Just like a lot of other things covered by MISRA and the like.

[AlfBaz]

Many of us compile c code with c++ compilers, or compilers that are in c++ mode, so it's worth knowing.

Very much this

In these coding style discussions you hardly ever see anybody talk about compiler options. Not much point in pedantic coding if you don't know what the compiler is doing

[tggzzz]

In these coding style discussions you hardly ever see anybody talk about compiler options. Not much point in pedantic coding if you don't know what the compiler is doing

+1, very much so.

Since the compiler options can completely change the functioning of the code, they really, really ought to be regarded as part of the code.

But then the problem is that what they do changes as the compiler is "improved" as newer versions materialise - so you are stuck with using a single version of a single compiler. The only way out of that is to have unrealistically good unit tests and regression tests, and to believe that you can "test quality into a product".

For the youngsters out there, it used to be axiomatic that you cannot test quality into a product, you can only design quality into a product.

[westfw]

there is a profile file (.bat?) in the bin path which has the following line

Code: [Select]

SET  ev_shortcircuit 0

So, is changing that "ok", or do you have to go through a massive process to prove/qualify/justify changing it?  Ie, do "we" have any clue why someone turned it off in the first place?

[legacy]

So, is changing that "ok", or do you have to go through a massive process to prove/qualify/justify changing it?  Ie, do "we" have any clue why someone turned it off in the first place?

good question, probably a mistake (I guess), but I have to be sure so I will check, also because I have to be authorized to change the environment.

[legacy]

gcc has these interesting flags

Code: [Select]

-ansi -pedantic -Wall -W


[grumpydoc]

gcc has these interesting flags

Code: [Select]

-ansi -pedantic -Wall -W


You forgot -Werror (and -W properly should be -Wextra)

A static code checker like PC-Lint will complain about assigning an integer to a pointer without a

True but if it complains about type *ptr = 0; then it is broken.

[richardman]

The integer value 0, when used in a data pointer context, is implicitly converted to the null pointer, which may or may not have the bit representation of all zero bits. Th has been in Standard C since C90, I believe. Any #define you see with (void *)0 or similar construct are unnecessary and muddle the water.

C can be written in elegant, concise manner. Bad C programmers write bad C programs and then blame it on the language is a common problem.

[legacy]

Bad C programmers write bad C programs

have you ever locked at the K&R implementation of malloc?

[grumpydoc]

The integer value 0, when used in a data pointer context, is implicitly converted to the null pointer, which may or may not have the bit representation of all zero bits. Th has been in Standard C since C90, I believe. Any #define you see with (void *)0 or similar construct are unnecessary and muddle the water.

+1

In fact it has been standard since K&R

Where the (void *)0 construct came into use was old style K&R code without function prototypes. If the null pointer was a function call argument the compiler would not be aware of the pointer context so saying (void *)0 was used to specify a null pointer - just in case the representation was not all bits 0.

With function prototypes there is no need for this but it has hung around.

C can be written in elegant, concise manner. Bad C programmers write bad C programs and then blame it on the language is a common problem.

+ several hundred.

[legacy]

Not much point in pedantic coding if you don't know what the compiler is doing

there is a development phase called "trust"

practically speaking you have to verify what the compiler does, forcing the compiler to the assembly
(e.g. gcc $flags -S source.c -o source.asm, flags=optimization level? -O0? -O1? -O2? -O3? -OS? )
and then analyzing it, code-statement per code-statement

(if you are the "trust-verifier dude" you also have a lot of documentation to write)

it's boring, but it's required by the "life cycle process in Avionics" (explained this way, by my Boss)

so It smells that someone has deliberately disabled the "short-circuits" feature in SierraC
if this is true (I have to find and check its documentation), I'd like to know WHY?

[tggzzz]

Not much point in pedantic coding if you don't know what the compiler is doing

there is a development phase called "trust"

practically speaking you have to verify what the compiler does, forcing the compiler to the assembly
(e.g. gcc $flags -S source.c -o source.asm, flags=optimization level? -O0? -O1? -O2? -O3? -OS? )
and then analyzing it, code-statement per code-statement

(if you are the "trust-verifier dude" you also have a lot of documentation to write)

it's boring, but it's required by the "life cycle process in Avionics" (explained this way, by my Boss)

so It smells that someone has deliberately disabled the "short-circuits" feature in SierraC
if this is true (I have to find and check its documentation), I'd like to know WHY?

You would be wise to ensure your boss is aware of what you are doing and why. Put it in writing and get it in writing, and keep a copy off-site.

I know of people in aviation that have been sacked because paperwork was partially filled out (i.e. not completed let alone submitted) in the wrong order. Not good at the end of a career with a large pension entitlement. EDIT: change that to "one person".

[Godzil]

Not much point in pedantic coding if you don't know what the compiler is doing

there is a development phase called "trust"

practically speaking you have to verify what the compiler does, forcing the compiler to the assembly
(e.g. gcc $flags -S source.c -o source.asm, flags=optimization level? -O0? -O1? -O2? -O3? -OS? )
and then analyzing it, code-statement per code-statement

(if you are the "trust-verifier dude" you also have a lot of documentation to write)

it's boring, but it's required by the "life cycle process in Avionics" (explained this way, by my Boss)

so It smells that someone has deliberately disabled the "short-circuits" feature in SierraC
if this is true (I have to find and check its documentation), I'd like to know WHY?

I'm quite certain it has been done on purpose and in fact SierraC has may be choose because of that option.
That would make sure that ALL the test in an if are evaluated, that's sound stupid, but I'm nearly sure as this domain need everything to be provable that it need to evaluate all the tests.

(Or someone did a "smart trick" of calling a function in a if statement, and that function need to be called even is the first test fail, like a :

Code: [Select]

if ( (empty == 0) && (NeedToRunFunction() == 1) )
If empty is equal to 0, NeedToRunFunction is not warranted to be run at all.

[richardman]

Bad C programmers write bad C programs

have you ever locked at the K&R implementation of malloc?

What about it? It's a simple first fit algorithm. I tend to use pointer to pointer to manage lists, but so what?

[legacy]

What about it? It's a simple first fit algorithm. I tend to use pointer to pointer to manage lists, but so what?

just to be polite, what was published in the first edition of K&R book (and then removed) seems written by the last jerk child on Earth: see the comments by who has rewritten it in the decent way!