engineering ethics (it was [SOLVED] funny CC) - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 03:45:21 pm
content: 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 gccCode: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)){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 sierraCCode: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);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 gccof course the "fixed" version is too pedantic, but just a proof of concept, in order to understand WTF is wrong in the original codeand as far as I understand WTF happened, my debug TAP has found that the problem is around the following lineCode:if ((p_node->parent isNotEqualTo NULL)logicalAnd(p_node isEqualTo p_node->parent->pointer))more specifically (analyzing the assembly code) it seems that it depends by the CC implementationSierraCseems to implement the IF-STATEMENT asstep1: eval (p_node->parent isNotEqualTo NULL)step2: eval (p_node isEqualTo p_node->parent->pointer)step3: if they are both True then take the IF branch, else take the ELSE branchGCCseems to implement the IF-STATEMENT asstep1: eval (p_node->parent isNotEqualTo NULL)step2: if the previous eval is True then eval (p_node isEqualTo p_node->parent->pointer)step3: if (is_ok2 isEqualTo True) then take the IF branch, else take the ELSE branchso the problem with SierraC is … with "p_node->parent->pointer" which crashes when "p_node->parent" is NULLif so, it means that I have 4K lines of C to be fixed

author: Kalvin
author_rank: Super Contributor
timestamp: November 20, 2015, 04:11:52 pm
content: You may want to check for the compiler switch for the "short-circuit" evaluation.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 20, 2015, 04:16:08 pm
content: 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.

author: grumpydoc
author_rank: Super Contributor
timestamp: November 20, 2015, 04:24:49 pm
content: isNotEqualTo, logicalAnd etc - just use the *&^%!!! language FFSThese sort of shenanigans do not, in general, help write bug free code.

author: newbrain
author_rank: Super Contributor
timestamp: November 20, 2015, 04:49:46 pm
content: 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...):QuoteThe sequence point and definition guarantee that the second operand:will only be evaluated if the first one is non-zeroits (possible) evaluation will happen only when all the side effects of the first one are completedK&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.

author: Howardlong
author_rank: Super Contributor
timestamp: November 20, 2015, 05:12:40 pm
content: Quote from: grumpydoc on November 20, 2015, 04:24:49 pmPretty 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.

author: grumpydoc
author_rank: Super Contributor
timestamp: November 20, 2015, 05:16:33 pm
content: QuoteMy copy of K&R clearly states that && and || stop evaluation as soon as the value of the whole expression is known.

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 05:25:21 pm
content: Quote from: 0xdeadbeef on November 20, 2015, 04:16:08 pmit's the alias for "&&"Code:#define logicalAnd &&I had to use the alias for an internal reason (my boss wants this way)Quote from: 0xdeadbeef on November 20, 2015, 04:16:08 pm

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 05:32:28 pm
content: Quote from: newbrain on November 20, 2015, 04:49:46 pmyes it isQuote from: newbrain on November 20, 2015, 04:49:46 pmit's more horrible to see "&&", which can be confused with "&"Quote from: newbrain on November 20, 2015, 04:49:46 pmI am really afraid they are not C89Quote from: newbrain on November 20, 2015, 04:49:46 pmexactly what happensQuote from: newbrain on November 20, 2015, 04:49:46 pmSo it might be a pre-ANSI-C compiler, or probably they have give me the wrong compiler versionor it's not configured in the right way (missing FLAGS? missing external profile that "enables/disables" features? who knows)

author: newbrain
author_rank: Super Contributor
timestamp: November 20, 2015, 05:45:08 pm
content: Quote from: grumpydoc on November 20, 2015, 05:16:33 pmI stand corrected, unless that copy is the "Second Edition" (that is, already ANSI). My original one is long lostQuoteTo each their own. I do not agree in the least, but if you are fine with thatCode:#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.

author: Godzil
author_rank: Frequent Contributor
timestamp: November 20, 2015, 05:47:25 pm
content: 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..

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 05:51:49 pm
content: Quote from: Howardlong on November 20, 2015, 05:12:40 pmemmm, 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)

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 06:01:00 pm
content: Quote from: Godzil on November 20, 2015, 05:47:25 pmyes, but it's not the SierraC Compiler that was bought by TI and used for their calculatorsI can say that because it supports CPU32 (683xx) which was not supported by the TI versionhere 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 equipmentI 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)

