engineering ethics (it was [SOLVED] funny CC)

[legacy]

Short circuiting expressions is part of the language

Pretty False in Avionics

C89 << MISRA C/2004 << "SafeC" (our standard)

"SafeC" (MISRA C/2004 + DO178A + MIL-STD) bans

• break
• continue
• short circuit
• multiple returns
• passing pointers by reference
• goto (if you really need you have to open a "unsafe code" section and manually justify them)
• arithmetic with pointers (you are forced to use "array")
• casting (you have to use "unchecked converters", explicitly defined in "unsafe code" sections)
• etc etc …

You can consider "Avionics/SafeC" as "another" language 

[legacy]

Model-Based Engineering with AADL (and HOOD)

someone directly or indirectly experienced with such a things?

[legacy]

I have downloaded and installed the Windows version of "Stood" (trial, features limited but "good usable" if you want to learn)
it seems to be written in Prolog 

[dmills]

I'm out of date with modern C++ but wow, WTF. That should have been shot at birth but I have a horrible feeling that the next C++ standard will add features 

Almost certainly, the C++ committee never saw a feature they didn't like.

My major problem with the langue is that everyone knows a DIFFERENT subset of it, makes building a team to work on a C++ project awful hard.

It also encourages language lawyer cleverness which is never a good thing, while I like an expressive language as much as the next guy, one should always remember that someone else will sooner or later end up doing the maintenance programming, and they may well know a different subset.

Regards, Dan.

[legacy]

I haven't understood if we are allowed to use "restrict" (C99 feature) 

[grumpydoc]

Almost certainly, the C++ committee never saw a feature they didn't like.

My major problem with the langue is that everyone knows a DIFFERENT subset of it, makes building a team to work on a C++ project awful hard.

It also encourages language lawyer cleverness which is never a good thing, while I like an expressive language as much as the next guy, one should always remember that someone else will sooner or later end up doing the maintenance programming, and they may well know a different subset.

Agreed, large c++ projects essentially end up write only and it often becomes almost impossible to "get up to speed" with the codebase for newcommers.

With templates you need to know the precise static type of everything in the program to know what code will be even generated which could be several templates deep - it's like all the abominations you could do with the pre-processor and them some. At least you can dump C code after cpp has run and see what you are getting.

With virtual functions you then need to know the exact dynamic type of everything to know what code could be executed - in fact for projects of only moderate complexity anything other than running the code in the debugger will probably fail. OK, that is true of all OO languages to some degree but C++ seems worse than most.

I'm generally "off" C++ these days - I think that the complexity of the language is now too great.

[Godzil]

Almost certainly, the C++ committee never saw a feature they didn't like.

My major problem with the langue is that everyone knows a DIFFERENT subset of it, makes building a team to work on a C++ project awful hard.

It also encourages language lawyer cleverness which is never a good thing, while I like an expressive language as much as the next guy, one should always remember that someone else will sooner or later end up doing the maintenance programming, and they may well know a different subset.

Agreed, large c++ projects essentially end up write only and it often becomes almost impossible to "get up to speed" with the codebase for newcommers.

With templates you need to know the precise static type of everything in the program to know what code will be even generated which could be several templates deep - it's like all the abominations you could do with the pre-processor and them some. At least you can dump C code after cpp has run and see what you are getting.

With virtual functions you then need to know the exact dynamic type of everything to know what code could be executed - in fact for projects of only moderate complexity anything other than running the code in the debugger will probably fail. OK, that is true of all OO languages to some degree but C++ seems worse than most.

I'm generally "off" C++ these days - I think that the complexity of the language is now too great.

A really good example of that is WebKit

[dmills]

I haven't understood if we are allowed to use "restrict" (C99 feature) 

I doubt it, restrict makes a promise to the compiler about pointer aliasing which your verification tools may not be able to check, it would worry me in SIL4 code.
Also, does that prehistoric C compiler you guys are using even support C99?

Regards, Dan.

[legacy]

Also, does that prehistoric C compiler you guys are using even support C99?

what I have on hand now (C89): no
Next Step, Green Hills C (=C99): yes

[legacy]

your verification tools may not be able to check

the current version of QaC (source code validator) is C89 and does not understand "restrict" because it's C99 feature
I hope (but I do not know if) they will buy the new version of QaC (=$$$, a lot of bucks)
otherwise we will have to downgrade C99 to C89 

[legacy]

Code: [Select]

while(n-- > 0) *t1++ = *t2++;

a lot of bans here

n--: banned if used with a compare
n--: banned if inside while ()
*t1: banned
t1++=: banned
*t2: banned
t2++: banned
while without a block: banned, it must always have "{' … "}"

[tggzzz]

With templates you need to know the precise static type of everything in the program to know what code will be even generated which could be several templates deep - it's like all the abominations you could do with the pre-processor and them some. At least you can dump C code after cpp has run and see what you are getting.

With virtual functions you then need to know the exact dynamic type of everything to know what code could be executed - in fact for projects of only moderate complexity anything other than running the code in the debugger will probably fail. OK, that is true of all OO languages to some degree but C++ seems worse than most.

