Author Topic: engineering ethics (it was [SOLVED] funny CC)  (Read 35523 times)

0 Members and 1 Guest are viewing this topic.

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
engineering ethics (it was [SOLVED] funny CC)
« on: November 20, 2015, 03:45:21 pm »
yesterday I was hammering my head with a piece of C code (not written by me, & bare metal profiled for MIPS32) which continuously crashes when compiled with SierraC while it works when compiled with gcc

Code: [Select]
        while (p_btree->context.queue isNotEqualTo NULL)
        {
            p_node = queue_de(p_btree);
            if ((p_node->parent isNotEqualTo NULL)logicalAnd(p_node isEqualTo p_node->parent->pointer[0]))
            {
                rank_new = tree_get_path_lengh_to_root(p_root, p_node);
                if (rank_new isNotEqualTo rank)
                {
                    rank = rank_new;
                }
            }
        }
working with gcc, not working with sierraC

Code: [Select]
        is_done=(p_btree->context.queue isEqualTo NULL);
        while (is_done isNotEqualTo True)
        {
            p_node = queue_de(p_btree);           
            is_ok1=(p_node->parent isNotEqualTo NULL);
            if (is_ok1 isEqualTo True)
            {
                is_ok2=(p_node isEqualTo p_node->parent->pointer[0]);
                if (is_ok2 isEqualTo True)
                {
                   rank2 = tree_get_path_lengh_to_root(p_root, p_node);
                   if (rank2 isNotEqualTo rank1)
                   {
                       rank1 = rank2;
                   }
                }
            }
            is_done=(p_btree->context.queue isEqualTo NULL);
        }
working with both sierraC and gcc


of course the "fixed" version is too pedantic, but just a proof of concept, in order to understand WTF is wrong in the original code
and as far as I understand WTF happened, my debug TAP has found that the problem is around the following line
Code: [Select]
if ((p_node->parent isNotEqualTo NULL)logicalAnd(p_node isEqualTo p_node->parent->pointer[0]))

more specifically (analyzing the assembly code) it seems that it depends by the CC implementation

SierraC seems to implement the IF-STATEMENT as
  • step1: eval (p_node->parent isNotEqualTo NULL)
  • step2: eval (p_node isEqualTo p_node->parent->pointer[0])
  • step3: if they are both True then take the IF branch, else take the ELSE branch

GCC seems to implement the IF-STATEMENT as
  • step1: eval (p_node->parent isNotEqualTo NULL)
  • step2: if the previous eval is True then eval (p_node isEqualTo p_node->parent->pointer[0])
  • step3: if (is_ok2 isEqualTo True) then take the IF branch, else take the ELSE branch

so the problem with SierraC is … with "p_node->parent->pointer" which crashes when "p_node->parent" is NULL


if so, it means that I have 4K lines of C to be fixed :palm: :palm: :palm: :palm: :palm:
« Last Edit: November 22, 2015, 01:28:09 pm by legacy »
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: funny CC
« Reply #1 on: November 20, 2015, 04:11:52 pm »
You may want to check for the compiler switch for the "short-circuit" evaluation.
 

Offline 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1570
  • Country: de
Re: funny CC
« Reply #2 on: November 20, 2015, 04:16:08 pm »
Sure the "logicalAnd" is defined the same in both versions?
I'm pretty sure that "&&" should always be short circuit according to the standard while "&" is not.
If both versions use "&&", there must be a compiler switch to ignore the standard.
Well, or the compiler is crap.
Trying is the first step towards failure - Homer J. Simpson
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: funny CC
« Reply #3 on: November 20, 2015, 04:24:49 pm »
isNotEqualTo, logicalAnd etc - just use the *&^%!!! language FFS  :palm:

