APL\360

[Fred Cisin]

>> '=' 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, wrcooke at 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.