author: Godzil
author_rank: Frequent Contributor
timestamp: November 20, 2015, 06:05:06 pm
content: Avionics that use that crap compiler?!?!? O_O

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 06:16:23 pm
content: * * * solution found * * *there is a profile file (.bat?) in the bin path which has the following lineCode:SET ev_shortcircuit 0I have changed intoCode:SET ev_shortcircuit 1and everything is now working as expectedso, it seems that it's really possible to "disable" that featuretoo amazing

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 06:34:25 pm
content: Quote from: legacy on November 20, 2015, 05:51:49 pmwhen you have this setCode:SET ev_wall 0I have changed intoCode:SET ev_wall 1and now it offers a lot of useful warningsconclusion: the environment was not configured in the proper way!

author: Jeroen3
author_rank: Super Contributor
timestamp: November 20, 2015, 06:39:53 pm
content: Quote from: legacy on November 20, 2015, 05:25:21 pmApparently your boss does not know C, but still wants to read it.Send him on C-bootcamp or something.

author: tggzzz
author_rank: Super Contributor
timestamp: November 20, 2015, 06:42:54 pm
content: Quote from: legacy on November 20, 2015, 05:25:21 pmWhy don't you suggest also using#define begin {#define end }Of course, if your boss cannot expainwhythey want something, then you shold get another boss.

author: Ian.M
author_rank: Super Contributor
timestamp: November 20, 2015, 07:04:04 pm
content: Lets go the whole hog!Code:#define if if(#define then )

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 07:57:22 pm
content: Quote from: Jeroen3 on November 20, 2015, 06:39:53 pmhe is a pro ADA dude, probably too Pascal addicted

author: richardman
author_rank: Frequent Contributor
timestamp: November 20, 2015, 08:10:53 pm
content: You have a broken compiler and a broken boss. This could not be good for your career.

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 08:11:03 pm
content: Quote from: tggzzz on November 20, 2015, 06:42:54 pmand 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 to1) 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 avionicsbut yes, if you can employ me, I will change my job

author: grumpydoc
author_rank: Super Contributor
timestamp: November 20, 2015, 08:16:07 pm
content: Quote1st edition, bought 1986 according to the note I pot on the fly sheet. I had an earlier printing but mislaid it.QuoteYou can always use the"if (0==a){}"trick.QuoteWell, whoever pays the piper calls the tune I suppose.

author: djacobow
author_rank: Super Contributor
timestamp: November 20, 2015, 08:19:15 pm
content: I don't know why I feel the need to chime in, but not only iswhile (p_btree->context.queue isNotEqualTo NULL) { ... }barfalicious, but evenwhile(p_btree->context.queue != NULL) { ... } is awfulThis 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.

author: Godzil
author_rank: Frequent Contributor
timestamp: November 20, 2015, 08:52:20 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: November 20, 2015, 08:56:06 pm
content: Quote from: legacy on November 20, 2015, 08:11:03 pmIf 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 athttp://catless.ncl.ac.uk/RisksFor 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.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 20, 2015, 09:01:08 pm
content: Quote from: djacobow on November 20, 2015, 08:19:15 pmUsually 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.

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 09:12:04 pm
content: Quote from: tggzzz on November 20, 2015, 08:56:06 pmI know what I need to know: I have to do source code refactoringinstead of ranting against MISRA + DO178/A + MIL STD rulesbut the question is to you, can YOU explain to me ?people usually react with rants against the idiomatic violationand I want to know if they have a reasonable explanation

author: legacy
author_rank: Super Contributor
timestamp: November 20, 2015, 09:15:03 pm
content: Quote from: 0xdeadbeef on November 20, 2015, 09:01:08 pmexactly, we have converted the C language into "strong type"there are constraints about that (practically QAC rules)

author: grumpydoc
author_rank: Super Contributor
timestamp: November 20, 2015, 09:20:55 pm
content: QuoteIn 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.