These sort of shenanigans do not, in general, help write bug free code.
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: funny CC
« Reply #4 on: November 20, 2015, 04:49:46 pm »
If logicalAnd is defined as && (this is really horrible, what's the purpose?), then Sierra C is not ANSI standard compliant.

From C89 standard (well, the draft...):
Quote
3.3.13 Logical AND operator
[...]
   Unlike the bitwise binary & operator, the && operator guarantees
left-to-right evaluation; there is a sequence point after the
evaluation of the first operand.  If the first operand compares equal
to 0, the second operand is not evaluated.
The sequence point and definition guarantee that the second operand:
  • will only be evaluated if the first one is non-zero
  • its (possible) evaluation will happen only when all the side effects of the first one are completed

K&R C, if my memory helps, did not mandate short-circuit evaluation.
I'm not acquainted with Sierra C, there are almost no traces of it on the web, but it might have a switch to make it ANSI compliant.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: funny CC
« Reply #5 on: November 20, 2015, 05:12:40 pm »
isNotEqualTo, logicalAnd etc - just use the *&^%!!! language FFS  :palm:

These sort of shenanigans do not, in general, help write bug free code.

Pretty much my thoughts entirely, at the very least the code is much less readable.

I guess it's to save people from themselves on = vs == and the difference between bitwises and logicals. Any compiler worth its salt would offer a warning, assuming the dev hadn't tried to disable warnings that is.
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: funny CC
« Reply #6 on: November 20, 2015, 05:16:33 pm »
Quote
K&R C, if my memory helps, did not mandate short-circuit evaluation.
My copy of K&R clearly states that && and || stop evaluation as soon as the value of the whole expression is known.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: funny CC
« Reply #7 on: November 20, 2015, 05:25:21 pm »
Sure the "logicalAnd" is defined the same in both versions?

it's the alias for "&&"

Code: [Select]
#define logicalAnd     &&

I had to use the alias for an internal reason (my boss wants this way)

Well, or the compiler is crap.

 :-//
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: funny CC
« Reply #8 on: November 20, 2015, 05:32:28 pm »
If logicalAnd is defined as &&

yes it is

this is really horrible, what's the purpose?

it's more horrible to see "&&", which can be confused with "&"

then Sierra C is not ANSI standard compliant.

I am really afraid they are not C89

If the first operand compares equal to 0, the second operand is not evaluated.

exactly what happens  :palm:

K&R C, if my memory helps, did not mandate short-circuit evaluation.

So it might be a pre-ANSI-C compiler, or probably they have give me the wrong compiler version
or it's not configured in the right way (missing FLAGS? missing external profile that "enables/disables" features? who knows)
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: funny CC
« Reply #9 on: November 20, 2015, 05:45:08 pm »
Quote
K&R C, if my memory helps, did not mandate short-circuit evaluation.
My copy of K&R clearly states that && and || stop evaluation as soon as the value of the whole expression is known.
I stand corrected :-X, unless that copy is the "Second Edition" (that is, already ANSI). My original one is long lost :(

Quote
it's more horrible to see "&&", which can be confused with "&"
To each their own. I do not agree in the least, but if you are fine with that :-//
Code: [Select]
#define isAssignedTheFollowingExpression =
The latest thing I could find about SierraC is a 1993 reference...so, well in the C89 domain (but still a number of non-compliant compiler might still be around, and you might have an older version...). Check the documentation for C89/ANSI compliance, or at least short-circuit evaluation.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: funny CC
« Reply #10 on: November 20, 2015, 05:47:25 pm »
sierraC, are you building for 68000 target? This was used by TI for there 68K based calculator, and the resulted assembly was just absolutely horrible..
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: funny CC
« Reply #11 on: November 20, 2015, 05:51:49 pm »
I guess it's to save people from themselves on = vs == and the difference between bitwises and logicals.
Any compiler worth its salt would offer a warning, assuming the dev hadn't tried to disable warnings that is.

emmm, SierraC does not offer a warning when you write "if (a=0) {}" instead of "if (a==0) {}"
I can agree or disagree, however it's imposed by our customers (more specifically by their QA dudes)
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: funny CC
« Reply #12 on: November 20, 2015, 06:01:00 pm »
sierraC, are you building for 68000 target?

yes, but it's not the SierraC Compiler that was bought by TI and used for their calculators
I can say that because it supports CPU32 (683xx) which was not supported by the TI version

here I have a few 683xx cores, and a DOS16 CC (it works under WinXP, or inside a virtual machine)
the full toolchain has been provided by a few customers who want to support their old equipment
I have suggested them a full port to PIC32, but they said that they can't change the baseline until their EOL
(avionics products, they are crazy)
 

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: funny CC
« Reply #13 on: November 20, 2015, 06:05:06 pm »
Avionics that use that crap compiler?!?!? O_O
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: funny CC
« Reply #14 on: November 20, 2015, 06:16:23 pm »
* * * solution found * * *

there is a profile file (.bat?) in the bin path which has the following line
Code: [Select]
SET  ev_shortcircuit 0

I have changed into
Code: [Select]
SET  ev_shortcircuit 1

and everything is now working as expected :D :D :D :D



so, it seems that it's really possible to "disable" that feature
too amazing  :-DD
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: funny CC
« Reply #15 on: November 20, 2015, 06:34:25 pm »
emmm, SierraC does not offer a warning when

when you have this set

Code: [Select]
SET  ev_wall 0

I have changed into

Code: [Select]
SET  ev_wall 1

and now it offers a lot of useful warnings  :D


conclusion: the environment was not configured in the proper way!
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: funny CC
« Reply #16 on: November 20, 2015, 06:39:53 pm »
I had to use the alias for an internal reason (my boss wants this way)
 :-//
Apparently your boss does not know C, but still wants to read it.
Send him on C-bootcamp or something.  :P
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: funny CC
« Reply #17 on: November 20, 2015, 06:42:54 pm »
I had to use the alias for an internal reason (my boss wants this way)

Why don't you suggest also using
#define begin {
#define end }

Of course, if your boss cannot expain why they want something, then you shold get another boss.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: [SOLVED] funny CC
« Reply #18 on: November 20, 2015, 07:04:04 pm »
Lets go the whole hog!
Code: [Select]
#define if if(
#define then )
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: funny CC
« Reply #19 on: November 20, 2015, 07:57:22 pm »
Apparently your boss does not know C

he is a pro ADA dude, probably too Pascal addicted  :-//
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: [SOLVED] funny CC
« Reply #20 on: November 20, 2015, 08:10:53 pm »
You have a broken compiler and a broken boss. This could not be good for your career.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #21 on: November 20, 2015, 08:11:03 pm »
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  :D
« Last Edit: November 20, 2015, 08:25:18 pm by legacy »
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: [SOLVED] funny CC
« Reply #22 on: November 20, 2015, 08:16:07 pm »
Quote
I stand corrected :-X, unless that copy is the "Second Edition" (that is, already ANSI). My original one is long lost :(
1st edition, bought 1986 according to the note I pot on the fly sheet. I had an earlier printing but mislaid it.

Quote
emmm, SierraC does not offer a warning when you write "if (a=0) {}" instead of "if (a==0) {}"
You can always use the "if (0==a){}" trick.

Quote
I can agree or disagree, however it's imposed by our customers (more specifically by their QA dudes)
Well, whoever pays the piper calls the tune I suppose.
 

Offline djacobow

  • Super Contributor
  • ***
  • Posts: 1151
  • Country: us
  • takin' it apart since the 70's
Re: [SOLVED] funny CC
« Reply #23 on: November 20, 2015, 08:19:15 pm »
I don't know why I feel the need to chime in, but not only is

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

barfalicious, but even

        while(p_btree->context.queue != NULL) { ... } is awful

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.

 

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: [SOLVED] funny CC
« Reply #24 on: November 20, 2015, 08:52:20 pm »
You are all thinking about 'normal" engineering, here it's related to avionic, where EVERYTHING need to be proved and done explicitely.

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.
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #25 on: November 20, 2015, 08:56:06 pm »
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  :D

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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1570
  • Country: de
Re: [SOLVED] funny CC
« Reply #26 on: November 20, 2015, 09:01:08 pm »
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.
Trying is the first step towards failure - Homer J. Simpson
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #27 on: November 20, 2015, 09:12:04 pm »
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  :D

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

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #28 on: November 20, 2015, 09:15:03 pm »
"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)
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: [SOLVED] funny CC
« Reply #29 on: November 20, 2015, 09:20:55 pm »
Quote
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.
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: [SOLVED] funny CC
« Reply #30 on: November 20, 2015, 09:37:49 pm »
Quote
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.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: [SOLVED] funny CC
« Reply #31 on: November 20, 2015, 10:32:25 pm »
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/
 

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: [SOLVED] funny CC
« Reply #32 on: November 20, 2015, 11:33:03 pm »
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 //
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Offline Phoenix

  • Frequent Contributor
  • **
  • Posts: 420
  • Country: au
Re: [SOLVED] funny CC
« Reply #33 on: November 20, 2015, 11:46:37 pm »
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.
 

Offline djacobow

  • Super Contributor
  • ***
  • Posts: 1151
  • Country: us
  • takin' it apart since the 70's
Re: [SOLVED] funny CC
« Reply #34 on: November 20, 2015, 11:48:35 pm »
Quote
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.



 

Offline 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1570
  • Country: de
Re: [SOLVED] funny CC
« Reply #35 on: November 21, 2015, 12:17:03 am »
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.
Trying is the first step towards failure - Homer J. Simpson
 

Offline AlfBaz

  • Super Contributor
  • ***
  • Posts: 2183
  • Country: au
Re: [SOLVED] funny CC
« Reply #36 on: November 21, 2015, 12:22:40 am »
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
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #37 on: November 21, 2015, 12:50:13 am »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: [SOLVED] funny CC
« Reply #38 on: November 21, 2015, 12:52:27 am »
Quote
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?
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #39 on: November 21, 2015, 01:00:11 am »
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.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #40 on: November 21, 2015, 01:03:16 am »
gcc has these interesting flags

Code: [Select]
-ansi -pedantic -Wall -W
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: [SOLVED] funny CC
« Reply #41 on: November 21, 2015, 09:32:38 am »
gcc has these interesting flags

Code: [Select]
-ansi -pedantic -Wall -W
You forgot -Werror (and -W properly should be -Wextra)

Quote from: 0xdeadbeef
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.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: [SOLVED] funny CC
« Reply #42 on: November 21, 2015, 09:40:46 am »
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.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #43 on: November 21, 2015, 10:02:56 am »
Bad C programmers write bad C programs

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

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: [SOLVED] funny CC
« Reply #44 on: November 21, 2015, 10:07:49 am »
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.

Quote
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.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #45 on: November 21, 2015, 10:17:28 am »
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?
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #46 on: November 21, 2015, 11:40:31 am »
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".
« Last Edit: November 21, 2015, 12:32:30 pm by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: [SOLVED] funny CC
« Reply #47 on: November 21, 2015, 11:44:01 am »
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.
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: [SOLVED] funny CC
« Reply #48 on: November 21, 2015, 12:05:20 pm »
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?
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #49 on: November 21, 2015, 01:16:03 pm »
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!
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #50 on: November 21, 2015, 01:23:56 pm »
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.

yes, speaking with my Boss (about the WHY? on the WHY?), I have understood that it has been done on purpose (so I can't re-enable it  :palm: :palm: :palm: ) because the software has to be validated by VectorCast within level B, so every if () statement has to be evaluated in deeply

it means that if you have if (a && b) you have to prove (through VectorCast test reports) that you have covered the full True table

a-b
----
0-0
0-1
1-0
1-1

I am a bit shocked to hear that  :-//
« Last Edit: November 22, 2015, 10:10:50 am by legacy »
 

Offline 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1570
  • Country: de
Re: [SOLVED] funny CC
« Reply #51 on: November 21, 2015, 02:50:37 pm »
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
This never was the question. However a plain integer variable and a pointer/reference are different types and therefore more stricter languages don't allow direct assignment/comparison to avoid unintended mixture of types. This concept of stricter type checking and avoiding implicit casts is usually applied in environments where code quality matters (automobile, avionics).
E.g. C also doesn't complain about comparing signed and unsigned integers even if this is pretty dangerous. Sure this is OK from C point of view, still it's bad style. And since all immediates without cast or other forced type assignment (like 1UL or 1.0f) are considered signed integers by C, even assigning an immediate to a variable without explicit cast can be dangerous. The problem is that C allows more or less everything regarding assignment and comparisons but most people programming C don't understand the implications and dangers of this freedom.
Trying is the first step towards failure - Homer J. Simpson
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: [SOLVED] funny CC
« Reply #52 on: November 21, 2015, 03:18:59 pm »
So there is this "bug" in a popular compiler about doing this:
uint64_t variable = 0;
Where it will only initialise the lower word of the variable and not the complete thing.
Since the 0 is of type int, which is int32_t for 32 bit system.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #53 on: November 21, 2015, 04:13:09 pm »
So there is this "bug" in a popular compiler about doing this:
uint64_t variable = 0;
Where it will only initialise the lower word of the variable and not the complete thing.
Since the 0 is of type int, which is int32_t for 32 bit system.

Welcome to the land of missing toes. Wise practitioners turn on all warnings, and find out what is provoking them.

There's an old aphorism "cc is only half a compiler, the other half is called lint".
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: [SOLVED] funny CC
« Reply #54 on: November 21, 2015, 09:28:01 pm »
So there is this "bug" in a popular compiler about doing this:
uint64_t variable = 0;
Where it will only initialise the lower word of the variable and not the complete thing.
Since the 0 is of type int, which is int32_t for 32 bit system.

Please emphasize that this is a bug in the compiler, not the C language. The C language specifies that a conversion be made from 0 to uint64_t, and the variable is completely initialized to zero.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: [SOLVED] funny CC
« Reply #55 on: November 21, 2015, 10:33:45 pm »
It was armcc 5.03.0.76 to be precise. But I did not put any more effort into it after discovering this weird behavior. I was once again warned that a compiler is software, and software has random features you can discover. I reconsidered my approach and did not use 64 bit types for whatever I was doing because I cannot find any *int64 in the project anymore.
 

Online helius

  • Super Contributor
  • ***
  • Posts: 3632
  • Country: us
Re: [SOLVED] funny CC
« Reply #56 on: November 21, 2015, 10:42:02 pm »
I am very amused by these discussions where very experienced people talk about using casts as if they are safer. The only thing that casts do is destroy type safety and prevent warnings. In code with explicit casts, you will never be told that there is a type mismatch. The plain truth is that in strongly-typed languages, casts do not exist.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: [SOLVED] funny CC
« Reply #57 on: November 21, 2015, 10:43:44 pm »
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!

Don't hold punches, go ahead and quote such people who "have rewritten it in the decent way!" It's a simple example to demonstrate how a simple allocator can be written, but now you are claiming that it should be held up as examples of badly written code, in the order of morons who would turn off short-circuited evaluations and abuse macros (in other words, they don't want to write in C, in which case, they should not), so let's see such evidence.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #58 on: November 21, 2015, 11:21:27 pm »
I am very amused by these discussions where very experienced people talk about using casts as if they are safer. The only thing that casts do is destroy type safety and prevent warnings. In code with explicit casts, you will never be told that there is a type mismatch. The plain truth is that in strongly-typed languages, casts do not exist.

Java's objects are extremely strongly typed, and typesafe downcasts are frequently used. If the downcast is invalid, an exception is thrown.

In C/C++, casts are used to say "I'm lying" or "I can't specify it, but I believe it is true".
« Last Edit: November 21, 2015, 11:23:22 pm by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #59 on: November 21, 2015, 11:40:30 pm »
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: [SOLVED] funny CC
« Reply #60 on: November 21, 2015, 11:50:33 pm »
Quote
Java's objects are extremely strongly typed, and typesafe downcasts are frequently used. If the downcast is invalid, an exception is thrown.

In C/C++, casts are used to say "I'm lying" or "I can't specify it, but I believe it is true".

The things which Java is good at tend not to require circumvention of the type system.

The things which C is good at occasionally  require flexibility in the type system.


 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: [SOLVED] funny CC
« Reply #61 on: November 21, 2015, 11:50:43 pm »
A problem with unsigned vs. signed int is because human are lousy with them :-) Ask any programmer, what should the data type of a counter? And most would say "int" because we tend to think of int as integer. Except that if you are truly counting, then it is really an unsigned counter. So most of the time, there should not be penalty of conversion between signed and unsigned int of the same base type.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1570
  • Country: de
Re: [SOLVED] funny CC
« Reply #62 on: November 21, 2015, 11:56:19 pm »
I am very amused by these discussions where very experienced people talk about using casts as if they are safer. The only thing that casts do is destroy type safety and prevent warnings. In code with explicit casts, you will never be told that there is a type mismatch. The plain truth is that in strongly-typed languages, casts do not exist.
Sorry, but this is nonsense. Of course strongly typed languages as Java use casts. Actually, in Java you are forced to use a cast if the correctness of an assignment/comparison can't be statically checked to be safe. In C, you can more or less assign everything to everything. Then again if you use a static code checker as Lint, the behavior is similar to the default Java compiler: every unsafe assignment/comparison needs an explicit cast to force the developer to think about the cross-type operation. Of course just using casts without thinking about it, doesn't improve the situation. But for a decent programmer, these hints are very useful to detect cross-type operations that happened by mistake.
Trying is the first step towards failure - Homer J. Simpson
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #63 on: November 22, 2015, 12:20:25 am »
The things which C is good at occasionally  require flexibility in the type system.

ummm  |O
 

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 294
  • Country: gb
Re: [SOLVED] funny CC
« Reply #64 on: November 22, 2015, 12:28:50 am »
I am very amused by these discussions where very experienced people talk about using casts as if they are safer. The only thing that casts do is destroy type safety and prevent warnings. In code with explicit casts, you will never be told that there is a type mismatch. The plain truth is that in strongly-typed languages, casts do not exist.
Sorry, but this is nonsense. Of course strongly typed languages as Java use casts. Actually, in Java you are forced to use a cast if the correctness of an assignment/comparison can't be statically checked to be safe. In C, you can more or less assign everything to everything. Then again if you use a static code checker as Lint, the behavior is similar to the default Java compiler: every unsafe assignment/comparison needs an explicit cast to force the developer to think about the cross-type operation. Of course just using casts without thinking about it, doesn't improve the situation. But for a decent programmer, these hints are very useful to detect cross-type operations that happened by mistake.

I'm just a casual Java programmer, but I believe the cast there is either an upcast or downcast that traverses an object hierarchy and trying to perform an unsafe downcast, e.g. an (String)x when x is an object that is actually an integer will cause a runtime ClassCastException.  All upcasts are safe.

Contrast this to C where a similar cast is just accepted by the compiler  and the runtime results are undefined.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #65 on: November 22, 2015, 12:49:26 am »
I am very amused by these discussions where very experienced people talk about using casts as if they are safer. The only thing that casts do is destroy type safety and prevent warnings. In code with explicit casts, you will never be told that there is a type mismatch. The plain truth is that in strongly-typed languages, casts do not exist.
Sorry, but this is nonsense. Of course strongly typed languages as Java use casts. Actually, in Java you are forced to use a cast if the correctness of an assignment/comparison can't be statically checked to be safe. In C, you can more or less assign everything to everything. Then again if you use a static code checker as Lint, the behavior is similar to the default Java compiler: every unsafe assignment/comparison needs an explicit cast to force the developer to think about the cross-type operation. Of course just using casts without thinking about it, doesn't improve the situation. But for a decent programmer, these hints are very useful to detect cross-type operations that happened by mistake.

I'm just a casual Java programmer, but I believe the cast there is either an upcast or downcast that traverses an object hierarchy and trying to perform an unsafe downcast, e.g. an (String)x when x is an object that is actually an integer will cause a runtime ClassCastException.  All upcasts are safe.

Contrast this to C where a similar cast is just accepted by the compiler  and the runtime results are undefined.

Java's type system has the sensible traditional covariant return values and contravariant arguments. Hence upcasting is not required, and the principal use of downcasting was when extracting an object from one of the collection objects (Sets, ArrayLists etc). Nowadays there is less requirement for downcasting due to the use of generics in the collection classes.

Both upcasts and downcasts are typesafe in that they are checked at runtime and, if necessary, an exception is thrown. In Java you can't cast a Horse into a Camel.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #66 on: November 22, 2015, 01:00:38 am »
I guess we'd better talk about ADA and their motd "in strong state-type we trust"

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: [SOLVED] funny CC
« Reply #67 on: November 22, 2015, 02:58:02 am »
Quote
I have understand that it has been done on purpose because the software has to be validated by VectorCast within level B, so every if () statement has to be evaluated in deeply
"people" have "coding quality standards" that restrict and redefine a language SO much that it might as well be a different language, in turn largely restricting their developer pool and their choice of compilers.  And then they wonder why their product quality isn't that good...
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8240
Re: [SOLVED] funny CC
« Reply #68 on: November 22, 2015, 03:49:28 am »
There is not enough :wtf: :o :palm: to describe what I'm feeling as I'm reading through this thread...

I know you probably are under NDA but could you at least say if the code you're working on appears in any commercial airliners?

One strategy I use when I have to work at places with insane code-formatting requirements is to write a simple script to apply the changes (in the appropriate directly) when you actually checkin/checkout code from the repository, so you can work in your own style and everyone else only sees the "processed" version that following their rules but which you abhor.

The lack of a true boolean type in C is usually considered a flaw.
...by those who don't really understand C. (Of course it would be useful if bools actually used the processor status flags and were only 1 bit wide as they should be...)
« Last Edit: November 22, 2015, 03:51:59 am by amyk »
 

Online helius

  • Super Contributor
  • ***
  • Posts: 3632
  • Country: us
Re: [SOLVED] funny CC
« Reply #69 on: November 22, 2015, 05:00:03 am »
Java's objects are extremely strongly typed, and typesafe downcasts are frequently used. If the downcast is invalid, an exception is thrown.
Interesting equivocation. Are you saying that only the "objects" are strongly typed, and the rest of the language doesn't count? :palm:
In Java you can break the integrity of the type system as soon as you declare an array.
Code: [Select]
String[] strings = new String[1];
  Object[] objects = strings;
  objects[0] = new Integer(1);
Sorry, but this is nonsense. Of course strongly typed languages as Java use casts. Actually, in Java you are forced to use a cast if the correctness of an assignment/comparison can't be statically checked to be safe.
If a program can't be verified to be type-correct at compile time then the language isn't strongly typed. All of the dozens of languages with Hindley-Milner type systems are decidable at compile time. The rest are pretenders.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #70 on: November 22, 2015, 09:40:21 am »
Java's objects are extremely strongly typed, and typesafe downcasts are frequently used. If the downcast is invalid, an exception is thrown.
Interesting equivocation. Are you saying that only the "objects" are strongly typed, and the rest of the language doesn't count? :palm:
In Java you can break the integrity of the type system as soon as you declare an array.
Code: [Select]
String[] strings = new String[1];
  Object[] objects = strings;
  objects[0] = new Integer(1);
Sorry, but this is nonsense. Of course strongly typed languages as Java use casts. Actually, in Java you are forced to use a cast if the correctness of an assignment/comparison can't be statically checked to be safe.
If a program can't be verified to be type-correct at compile time then the language isn't strongly typed. All of the dozens of languages with Hindley-Milner type systems are decidable at compile time. The rest are pretenders.

I did not say the language was strongly typed; please do not invent strawman arguments. Java is the combination of the source-code language syntax and semantics, plus the runtime execution mechanism. Given the Halting problem, anything less is insufficient.

In your example, try casting (Camel)(objects[0]) and see what happens.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #71 on: November 22, 2015, 10:27:55 am »
I did a mistake in typing "understand", it was "I have understood", just a little mistake because I was tired and because English (blind in catching errors at the first sign) is not my first language, you can still understand the meaning, but imagine if you were blind in the source code, and this mistake reacts in the worst way during abnormal working: mission failed, everybody dies


And then they wonder why their product quality isn't that good

the "quality" implies how deep you know what your source code does, in this case we MUST have a dynamically coverage (->VectorCast) covering everything deeply within normal and abnormal working condition

we have to run the source code within a lot of test benches (described by ATP&ATR), probing stimulus from the outside (there is an hardware equipment for that) , and verify that every statement is covered in the reasonable way, with manually justifications in case of need ("unsafe code, defensive code, etcetc")

In short, the more I work with them, the more It does make sense  :-//
(even if, I still think they are funny~crazy)

« Last Edit: November 22, 2015, 11:32:18 am by legacy »
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #72 on: November 22, 2015, 10:38:06 am »
It was armcc 5.03.0.76 to be precise

are you speaking about Keil/uVision using the ARMCC compiler v 5.03.0.76 ?
is GCC v>=v4.9/5.* bugged too ?
« Last Edit: November 22, 2015, 11:30:09 am by legacy »
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: [SOLVED] funny CC
« Reply #73 on: November 22, 2015, 10:38:34 am »
IMHO the initial decision to use a compiler modified from the language standard (by 'SET ev_shortcircuit 0') was defective. The problem with the VectorCast test coverage should have been resolved in another way, possibly by setting coding standards forbidding boolean logical operations, thus enforcing explicit nested 'if()....else....' logic.

However you are now stuck with it, unless you find a job elsewhere.
 

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: [SOLVED] funny CC
« Reply #74 on: November 22, 2015, 10:57:56 am »
Nah seriously avionics NEED that sort of test or your stuff will never ever pass the standardisation. Ask anyone who work on avionics or satellites or any other space related project you'll see.
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: [SOLVED] funny CC
« Reply #75 on: November 22, 2015, 11:05:36 am »
If the short-circuit evaluation is to be avoided, then the correct behavior for any coverage tools is to diagnose the use of the && and || operators as unsafe, NOT by requiring compiler changes.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #76 on: November 22, 2015, 11:11:06 am »
the "quality" implies how deep you know what your source code does...

Quality requires far more than that, of course.

Lastly, you have to create something that solves the client's problem.

Firstly, and far more intractably, you have to get the client to understand their problem and provide a sufficient specification of the problem.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: [SOLVED] funny CC
« Reply #77 on: November 22, 2015, 11:18:40 am »
The things which C is good at occasionally  require flexibility in the type system.

ummm  |O
Yes, sorry, perhaps too much wine :)

What I was getting at is that C is a good language for implementing low level systems and that type of coding occasionally needs casts - but in well written code the need for type casts should generally be fairly small. If reviewing code I worry if I find casts scattered throughout the code. Something like a single cast of a void * into a correct type at the top of a function is reasonably clear and a well recognised idiom in C.



 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: [SOLVED] funny CC
« Reply #78 on: November 22, 2015, 11:20:40 am »
Oh you need test coverage tools right enough, but the correct answer to a problem like this is to shout at the test coverage tool vendor until they fix the tool, not set a horribly fragile flag in a makefile that breaks the language.

One observation from an (Ex) automotive guy, testing that "If X any not Y then Z within 100ms" is easy, testing that Z **ONLY** occurs within 100ms of those conditions is almost impossible in a non trivial system, and often the second is of FAR greater importance.
Also, CAN and friends are asynchronous and you can get races between the updates from various systems, very hard to test for.

You cannot test quality into a product, and I am having a horrible feeling that this is being attempted.

There is **PLENTY** of WTF in this thread, and the whole thing is making me far more nervous then I ever was about flying.

Regards, Dan.
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: [SOLVED] funny CC
« Reply #79 on: November 22, 2015, 11:27:33 am »
IMHO the initial decision to use a compiler modified from the language standard (by 'SET ev_shortcircuit 0') was defective.
I have to say I am in 100% agreement with this - in fact I'm quite surprised to find that the compiler even allows such a switch as it renders the environment incompatible with any C standard so that move in itself would be against MISRA  guidelines.

I'd also argue that whoever insisted on "all 4" cases for coverage does not understand C enough to be making that specification.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #80 on: November 22, 2015, 11:44:23 am »
by setting coding standards forbidding boolean logical operations, thus enforcing explicit nested 'if()....else....' logic.

it's what I am manually doing to satisfy both SierraC and VectorCast: my best with ~3K lines of source code (draft version) to be modified, retested, and then validated by VectorCast, also keeping both my eyes on test reports in order to be sure that everything is correct.

I do not know WHY? they do not fix/modify VectorCast, I do not know if there are other hidden reasons in that decision :-//
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: [SOLVED] funny CC
« Reply #81 on: November 22, 2015, 11:48:49 am »
If they've done one such non-ANSI C abomination, they'll have done others.  Have an exit strategy in place in case you need to whistle-blow.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #82 on: November 22, 2015, 12:24:58 pm »
Also, CAN and friends are asynchronous and you can get races between the updates from various systems, very hard to test for.

You cannot test quality into a product, and I am having a horrible feeling that this is being attempted.

Very true. From your use of "You cannot test quality into a product", I guess you have been around for a while.

Nowadays software of all sorts is written by the very inexperienced, who believe that if all the unit tests have been passed then the software is correct. Seriously, I have heard that several times from people that ought to know better.

Given that level of ineptitude, it is unsurprising that, if they have even heard of the "byzantine generals" problem, they don't think it applies in the software they are creating.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #83 on: November 22, 2015, 12:35:10 pm »
who believe that if all the unit tests have been passed then the software is correct

unit tests is "minimum condition but not sufficient" ~ if ( A && ….
there are also integration tests, and a lot of other fine tests
(I am not directly involved in them, it's other dudes task)
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #84 on: November 22, 2015, 12:37:04 pm »
"byzantine generals" problem"

nice quote  :-+
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: [SOLVED] funny CC
« Reply #85 on: November 22, 2015, 01:10:43 pm »
are you speaking about Keil/uVision using the ARMCC compiler v 5.03.0.76 ?
is GCC v>=v4.9/5.* bugged too ?
I never used gcc for arm, so I wouldn't know.
Also note that I didn't find a public list of known bugs or errata for the compiler. They probably have a list in a secure part of their website to which I do not have access.

Meanwhile this topic is turning into "engineering ethics". Should we change the title?
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #86 on: November 22, 2015, 01:25:30 pm »
so, it's seem that I am going to understand the a few points

I have already modified a C-Grammar tool that I have written a few months ago (in order to do "inter modules dependencies"), just to automate the process of changing the if-statement (1) into (2)

(1): if (A && B) ----- automatically transformed into ------> (2): if (A) { if (B) {} }

* * * my boss * * * has said that he assigned a level-B (sub)task to me not because I am qualified as level-B-developer/tester (as I am still  level-E), but because "I am good" at creating tools in order to solve a problem.

as far as I understood, I am working on a piece of code that was originally created for a level-D in where VectorCast just needs to check if the if-statement was taken or not, it didn't matter about the True-table, and they want to "improve" it into level-B, modifying as it's needed

Code: [Select]
var.A var.B  then-branch
------------------------
False False  not taken
False  True  not taken
True  False  not taken
True   True  taken
True table, coverage, Level D..E

Code: [Select]
var.A var.B  then-branch  detailed conditions
-------------------------------------------------------
False False  not taken    with var.A=False, var.B=False
False  True  not taken    with var.A=False, Var.B=True
True  False  not taken    with var.A=True , Var.B=False
True   True  taken        with var.A=True , Var.B=True
True table, coverage, Level A..B

coverage, Level C=?!?!?!?

i am working on a draft version, which means it has passed the "normal" condition on real hardware and it's ready to be tested with "abnormal" condition, which also implies hard stress tests

as far as I understood they want to reuse (of course improving them as need) their ATP (test plan) to the ICE test, this requires "hard points" in the source code around the if-branches to allow the ICE (in circuit emulator) to collect the environment while the software is running in run-mode.

VectorCast tends to make the code "instrumented", this means modified to collect "triplets" (sampled detailed conditions) about the if-then-else statement, and also it requires debug mode, so the clock is scaled 1:x, and sometime too much intrusive

They got requested to provide a VectorCast test report (ATP), it's a MUST DONE (required by QA dudes), but they also want to provide an ICE ATP (not intrusive, but not directly requested, so it's a sort of intenral ATP): both of them requires the source code modified as my new tools is going to do (my boss justified that it costs the less, by several number of magnitude in term of dollars, than asking VectorCast-dudes to create such a tool, even if … you can't absolutely use an internal tool to do certifications, it's just for your personal engineering purpose)

Technically speaking the ICE ATP is performed with a WindRiver ICE for PowerPC440/460, it's phisically a "black box" (like a jtag-black-box but with an RJ45 plug) with a sort of hardware debug port (it's not jtag, it's not BDM, it's not NEXUS, I do not know what it is, I have no manual here, and no time to investigate, I am waiting for the first occasion to ask to an "hw" dude as soon as he will have his coffee break), with a Gigabit/sec ethernet port and up to 256Mbyte of DDR ram, able to collect thousand and thousand of triplets without breaking the CPU on hardware and software "breakpoints".

Other testes require the use of a Digital Oscilloscope (DSO), plus a test-case software (special ATP+ATR, hw dependent)

my apologies to who is heart sensitive, it's not easy to hear for me too

edit: I forgot

Last but not least, it seems that level B has the ARINC (419/429/575/573/717) interface cards with 32-bit FPGA Protocol Engine, fully configurable Bit Rate, Bit Encoding, Word Length, Start/Sync and Stop Bits. This part is covered by an other squad, a part of them has also to verify the MIL-STD-1553 compliance

So about the quality, there are a lot of people involved into the product life cycle, I do not have the full view of the process: do not take my words as THE measure of the quality in Avionics
« Last Edit: November 22, 2015, 01:36:21 pm by legacy »
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: [SOLVED] funny CC
« Reply #87 on: November 22, 2015, 01:28:38 pm »
Meanwhile this topic is turning into "engineering ethics". Should we change the title?

done  :-+
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: [SOLVED] funny CC
« Reply #88 on: November 22, 2015, 01:41:41 pm »
who believe that if all the unit tests have been passed then the software is correct
there are also integration tests, and a lot of other fine tests

There is zero philosophical difference between unit tests and integration tests. The only trivial difference is that the units being tested have changed.

To put it another way, all the tests you think of as unit tests are actually integration tests. For example, you are integrating your code with (unit1) library code and (unit2) compiler switches, and you are integrating that with the board (unit3) containing the computer. And the board containing the computer is the integration of a processor (unit4) some memory (unit5) the i/o hardware (unit6) and all the passive components including the PCB itself (unit7).

It is integration tests all the way down to transistors[1] and wires, and all the way up to an aircraft and the ATC systems.

[1] I'll ignore the electrons, but even they become problematic with smallest geometry devices.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #89 on: November 22, 2015, 05:12:15 pm »
Am I the only one being slightly worried by the slavish pursuit of MISRA this and DO-17... That?

Stepping back a little, none of those things give you reliable mission critical software, at most the help with reducing the incidence of silly mistakes (So they are valuable in that respect), but compliance is neither necessary nor sufficient to end up with reliable software (And C is **really** the wrong tool for critical systems, you should be writing in something much higher level if at all practical).
I have issues with the altogether too common management assumption that compliance with these standards makes a reliable system.

For me the really dangerous bugs are usually way up at the system level, races that only trigger on average once in a blue moon, Byzantine generals, weird cascade failures because some units fail safe state transition confused some other box, all that sort of thing, they are architectural and design bugs not ones easily amenable to software verification, and almost nobody makes a proper study of formal systems theory these days.
 
And, no I have only been doing this about 25 years (And I am first and foremost an analogue hardware designer anyway), my beard is not yet grey.

Regards, Dan.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #90 on: November 22, 2015, 07:18:17 pm »
DO-17... That?

SW: DO178B & DO178A, level A..D+E

And C is **really** the wrong tool for critical systems, you should be writing in something much higher level if at all practical

low level: assembly, manual check and justification
wrappers: inline assembly + C (defined as "unsafe code"), they MUST be manually checked and justified
BSP: C, MISRA QAC
iBSP: C, MISRA QAC
drivers: C, MISRA QAC
RT/OS: C, MISRA QAC (usually provided by Green Hills or other Vendors, so it's already certified)
-------------------------------------- end of my task view -------------------------------------
customer App: ADA

architectural and design bugs not ones easily amenable to software verification

Avionics is strongly pipelined job (like a "chain")
someone does design -> someone checks it -> someone prepares the C,ADA -> someone prepare ATP -> someone does tests -> someone takes decisions if/what/when/who reiterate


I have seen people using "Stood", it's a "design" program with AADL (which is a MUST in DO178A/B)
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #91 on: November 22, 2015, 07:23:34 pm »
In short, there is Model-Based Engineering with AADL (and HOOD)
their output is
  • my input about C testing (ATP/ATR)
  • the input to an other squad that has to verify others critical details (e.g. latency analysis)
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #92 on: November 22, 2015, 07:26:39 pm »
AADL tools, commercial and OpenSource
book Model-Based Engineering with AADL

 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: [SOLVED] funny CC
« Reply #93 on: November 23, 2015, 11:52:51 pm »
(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.

I'm mostly an FPGA guy, and I do VHDL, so I am used to (and prefer) a strongly-typed language. But I do plenty of micro firmware in C, and at two past jobs I've done Verilog. And all of this language-hopping has taught me a valuable less: don't count on language "features" like expression short-circuiting or sign-extension (Verilog is weird for this), and instead, just write explicit code.

For the example given, NeedToRunFunction() must have (because of its name) some side-effect (a hardware register access, whatever) that system operation requires. So I'd write this as:

Code: [Select]
if (1 == NeedToRunFunction())
{
    if (0 == empty)
    {
    }
}

The above makes my intentions explicit to both the compiler and the casual reader, the latter being someone who might not be as well-versed in the language as the experienced pro. (It also might be me, a year later.) I know that there's this subculture of programmers who love to do the obscure C coding thing (already referenced in this thread), but being clever doesn't score points in some game.
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8240
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #94 on: November 24, 2015, 05:08:42 am »
:palm: It's not "weird" or anything, it's called knowing the language. 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...
 

Offline djacobow

  • Super Contributor
  • ***
  • Posts: 1151
  • Country: us
  • takin' it apart since the 70's
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #95 on: November 24, 2015, 08:16:08 am »
:palm: It's not "weird" or anything, it's called knowing the language. 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...

Moreover, C is actually, a teensy, tiny language. It is not outrageous to expect a reader of C code to know the whole thing. Short circuiting expressions is part of the language. Writing truth tests without == 0 or != 0 is very idiomatic C.

Other languages are much bigger and I have more sympathy for those that suggest that code be reigned in from using every single feature. C++ is big. Perl is big. C, not so much.
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #96 on: November 24, 2015, 08:28:13 am »
Quote
C++ is big

I confess that I had had an on-off love affair with C++ when I wrote code for a living.

On the plus side it can be a beautifully expressive language.

On the minus side any language where you have to know the exact dynamic run-time type of "a" and "b" to know whether the statement a + b; will do something akin to addition or will withdraw all of the control rods from the nuclear reactor is not one that I would feel comfortable with for the implementation of safety critical systems.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #97 on: November 24, 2015, 09:12:18 am »
Quote
C++ is big

I confess that I had had an on-off love affair with C++ when I wrote code for a living.

On the plus side it can be a beautifully expressive language.

On the minus side any language where you have to know the exact dynamic run-time type of "a" and "b" to know whether the statement a + b; will do something akin to addition or will withdraw all of the control rods from the nuclear reactor is not one that I would feel comfortable with for the implementation of safety critical systems.

Just so.

Always worth remembering that the designers unwittingly created a Turing-complete sub-language. They were surprised when someone demonstrated that, during the compilation process you could get the compiler to emit the sequence of prime numbers, albeit very slowly. The culprit was the complexity of the interactions between templates and the rest of the language.

And that was when I vowed never to use C++ for anything non-trivial.

If the language designers didn't understand their creation, what chance is there for the rest of us?

Don't believe me? FFI: https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #98 on: November 24, 2015, 09:29:14 am »
If the language designers didn't understand their creation, what chance is there for the rest of us?

Don't believe me? FFI: https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP

Template meta programming is a powerful thing in the right hands...
and very very scary in the wrong hands.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #99 on: November 24, 2015, 09:35:12 am »
Always worth remembering that the designers unwittingly created a Turing-complete sub-language. They were surprised when someone demonstrated that, during the compilation process you could get the compiler to emit the sequence of prime numbers, albeit very slowly. The culprit was the complexity of the interactions between templates and the rest of the language.

And that was when I vowed never to use C++ for anything non-trivial.

If the language designers didn't understand their creation, what chance is there for the rest of us?

Don't believe me? FFI: https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP
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  :palm:
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #100 on: November 24, 2015, 09:40:00 am »
Short circuiting expressions is part of the language

Pretty False in Avionics :D

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  :o :o :o :o
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #101 on: November 24, 2015, 09:47:21 am »
Model-Based Engineering with AADL (and HOOD)

someone directly or indirectly experienced with such a things?
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #102 on: November 24, 2015, 09:51:41 am »
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  :o :o :o
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #103 on: November 24, 2015, 10:17:13 am »
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  :palm:
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.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #104 on: November 24, 2015, 10:56:48 am »
I haven't understood if we are allowed to use "restrict" (C99 feature)  :-//
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #105 on: November 24, 2015, 11:19:28 am »
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.
 

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #106 on: November 24, 2015, 11:54:10 am »
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
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #107 on: November 24, 2015, 12:19:14 pm »
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.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #108 on: November 24, 2015, 12:33:23 pm »
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
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #109 on: November 24, 2015, 12:37:31 pm »
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 :palm: :palm: :palm:
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  :palm: :palm: :palm: :palm:
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #110 on: November 24, 2015, 01:08:05 pm »
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 "{' … "}"
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #111 on: November 24, 2015, 02:54:50 pm »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #112 on: November 24, 2015, 04:18:46 pm »
:palm: 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.

Quote
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. 
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #113 on: November 24, 2015, 08:56:52 pm »
and a bit of confusion about "const" and "restrict"  :popcorn:
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #114 on: November 24, 2015, 08:59:32 pm »
not so clear that there is the need to demystify the restrict keyword  :palm: :palm: :palm:
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #115 on: November 24, 2015, 09:08:24 pm »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #116 on: November 25, 2015, 01:48:04 am »
Quote
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.)
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #117 on: November 25, 2015, 04:31:26 am »
Quote
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.
 

Offline AlfBaz

  • Super Contributor
  • ***
  • Posts: 2183
  • Country: au
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #118 on: November 25, 2015, 04:59:07 am »
Code: [Select]
   n -= 1;
I'm surprised that's not banned also  ::)
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #119 on: November 25, 2015, 05:16:01 am »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #120 on: November 25, 2015, 07:08:32 am »
Quote
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;
  }
}
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #121 on: November 25, 2015, 11:11:20 am »
  • char t1: banned, you have to use "uint8_t" (motivation I got: "because char can mean 16bit"  :wtf:  )
  • int n: banned, uint32_t

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

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

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #122 on: November 25, 2015, 11:12:02 am »
Code: [Select]
   n -= 1;
