On Tue, 2022-03-29 at 15:10 -0700, Charles Mills wrote:
> Well, while we are digressing ...
>
> There was discussion earlier of the use of the equal sign for assignment
> versus comparison.
>
> I am going to guess that THE most common cause of C/C++ program errors is the
> mis-use of = for comparison. (The comparison operator in C and C++ is ==.) In
> C if you code
>
> if (foo = 3) bar = 5;
>
> Then the compiler generates code to assign 3 to foo, test the result (3) for
> truth (not 0) and then execute the conditional statement. The above has the
> same effect as
Almost all modern C/C++ compilers will flag that as a warning. And there are
options to promote warnings to errors. For example:
❯ clang -Werror -o a a.c
a.c:6:11: error: using the result of an assignment as a condition without
parentheses [-Werror,-Wparentheses]
if (a = 2) puts("bugger");
~~^~~
a.c:6:11: note: place parentheses around the assignment to silence this warning
if (a = 2) puts("bugger");
^
( )
a.c:6:11: note: use '==' to turn this assignment into an equality comparison
if (a = 2) puts("bugger");
^
==
1 error generated.
I use the CLion IDE which uses clang-tidy to check for errors while I type.
Most editors such as Vim, VS Code etc support clang integration including
Visual Studio.
>
> foo = 3;
> bar = 5;
>
> If I am recalling the story correctly, a malicious programmer *almost*
> succeeded in inserting code into the Linux kernel of the form
>
> if (uid = 0) ...
>
> The code appears to be testing the uid for 0, but in reality is making the
> uid 0. Someone who know how to get to the code path could make themselves
> into superuser.
>
> I like := for assignment, but I believe C eliminated the ambiguity of = by
> choosing == for comparison, by analogy to all of the other 2-character
> comparison operators (>=, !=, etc.).=
>
> Charles
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Bernd Oppolzer
> Sent: Tuesday, March 29, 2022 1:57 PM
> To: [email protected]
> Subject: Re: PL/I question
>
> As it seems from other posts, the story is not completely true;
> there was indeed such an error somewhere sometime with NASA,
> but the error that destroyed the Mariner spacecraft was different (a
> missing hyphen on
> a hand-written variable specification, which had not been translated
> correctly to computer code).
>
> I believe that there are similar pitfalls in other languages, too,
> although FORTRAN is very special,
> because it allows spaces even in the middle of identifiers (and
> numbers), such as
>
> DO 3 I = 1 . 10
>
> which in every other programming language would disqualify as an
> assignment statement
> because of the spaces around the DO symbol.
>
> My favorite PL/1 example from a real world program is this:
>
> IF 9 < ZZ < 20 THEN DO; ...
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
