'=' and '==' makes possible what is probably the most common error, and
which the compiler doesn't catch:
if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */
I imagine that there are probably some pre-processors that would return a
WARNING for it.
On Fri, 29 Jan 2021, wrco...@wrcooke.net wrote:
Modern Visual Studio and GCC both flag the "=" in a condition, I
believe. But if you're shipping code with 260+ warnings, who would see
one more.
Yet, '=' in a condition is not necessarily a fault.
while (*T++ = *S++); /* is the guts of strcpy */
But, it can certainly still blow up in your face.
If you want to insert a character at the beginning of a string pointed
to by P1,
P2 = P1 + 1;
strcpy(P2,P1); /* What went wrong? :-) */
For beginners, it would be nice to use a "SANDBOX" C with runtime error
checking. such that
Z = X / Y ;
would do a if (Y == 0) . . .
Z = X / Y ;
But, that would slow down stuff in the situations where it isn't needed.
Y = 2;
if (condition) Y = 3;
Z = X / Y ;
does NOT need that runtime error check.
An assumption in C (whether or not it is a valid assumption) is that the
programmer KNOWS where and what runtime checking is needed, and will
manually add it in where needed. The problem, of course, is that they
DON'T.
There's a pretty good chance the heat pump you're using right now has
those warnings. Alas...
In some cases, it is possible to put in preprocessor directives to alert
the compiler that you are aware of it, and to NOT generate the WARNING.
Or, in many cases to modify the code, such as EXPLICIT typedefs to not
generate warnings.
int X = PI; /* should give a warning */
int x = (int)PI; /* should be OK, without a loss of efficiency */
It's scary that code gets shipped as soon as it "seems to be working",
without confirming that ALL of the 260+ WARNINGS are deliberately
over-ridden.