I'm surprised that's not banned also  ::)

indeed banned  :D

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  :-DD )
  • i*=const: banned
« Last Edit: November 25, 2015, 11:58:34 am by legacy »
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #123 on: November 25, 2015, 11:13:19 am »
AVR

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

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #124 on: November 25, 2015, 11:48:35 am »
  • char t1: banned, you have to use "uint8_t" (motivation I got: "because char can mean 16bit"  :wtf:  )

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
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #125 on: November 25, 2015, 01:59:54 pm »
Embarrassingly I got bitten by this in real production code within the last year or so, Analogue Devices Shark with sizeof (char) == sizeof (short) == sizeof (int) == 1;

All were actually 32 bit types, and 32 bits is the smallest addressable unit of memory, so this is actually standard compliant, just boring when a packed structure comes in over the SPI bus....

Regards, Dan.
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #126 on: November 25, 2015, 03:36:50 pm »
  • char t1: banned, you have to use "uint8_t" (motivation I got: "because char can mean 16bit"  :wtf:  )
  • int n: banned, uint32_t

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

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

char is 16 bit on some DSPs, and I think its even 24 bit in some places.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #127 on: November 25, 2015, 04:18:42 pm »
  • char t1: banned, you have to use "uint8_t" (motivation I got: "because char can mean 16bit"  :wtf:  )
  • int n: banned, uint32_t