author: grumpydoc
author_rank: Super Contributor
timestamp: November 20, 2015, 09:37:49 pm
content: QuoteYes, 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.eif(x == 0)..., rather thanif (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.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 20, 2015, 10:32:25 pm
content: 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/

author: Godzil
author_rank: Frequent Contributor
timestamp: November 20, 2015, 11:33:03 pm
content: Quote from: Jeroen3 on November 20, 2015, 10:32:25 pmNo 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 //

author: Phoenix
author_rank: Frequent Contributor
timestamp: November 20, 2015, 11:46:37 pm
content: Quote from: Jeroen3 on November 20, 2015, 10:32:25 pmIt'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.

author: djacobow
author_rank: Super Contributor
timestamp: November 20, 2015, 11:48:35 pm
content: Quote from: grumpydoc on November 20, 2015, 09:20:55 pmWhich 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.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 21, 2015, 12:17:03 am
content: 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.

author: AlfBaz
author_rank: Super Contributor
timestamp: November 21, 2015, 12:22:40 am
content: Quote from: djacobow on November 20, 2015, 11:48:35 pmVery much thisIn 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

author: tggzzz
author_rank: Super Contributor
timestamp: November 21, 2015, 12:50:13 am
content: Quote from: AlfBaz on November 21, 2015, 12:22:40 am+1, very much so.Since the compiler options can completely change the functioning of the code, they really,reallyought to be regarded as part of the code.But then the problem is that what they dochangesas 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 cannottestquality into a product, you can onlydesignquality into a product.

author: westfw
author_rank: Super Contributor
timestamp: November 21, 2015, 12:52:27 am
content: QuoteSo, 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?

author: legacy
author_rank: Super Contributor
timestamp: November 21, 2015, 01:00:11 am
content: Quote from: westfw on November 21, 2015, 12:52:27 amgood 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.

author: legacy
author_rank: Super Contributor
timestamp: November 21, 2015, 01:03:16 am
content: gcc has these interesting flagsCode:-ansi -pedantic -Wall -W

author: grumpydoc
author_rank: Super Contributor
timestamp: November 21, 2015, 09:32:38 am
content: Quote from: legacy on November 21, 2015, 01:03:16 amYou forgot -Werror (and -W properly should be -Wextra)Quote from: 0xdeadbeefTrue but if it complains abouttype *ptr = 0;then it is broken.

author: richardman
author_rank: Frequent Contributor
timestamp: November 21, 2015, 09:40:46 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: November 21, 2015, 10:02:56 am
content: Quote from: richardman on November 21, 2015, 09:40:46 amhave you ever locked at the K&R implementation of malloc?

author: grumpydoc
author_rank: Super Contributor
timestamp: November 21, 2015, 10:07:49 am
content: Quote from: richardman on November 21, 2015, 09:40:46 am+1In fact it has been standard since K&RWhere 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 wasnotall bits 0.With function prototypes there is no need for this but it has hung around.Quote+ several hundred.

author: legacy
author_rank: Super Contributor
timestamp: November 21, 2015, 10:17:28 am
content: Quote from: AlfBaz on November 21, 2015, 12:22:40 amthere 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 SierraCif this is true (I have to find and check its documentation), I'd like to know WHY?

author: tggzzz
author_rank: Super Contributor
timestamp: November 21, 2015, 11:40:31 am
content: Quote from: legacy on November 21, 2015, 10:17:28 amYou 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 waspartiallyfilled 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".

author: Godzil
author_rank: Frequent Contributor
timestamp: November 21, 2015, 11:44:01 am
content: Quote from: legacy on November 21, 2015, 10:17:28 amI'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:if ( (empty == 0) && (NeedToRunFunction() == 1) )If empty is equal to 0, NeedToRunFunction is not warranted to be run at all.

author: richardman
author_rank: Frequent Contributor
timestamp: November 21, 2015, 12:05:20 pm
content: Quote from: legacy on November 21, 2015, 10:02:56 amWhat about it? It's a simple first fit algorithm. I tend to use pointer to pointer to manage lists, but so what?

author: legacy
author_rank: Super Contributor
timestamp: November 21, 2015, 01:16:03 pm
content: Quote from: richardman on November 21, 2015, 12:05:20 pmjust 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!

author: legacy
author_rank: Super Contributor
timestamp: November 21, 2015, 01:23:56 pm
content: Quote from: Godzil on November 21, 2015, 11:44:01 amyes, 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) because the software has to be validated by VectorCast withinlevel B, so every if () statement has to be evaluated in deeplyit means that if you have if (a && b) you have to prove (through VectorCast test reports) that you have covered the full True tablea-b----0-00-11-01-1I am a bit shocked to hear that

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 21, 2015, 02:50:37 pm
content: Quote from: grumpydoc on November 21, 2015, 10:07:49 amThis 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 21, 2015, 03:18:59 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: November 21, 2015, 04:13:09 pm
content: Quote from: Jeroen3 on November 21, 2015, 03:18:59 pmWelcome 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".

