-
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
) 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
-
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).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
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. -
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. -
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". -
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. -
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.
-
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.
-
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. -
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". -
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.
-
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.
-
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. -
The things which C is good at occasionally require flexibility in the type system.
ummm
-
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. -
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. -
I guess we'd better talk about ADA and their motd "in strong state-type we trust"
-
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...
-
There is not enough
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...) -
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?
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. -
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?
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. -
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)
-
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 ? -
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. -
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.