The motivation is being more explicit about what you're doing, and anybody who doesn't understand that shouldn't be inflicting their code on the world.
No longer active here - try the IRC channel if you just can't be without me :)
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #128 on: November 25, 2015, 04:21:06 pm »
char is 16 bit on some DSPs, and I think its even 24 bit in some places.
And arguably 6-bit on some obsolete systems.

I wonder what it should be on the first computer I programmed, which had 5 channel paper tape for input and 39-bit words. (Exercise for youngsters: explain how the full symbol set could be represented on a 5 channel (i.e. 5 bit) paper tape).
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #129 on: November 25, 2015, 04:27:22 pm »
I wonder what it should be on the first computer I programmed, which had 5 channel paper tape for input and 39-bit words. (Exercise for youngsters: explain how the full symbol set could be represented on a 5 channel (i.e. 5 bit) paper tape).
Also explain how UTF8 is a failure to learn from baudot history.....

Regards, Dan.
 

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #130 on: November 25, 2015, 04:42:52 pm »
char is 16 bit on some DSPs, and I think its even 24 bit in some places.
And arguably 6-bit on some obsolete systems.

I wonder what it should be on the first computer I programmed, which had 5 channel paper tape for input and 39-bit words. (Exercise for youngsters: explain how the full symbol set could be represented on a 5 channel (i.e. 5 bit) paper tape).
There are so many way, but we can think of 39bit word + 1bit of parity => 40bit in total, 40/5 = 8 Columns for one word
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #131 on: November 25, 2015, 05:48:28 pm »
char is 16 bit on some DSPs, and I think its even 24 bit in some places.
And arguably 6-bit on some obsolete systems.