author: richardman
author_rank: Frequent Contributor
timestamp: November 21, 2015, 09:28:01 pm
content: Quote from: Jeroen3 on November 21, 2015, 03:18:59 pmPlease emphasize that this is a bug in thecompiler, 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 21, 2015, 10:33:45 pm
content: 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.

author: helius
author_rank: Super Contributor
timestamp: November 21, 2015, 10:42:02 pm
content: 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 instrongly-typedlanguages, casts do not exist.

author: richardman
author_rank: Frequent Contributor
timestamp: November 21, 2015, 10:43:44 pm
content: Quote from: legacy on November 21, 2015, 01:16:03 pmDon'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.

author: tggzzz
author_rank: Super Contributor
timestamp: November 21, 2015, 11:21:27 pm
content: Quote from: helius on November 21, 2015, 10:42:02 pmJava'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".

author: legacy
author_rank: Super Contributor
timestamp: November 21, 2015, 11:40:30 pm
content: Quote from: Jeroen3 on November 21, 2015, 10:33:45 pmgcc v5 ?

author: grumpydoc
author_rank: Super Contributor
timestamp: November 21, 2015, 11:50:33 pm
content: QuoteThe things which Java is good at tend not to require circumvention of the type system.The things which C is good atoccasionallyrequire flexibility in the type system.

author: richardman
author_rank: Frequent Contributor
timestamp: November 21, 2015, 11:50:43 pm
content: 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.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 21, 2015, 11:56:19 pm
content: Quote from: helius on November 21, 2015, 10:42:02 pmSorry, 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.

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 12:20:25 am
content: Quote from: grumpydoc on November 21, 2015, 11:50:33 pmummm

author: gmb42
author_rank: Frequent Contributor
timestamp: November 22, 2015, 12:28:50 am
content: Quote from: 0xdeadbeef on November 21, 2015, 11:56:19 pmI'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.

author: tggzzz
author_rank: Super Contributor
timestamp: November 22, 2015, 12:49:26 am
content: Quote from: gmb42 on November 22, 2015, 12:28:50 amJava'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.

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 01:00:38 am
content: I guess we'd better talk about ADA and their motd "in strong state-type we trust"

author: westfw
author_rank: Super Contributor
timestamp: November 22, 2015, 02:58:02 am
content: Quote"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...

author: amyk
author_rank: Super Contributor
timestamp: November 22, 2015, 03:49:28 am
content: There is not enoughto 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.Quote from: 0xdeadbeef on November 20, 2015, 09:01:08 pm...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...)

author: helius
author_rank: Super Contributor
timestamp: November 22, 2015, 05:00:03 am
content: Quote from: tggzzz on November 21, 2015, 11:21:27 pmInteresting equivocation. Are you saying that only the "objects" are strongly typed, and the rest of the language doesn't count?In Java you can break the integrity of the type system as soon as you declare an array.Code:String[] strings = new String;Object[] objects = strings;objects = new Integer(1);Quote from: 0xdeadbeef on November 21, 2015, 11:56:19 pmIf 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.

author: tggzzz
author_rank: Super Contributor
timestamp: November 22, 2015, 09:40:21 am
content: Quote from: helius on November 22, 2015, 05:00:03 amI did not say thelanguagewas 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) and see what happens.

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 10:27:55 am
content: 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 diesQuote from: westfw on November 22, 2015, 02:58:02 amthe "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 conditionwe 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)

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 10:38:06 am
content: Quote from: Jeroen3 on November 21, 2015, 10:33:45 pmare you speaking about Keil/uVision using the ARMCC compiler v 5.03.0.76 ?is GCC v>=v4.9/5.* bugged too ?