I'm generally "off" C++ these days - I think that the complexity of the language is now too great.

Agreed, except that it is trivial to run the code in the debugger for Smalltalk[1] and Java, and you do get the expected results.

As far as I'm concerned, if C++ is the answer, then the question needs to be re-evaluated.

C is going that way too - some people want it to be a semi-portable assembler close to the bare metal, some want it to be for large mutating portable applications. Either would be possible and good, but it is impossible to shoehorn C into being both (C++ doubly so).

[1] when L. Peter Deutsch introduced the first JIT (Smalltalk ~1986), he observed that it is legitimate to cheat like hell under the hood, so long as you can't tell the cheating is occurring.

[Bassman59]

It's not "weird" or anything, it's called knowing the language.

Look up the Verilog sign-extension (and truncation) rules. They're weird. Yes, I know the language.  And that Verilog is supposed to be "C-like" is scary.

Short-circuit evaluation of || and && are literally one of the first things any C programmer should know - it's covered in section 1.5.4 of K&R. If someone can't figure out something as simple as this, I don't want to know what else they'll screw up...

Here's the thing, though. If you are working on a design with an FPGA and a micro, you have to be very careful about your coding, because it's too easy to mix things up! I spent too long trying to figure out why this bit of C didn't work as expected:

Code: [Select]

if (foo /= bar) {
    ... this
} else {
    ... that
}
It compiled without warning or error, of course. 

[legacy]

and a bit of confusion about "const" and "restrict" 

[legacy]

not so clear that there is the need to demystify the restrict keyword 

[dmills]

Look up the Verilog sign-extension (and truncation) rules. They're weird. Yes, I know the language.  And that Verilog is supposed to be "C-like" is scary.

This is why I like VHDL for hardware designs, I am way too comfortable in C for a language as superficially C like as  Verilog to NOT trip me up on a regular basis.

Also, when writing Verilog I find myself falling into a software rather then a hardware mindset more often then not, telling the thing what to do, rather then what to be, and that results in horrific code in a HDL.

besides, with 20 minute place and route times, I find the strong typing and range checks to be a net time saver even if it involves rather too much typing.

Regards, Dan.

[westfw]

Code: [Select]

while(n-- > 0) *t1++ = *t2++;

So the conforming version would be something like:

Code: [Select]

while (n > 0) {
   n -= 1;
   t1[n] = t2[n];
}
I guess that isn't too awful.  I think I can even see how it would make static analysis easier (esp assuming t1 and t2 are sized), and probably produces very similar code (Hmm.  Not so much, on AVR.  Neither one seems to produce the code I'd like to see.)

[coppice]

Code: [Select]

while(n-- > 0) *t1++ = *t2++;

So the conforming version would be something like:

Code: [Select]

while (n > 0) {
   n -= 1;
   t1[n] = t2[n];
}
I guess that isn't too awful.  I think I can even see how it would make static analysis easier (esp assuming t1 and t2 are sized), and probably produces very similar code (Hmm.  Not so much, on AVR.  Neither one seems to produce the code I'd like to see.)

Those two pieces of code are not equivalent.

[AlfBaz]

Code: [Select]

   n -= 1;


I'm surprised that's not banned also 

[coppice]

Code: [Select]

   n -= 1;


I'm surprised that's not banned also 

Why? That's a construct they helps reduce stupid typos, which is the theme of a lot of the MISRA restrictions.

[westfw]

Those two pieces of code are not equivalent.

True.  And a good point.  If I do better, by ADDING source code, the binary for the compliant version shrinks, and becomes identical to the non-compliant version (for AVR.)  (neat trick!)

Code: [Select]

void memcpy1(char *t1, char *t2, int n)
{
  while (n-- > 0) *t1++ = *t2++;
}

void memcpy2(char t1[], char t2[], int n)
{
  int i = 0;
  while (n > 0) {
    t1[i] = t2[i];
    n -= 1;
    i += 1;
  }
}

[legacy]

• char t1: banned, you have to use "uint8_t" (motivation I got: "because char can mean 16bit"    )
• int n: banned, uint32_t

signed $SIZE ----> sint$SIZE_t
unsigned $SIZE ---> uint$SIZE_t

$SIZE={8, 16, 32, 64}

[legacy]

Code: [Select]

   n -= 1;
I'm surprised that's not banned also 

indeed banned 

in level A/B

• i++: banned
• i--: banned
• ++i: banned
• --i: banned
• i+=const: banned
• i-=const: banned
• i/=const: super banned (threat to be fired  )
• i*=const: banned

[legacy]

AVR

they use "PowerPC", like PPC440, PPC460
we should also compare with MIPS32 (not used in avionics)

[Godzil]

• char t1: banned, you have to use "uint8_t" (motivation I got: "because char can mean 16bit"    )

That's true, the type char is the minimum size for a character on a specific platform, so it could be different than 8bit, also char could be signed or not depending on the compiler!

See: http://stackoverflow.com/questions/2098149/what-platforms-have-something-other-than-8-bit-char