I wonder what it should be on the first computer I programmed, which had 5 channel paper tape for input and 39-bit words. (Exercise for youngsters: explain how the full symbol set could be represented on a 5 channel (i.e. 5 bit) paper tape).
There are so many way, but we can think of 39bit word + 1bit of parity => 40bit in total, 40/5 = 8 Columns for one word

It was 39bit words, full stop. And an architectural maximum of 8K words, with an instruction time of 576us. It also had a famous and influential Algol-60 compiler that fitted in 4K words - written by a certain CAR Hoare who went on to do other very influential work, notably CSP.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Godzil

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: fr
    • My own blog
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #132 on: November 25, 2015, 09:56:25 pm »
char is 16 bit on some DSPs, and I think its even 24 bit in some places.
And arguably 6-bit on some obsolete systems.

I wonder what it should be on the first computer I programmed, which had 5 channel paper tape for input and 39-bit words. (Exercise for youngsters: explain how the full symbol set could be represented on a 5 channel (i.e. 5 bit) paper tape).
There are so many way, but we can think of 39bit word + 1bit of parity => 40bit in total, 40/5 = 8 Columns for one word

It was 39bit words, full stop. And an architectural maximum of 8K words, with an instruction time of 576us. It also had a famous and influential Algol-60 compiler that fitted in 4K words - written by a certain CAR Hoare who went on to do other very influential work, notably CSP.
You can store a parity bit without having it part of the word, in fact a parity bit will never be part of the word. When you use a RS232 link, you can have 8bit data + 1 bit of parity, making transmitting 9 bits in total, but only 8 are really used. And I don't know how it was stored on your tape system, I was just making a guess, on how I would store
When you make hardware without taking into account the needs of the eventual software developers, you end up with bloated hardware full of pointless excess. From the outset one must consider design from both a hardware and software perspective.
-- Yokoi Gunpei
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #133 on: November 25, 2015, 10:55:34 pm »
char is 16 bit on some DSPs, and I think its even 24 bit in some places.
And arguably 6-bit on some obsolete systems.