author: Ian.M
author_rank: Super Contributor
timestamp: November 22, 2015, 10:38:34 am
content: 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.

author: Godzil
author_rank: Frequent Contributor
timestamp: November 22, 2015, 10:57:56 am
content: 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.

author: richardman
author_rank: Frequent Contributor
timestamp: November 22, 2015, 11:05:36 am
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: November 22, 2015, 11:11:06 am
content: Quote from: legacy on November 22, 2015, 10:27:55 amQualityrequiresfar 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.

author: grumpydoc
author_rank: Super Contributor
timestamp: November 22, 2015, 11:18:40 am
content: Quote from: legacy on November 22, 2015, 12:20:25 amYes, sorry, perhaps too much wineWhat 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.

author: dmills
author_rank: Super Contributor
timestamp: November 22, 2015, 11:20:40 am
content: 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.

author: grumpydoc
author_rank: Super Contributor
timestamp: November 22, 2015, 11:27:33 am
content: Quote from: Ian.M on November 22, 2015, 10:38:34 amI 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 withanyC 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.

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 11:44:23 am
content: Quote from: Ian.M on November 22, 2015, 10:38:34 amit'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

author: Ian.M
author_rank: Super Contributor
timestamp: November 22, 2015, 11:48:49 am
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: November 22, 2015, 12:24:58 pm
content: Quote from: dmills on November 22, 2015, 11:20:40 amVery 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.

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 12:35:10 pm
content: Quote from: tggzzz on November 22, 2015, 12:24:58 pmunit 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)

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 12:37:04 pm
content: Quote from: tggzzz on November 22, 2015, 12:24:58 pmnice quote

author: Jeroen3
author_rank: Super Contributor
timestamp: November 22, 2015, 01:10:43 pm
content: Quote from: legacy on November 22, 2015, 10:38:06 amI 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?

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 01:25:30 pm
content: so, it's seem that I am going to understand the a few pointsI 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-Din 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 neededCode:var.A var.B then-branch------------------------False False not takenFalse True not takenTrue False not takenTrue True takenTrue table, coverage, Level D..ECode:var.A var.B then-branch detailed conditions-------------------------------------------------------False False not taken with var.A=False, var.B=FalseFalse True not taken with var.A=False, Var.B=TrueTrue False not taken with var.A=True , Var.B=FalseTrue True taken with var.A=True , Var.B=TrueTrue table, coverage, Level A..Bcoverage, 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 testsas 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.VectorCasttends 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 intrusiveThey got requested to provide a VectorCast test report (ATP), it's aMUST 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 tooedit: I forgotLast but not least, it seems that level B has theARINC(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 complianceSo 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

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 01:28:38 pm
content: Quote from: Jeroen3 on November 22, 2015, 01:10:43 pmdone

author: tggzzz
author_rank: Super Contributor
timestamp: November 22, 2015, 01:41:41 pm
content: Quote from: legacy on November 22, 2015, 12:35:10 pmThere 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 and wires, and all the way up to an aircraft and the ATC systems. I'll ignore the electrons, but even they become problematic with smallest geometry devices.

author: dmills
author_rank: Super Contributor
timestamp: November 22, 2015, 05:12:15 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 07:18:17 pm
content: Quote from: dmills on November 22, 2015, 05:12:15 pmSW: DO178B & DO178A, level A..D+EQuote from: dmills on November 22, 2015, 05:12:15 pmlow level: assembly, manual check and justificationwrappers: inline assembly + C (defined as "unsafe code"), they MUST be manually checked and justifiedBSP: C, MISRA QACiBSP: C, MISRA QACdrivers: C, MISRA QACRT/OS: C, MISRA QAC (usually provided by Green Hills or other Vendors, so it's already certified)-------------------------------------- end of my task view -------------------------------------customer App: ADAQuote from: dmills on November 22, 2015, 05:12:15 pmAvionics 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 reiterateI have seen people using "Stood", it's a "design" program withAADL(which is a MUST in DO178A/B)

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 07:23:34 pm
content: In short, there is Model-Based Engineering with AADL (and HOOD)their output ismy input about C testing (ATP/ATR)the input to an other squad that has to verify others critical details (e.g. latency analysis)

author: legacy
author_rank: Super Contributor
timestamp: November 22, 2015, 07:26:39 pm
content: AADL tools, commercial and OpenSourcebookModel-Based Engineering with AADL

author: Bassman59
author_rank: Super Contributor
timestamp: November 23, 2015, 11:52:51 pm
content: Quote from: Godzil on November 21, 2015, 11:44:01 amI'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: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.

author: amyk
author_rank: Super Contributor
timestamp: November 24, 2015, 05:08:42 am
content: It's not "weird" or anything, it's calledknowing 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...

author: djacobow
author_rank: Super Contributor
timestamp: November 24, 2015, 08:16:08 am
content: Quote from: amyk on November 24, 2015, 05:08:42 amMoreover, 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.

author: grumpydoc
author_rank: Super Contributor
timestamp: November 24, 2015, 08:28:13 am
content: QuoteI 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 statementa + 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.

author: tggzzz
author_rank: Super Contributor
timestamp: November 24, 2015, 09:12:18 am
content: Quote from: grumpydoc on November 24, 2015, 08:28:13 amJust so.Always worth remembering that the designersunwittinglycreated a Turing-complete sub-language. They weresurprisedwhen someone demonstrated that,during the compilation processyou 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

author: richardman
author_rank: Frequent Contributor
timestamp: November 24, 2015, 09:29:14 am
content: Quote from: tggzzz on November 24, 2015, 09:12:18 amTemplate meta programming is a powerful thing in the right hands...and very very scary in the wrong hands.

author: grumpydoc
author_rank: Super Contributor
timestamp: November 24, 2015, 09:35:12 am
content: Quote from: tggzzz on November 24, 2015, 09:12:18 amI'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

author: legacy
author_rank: Super Contributor
timestamp: November 24, 2015, 09:40:00 am
content: Quote from: djacobow on November 24, 2015, 08:16:08 amPretty False in AvionicsC89 << MISRA C/2004 << "SafeC" (our standard)"SafeC" (MISRA C/2004 + DO178A + MIL-STD) bansbreakcontinueshort circuitmultiple returnspassing pointers by referencegoto (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

author: legacy
author_rank: Super Contributor
timestamp: November 24, 2015, 09:47:21 am
content: Quote from: legacy on November 22, 2015, 07:23:34 pmsomeone directly or indirectly experienced with such a things?

author: legacy
author_rank: Super Contributor
timestamp: November 24, 2015, 09:51:41 am
content: 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

author: dmills
author_rank: Super Contributor
timestamp: November 24, 2015, 10:17:13 am
content: Quote from: grumpydoc on November 24, 2015, 09:35:12 amAlmost 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.

author: legacy
author_rank: Super Contributor
timestamp: November 24, 2015, 10:56:48 am
content: I haven't understood if we are allowed to use "restrict" (C99 feature)

author: grumpydoc
author_rank: Super Contributor
timestamp: November 24, 2015, 11:19:28 am
content: Quote from: dmills on November 24, 2015, 10:17:13 amAgreed, 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.

author: Godzil
author_rank: Frequent Contributor
timestamp: November 24, 2015, 11:54:10 am
content: Quote from: grumpydoc on November 24, 2015, 11:19:28 amA really good example of that is WebKit

author: dmills
author_rank: Super Contributor
timestamp: November 24, 2015, 12:19:14 pm
content: Quote from: legacy on November 24, 2015, 10:56:48 amI 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.

author: legacy
author_rank: Super Contributor
timestamp: November 24, 2015, 12:33:23 pm
content: Quote from: dmills on November 24, 2015, 12:19:14 pmwhat I have on hand now (C89): noNext Step, Green Hills C (=C99): yes

author: legacy
author_rank: Super Contributor
timestamp: November 24, 2015, 12:37:31 pm
content: Quote from: dmills on November 24, 2015, 12:19:14 pmthe current version of QaC (source code validator) is C89 and does not understand "restrict" because it's C99 featureI 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

author: legacy
author_rank: Super Contributor
timestamp: November 24, 2015, 01:08:05 pm
content: Code:while(n-- > 0) *t1++ = *t2++;a lot of bans heren--: banned if used with a comparen--: banned if inside while ()*t1: bannedt1++=: banned*t2: bannedt2++: bannedwhile without a block: banned, it must always have "{' … "}"

author: tggzzz
author_rank: Super Contributor
timestamp: November 24, 2015, 02:54:50 pm
content: Quote from: grumpydoc on November 24, 2015, 11:19:28 amAgreed, except that it is trivial to run the code in the debugger for Smalltalk 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). 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.

author: Bassman59
author_rank: Super Contributor
timestamp: November 24, 2015, 04:18:46 pm
content: Quote from: amyk on November 24, 2015, 05:08:42 amLook 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.QuoteHere'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:if (foo /= bar) {... this} else {... that}It compiled without warning or error, of course.

author: legacy
author_rank: Super Contributor
timestamp: November 24, 2015, 08:56:52 pm
content: and a bit ofconfusionabout "const" and "restrict"

author: legacy
author_rank: Super Contributor
timestamp: November 24, 2015, 08:59:32 pm
content: not soclearthat there is the need todemystifythe restrict keyword

author: dmills
author_rank: Super Contributor
timestamp: November 24, 2015, 09:08:24 pm
content: Quote from: Bassman59 on November 24, 2015, 04:18:46 pmThis 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.

author: westfw
author_rank: Super Contributor
timestamp: November 25, 2015, 01:48:04 am
content: QuoteSo the conforming version would be something like:Code:while (n > 0) {n -= 1;t1 = t2;}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.)

author: coppice
author_rank: Super Contributor
timestamp: November 25, 2015, 04:31:26 am
content: Quote from: westfw on November 25, 2015, 01:48:04 amThose two pieces of code are not equivalent.

author: AlfBaz
author_rank: Super Contributor
timestamp: November 25, 2015, 04:59:07 am
content: Quote from: westfw on November 25, 2015, 01:48:04 amI'm surprised that's not banned also

author: coppice
author_rank: Super Contributor
timestamp: November 25, 2015, 05:16:01 am
content: Quote from: AlfBaz on November 25, 2015, 04:59:07 amWhy? That's a construct they helps reduce stupid typos, which is the theme of a lot of the MISRA restrictions.

author: westfw
author_rank: Super Contributor
timestamp: November 25, 2015, 07:08:32 am
content: QuoteTrue. 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: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 = t2;n -= 1;i += 1;}}

author: legacy
author_rank: Super Contributor
timestamp: November 25, 2015, 11:11:20 am
content: char t1: banned, you have to use "uint8_t" (motivation I got: "because char can mean 16bit")int n: banned, uint32_tsigned $SIZE ----> sint$SIZE_tunsigned $SIZE ---> uint$SIZE_t$SIZE={8, 16, 32, 64}

author: legacy
author_rank: Super Contributor
timestamp: November 25, 2015, 11:12:02 am
content: Quote from: AlfBaz on November 25, 2015, 04:59:07 amindeed bannedin level A/Bi++: bannedi--: banned++i: banned--i: bannedi+=const: bannedi-=const: bannedi/=const: super banned (threat to be fired)i*=const: banned

author: legacy
author_rank: Super Contributor
timestamp: November 25, 2015, 11:13:19 am
content: Quote from: westfw on November 25, 2015, 07:08:32 amthey use "PowerPC", like PPC440, PPC460we should also compare with MIPS32 (not used in avionics)

author: Godzil
author_rank: Frequent Contributor
timestamp: November 25, 2015, 11:48:35 am
content: Quote from: legacy on November 25, 2015, 11:11:20 amThat'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

author: dmills
author_rank: Super Contributor
timestamp: November 25, 2015, 01:59:54 pm
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: November 25, 2015, 03:36:50 pm
content: Quote from: legacy on November 25, 2015, 11:11:20 amchar is 16 bit on some DSPs, and I think its even 24 bit in some places.

author: c4757p
author_rank: Super Contributor
timestamp: November 25, 2015, 04:18:42 pm
content: Quote from: legacy on November 25, 2015, 11:11:20 amThe motivation is being more explicit about what you're doing, and anybody who doesn't understandthatshouldn't be inflicting their code on the world.

author: tggzzz
author_rank: Super Contributor
timestamp: November 25, 2015, 04:21:06 pm
content: Quote from: coppice on November 25, 2015, 03:36:50 pmAnd 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).

author: dmills
author_rank: Super Contributor
timestamp: November 25, 2015, 04:27:22 pm
content: Quote from: tggzzz on November 25, 2015, 04:21:06 pmAlso explain how UTF8 is a failure to learn from baudot history.....Regards, Dan.

author: Godzil
author_rank: Frequent Contributor
timestamp: November 25, 2015, 04:42:52 pm
content: Quote from: tggzzz on November 25, 2015, 04:21:06 pmThere are so many way, but we can think of 39bit word + 1bit of parity => 40bit in total, 40/5 = 8 Columns for one word

author: tggzzz
author_rank: Super Contributor
timestamp: November 25, 2015, 05:48:28 pm
content: Quote from: Godzil on November 25, 2015, 04:42:52 pmIt 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.

author: Godzil
author_rank: Frequent Contributor
timestamp: November 25, 2015, 09:56:25 pm
content: Quote from: tggzzz on November 25, 2015, 05:48:28 pmYou 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

author: tggzzz
author_rank: Super Contributor
timestamp: November 25, 2015, 10:55:34 pm
content: Quote from: Godzil on November 25, 2015, 09:56:25 pmSigh. You can also store ECC without it being part of the word, but that wasn't done either. Seehttps://en.wikipedia.org/wiki/Elliott_803But this is too far off the topic to be worth continuing.

author: westfw
author_rank: Super Contributor
timestamp: November 25, 2015, 11:15:15 pm
content: QuoteThat's sensible, assuming that the explicitly sized types have to be usedeverywhere(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), (uint8_t *)(&otherdatasource), sizeof(otherdatasource*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.QuoteNow 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!")

author: legacy
author_rank: Super Contributor
timestamp: November 26, 2015, 12:03:38 am
content: Quote from: westfw on November 25, 2015, 11:15:15 pmbanned && you get fired, directly

author: legacy
author_rank: Super Contributor
timestamp: November 26, 2015, 12:16:50 am
content: Quote from: westfw on November 25, 2015, 11:15:15 pmeverything 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 BEmanually justified: practically you have to justify statement by statement and confirmed under your responsibility, signing with your bloodthe same is applied to ADA(1) C prototype and public variables/types/consts/etc

author: Howardlong
author_rank: Super Contributor
timestamp: November 26, 2015, 12:56:42 am
content: Quote from: tggzzz on November 25, 2015, 04:21:06 pmOh stop, I'm getting all teary eyed. Having this manual is a bit like people keep wedding albums.

author: coppice
author_rank: Super Contributor
timestamp: November 26, 2015, 01:08:17 am
content: Quote from: Howardlong on November 26, 2015, 12:56:42 amElliott 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.

author: westfw
author_rank: Super Contributor
timestamp: November 26, 2015, 01:23:06 am
content: QuoteBut ... 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?

author: legacy
author_rank: Super Contributor
timestamp: November 26, 2015, 11:08:34 am
content: Quote from: westfw on November 26, 2015, 01:23:06 amyou have there choicesuse 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 themMUSTbe 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" sectionnote the prefix "p_" it means "pointer", it's MUST in our conforming codeyou 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 twiceand you'd better rememberyou are signing with your bloodQuote from: westfw on November 26, 2015, 01:23:06 amare you kidding ?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.interfaceexported symbol: memcopymy_module.c ----> my_module.interfaceexported symbol: memcopyQAC will say something like "ERROR, public collision between libC.interface and my_module.interface: memcopy defined twice"there is a special attribute "reserved"libC.interfaceexported symbol: memcopy (reserved)my_module.privateexported 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"

author: tggzzz
author_rank: Super Contributor
timestamp: November 26, 2015, 11:12:43 am
content: Quote from: Howardlong on November 26, 2015, 12:56:42 amPorn should have no place on the forumI 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.