I wonder what it should be on the first computer I programmed, which had 5 channel paper tape for input and 39-bit words. (Exercise for youngsters: explain how the full symbol set could be represented on a 5 channel (i.e. 5 bit) paper tape).
There are so many way, but we can think of 39bit word + 1bit of parity => 40bit in total, 40/5 = 8 Columns for one word

It was 39bit words, full stop. And an architectural maximum of 8K words, with an instruction time of 576us. It also had a famous and influential Algol-60 compiler that fitted in 4K words - written by a certain CAR Hoare who went on to do other very influential work, notably CSP.
You can store a parity bit without having it part of the word, in fact a parity bit will never be part of the word. When you use a RS232 link, you can have 8bit data + 1 bit of parity, making transmitting 9 bits in total, but only 8 are really used. And I don't know how it was stored on your tape system, I was just making a guess, on how I would store

Sigh. You can also store ECC without it being part of the word, but that wasn't done either. See https://en.wikipedia.org/wiki/Elliott_803

But this is too far off the topic to be worth continuing.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #134 on: November 25, 2015, 11:15:15 pm »
Quote
char t1: banned, you have to use "uint8_t"
int n: banned, uint32_t
That's sensible, assuming that the explicitly sized types have to be used everywhere (and don't run into some other edict to "only use compiler native types."  Heh.)   The original code didn't have any types, and indeed would work on any type (as would the "new" code), so I just picked one.
(I really, really, hope that "mycpy((uint8_t *)(&otherdatadest[0]), (uint8_t *)(&otherdatasource[0]), sizeof(otherdatasource[0]*NDATAELEMENTS);" is banned!)
(Are you allowed to use well-defined functions that violate rules?   While the example there is particularly ugly, so is having a different memcpy routine for each datatype.) (I've always found languages whose built-in functions violate the rules for user-written functions to be particularly annoying.  Grr.)

My first computer-of-choice stored text as 5 7-bit ascii characters per 36bit word.  (indeed, "bytes" could be any size between 1 and 36 bits, but they were only "individually addressable" in weird ways.)  The people working on the C compilers for it were ... frustrated.  (and this was the same timeframe that the ARPANet interfaces were essentially 1-bit parallel ports, so as not to impose any restrictions on native word sizes.)  Architecture is SO BORING these days.
Quote
i++: banned   i--: banned  ++i: banned  --i: banned  i+=const: banned  i-=const: banned
Now they're just being silly.  ("Did you ever hear of a COBOL program that gave up millions of users' private data due to a coding bug?  No!  Everything should look like COBOL!")
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #135 on: November 26, 2015, 12:03:38 am »
mycpy((uint8_t *)(&otherdatadest[0]), (uint8_t *)(&otherdatasource[0]), sizeof(otherdatasource[0]*NDATAELEMENTS);" is banned

banned && you get fired, directly  :D
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #136 on: November 26, 2015, 12:16:50 am »
Are you allowed to use well-defined functions that violate rules? 

everything that violates rules is rejected by QAC & QA-dudes, even if, in case of need, you can put "non conformal code" into a "unsafe-code" sections, which means they MUST be separated files (out of the QAC-folder), excluded by QAC check but provided with interfaces(1), so they are "opaque" modules which need to be MUST BE manually justified: practically you have to justify statement by statement and confirmed under your responsibility, signing with your blood  :D

the same is applied to ADA


(1) C prototype and public variables/types/consts/etc
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #137 on: November 26, 2015, 12:56:42 am »
char is 16 bit on some DSPs, and I think its even 24 bit in some places.
And arguably 6-bit on some obsolete systems.

I wonder what it should be on the first computer I programmed, which had 5 channel paper tape for input and 39-bit words. (Exercise for youngsters: explain how the full symbol set could be represented on a 5 channel (i.e. 5 bit) paper tape).

Oh stop, I'm getting all teary eyed. Having this manual is a bit like people keep wedding albums.





 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #138 on: November 26, 2015, 01:08:17 am »
char is 16 bit on some DSPs, and I think its even 24 bit in some places.
And arguably 6-bit on some obsolete systems.

I wonder what it should be on the first computer I programmed, which had 5 channel paper tape for input and 39-bit words. (Exercise for youngsters: explain how the full symbol set could be represented on a 5 channel (i.e. 5 bit) paper tape).

Oh stop, I'm getting all teary eyed. Having this manual is a bit like people keep wedding albums.
Elliott Bros - the aerospace company that hired many of the people who had made 2001: A Space Odyssey, when the MGM Borehamwood studios, just across the road from them, closed down.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #139 on: November 26, 2015, 01:23:06 am »
Quote
Quote
Are you allowed to use well-defined functions that violate rules?
everything that violates rules is rejected by QAC & QA-dudes
But ... do you get to use memcpy() and memset(), or not?  If not, that means writing a poorly-optimized and less well-tested copy function for each different data type you need to use.   And what do you do about the compiler's internal use of such functions?
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #140 on: November 26, 2015, 11:08:34 am »
But ... do you get to use memcpy() and memset(), or not?

you have there choices
  • use what provided by libC (which is included in your toolchain suite, if "it's approved", formally you have "C compiler unit", "assembler unit", "linker unit", "linker script unit", "memory model unit", and "libC unit" (bare metal profiled, of course), "crt0.s unit", all of them MUST be formally approved)
  • write your own version of memcpy&C, universal type (which means that you have to force everything to be p_uint8_t/8bit size ---> you need unchecked converter because "casting" is banned)
  • write your own versions of $type_memcpy&C

$type_memcpy means you to write

$type={ uint8, uint16, uint32, uint64, char }
for item in $type, do write "$type_memcpy"

(Stood is able to auto build code for you)

Casting is banned, so if you have to force everything to be uint8, you have to use "unchecked converter"

$type={ uint8, uint16, uint32, uint64, char }
for item in $type, do write "uc_$type_to_uint8(p_$type_t p)

they are functions, written in assembly, under "unsafe code" section

note the prefix "p_" it means "pointer", it's MUST in our conforming code

you could, also, write the full memcopy in assembly, and export it as "unsafe code"

I repeat again: everything is under the name of  "unsafe code" MUST be manually checked, justified, and hardly tested twice the twice
and you'd better remember you are signing with your blood  :D


And what do you do about the compiler's internal use of such functions?

are you kidding ?  :D
we do not have any "collision" with libC (if it's allowed be used): a collision means QAC immediately refuses the code!

Stood & QAC knows everything in the project (formally a project is a collection of modules, each module is collection of items, described by their interfaces)
they know which kind of libC you are using and what is provide by libC (because libC is formally a module, opaque, it means "black box")

You can't redefine a function that is included in libC without getting QAC to stop kicking you on your finger tips!

formally it's a "collision" (public interface collision) with a module!


libC.c ----> libC.interface
exported symbol: memcopy

my_module.c ----> my_module.interface
exported symbol: memcopy


QAC will say something like "ERROR, public collision between libC.interface and my_module.interface: memcopy defined twice"

there is a special attribute "reserved"

libC.interface
exported symbol: memcopy (reserved)

my_module.private
exported symbol: memcopy


"private" is the same as "static" in the C89 language, but … it's used to describe "private" interface (internal C prototypes, QAC uses it as "an attribute" for it's internal data base, there is a data base for each project, because "QAC "MUST be interfaced with "DOORS", which is formally the last suite to be used in order to present a product to QA guys and to the customer)

in this case "memcopy" is a private function, so it "could" overload the libC version, but QAC knows that it's "reserved"

so QAC will say something like "ERROR, public collision between libC.interface and my_module.private: memcopy is reserved, it can't be overloaded"
« Last Edit: November 26, 2015, 11:26:14 am by legacy »
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: engineering ethics (it was [SOLVED] funny CC)
« Reply #141 on: November 26, 2015, 11:12:43 am »
char is 16 bit on some DSPs, and I think its even 24 bit in some places.
And arguably 6-bit on some obsolete systems.

I wonder what it should be on the first computer I programmed, which had 5 channel paper tape for input and 39-bit words. (Exercise for youngsters: explain how the full symbol set could be represented on a 5 channel (i.e. 5 bit) paper tape).
Oh stop, I'm getting all teary eyed. Having this manual is a bit like people keep wedding albums.

Porn should have no place on the forum :)

I only have the A6-ish handbook of the instruction set, and an audio tape of it performing some tricks and clucking like a broody hen while "fetching-Algol" from the mag film.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf