[SystemSafety] OpenSSL Bug
Steve Tockey
Steve.Tockey at construx.com
Wed Apr 16 12:17:41 CEST 2014
I'm not arguing for or against C, but I have seen coding standards that
prohibit:
if ((a = check()) == SUCCESS) { ... }
They require instead:
if ( SUCCESS == (a = check()) ) { ... }
Simply moving the constant to the left side makes it an ill-formed
expression if the "==" is accidentally switched for "=":
if ( SUCCESS = (a = check()) ) { ... }
-- steve
-----Original Message-----
From: David MENTRE <dmentre at linux-france.org>
Date: Wednesday, April 16, 2014 3:10 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] OpenSSL Bug
Hello,
Le 14/04/2014 23:59, Derek M Jones a écrit :
>> Suppose technical methods T are known to avoid, definitively, mistakes
>> of type X,
>
> more empirical evidence,
No. As Peter said, the method T *definitely* avoids the mistake, by
construction.
To take just one example, consider the "=" vs. "==" issue in C's if
construct (e.g. "if ((a = check()) == SUCCESS) { ... }").
In C++, Ada and other languages, "if" construct only takes a Boolean as
first test parameter (contrary to C that takes arbitrary expression), so
an error like "if ((a = check()) = SUCCESS) { ... }" is systematically
caught by the compiler with a type error if type of "a" is not boolean.
In C, you could use a home defined bool type and have a static checker
checks that the use of this bool type is properly made according to some
typing rules.
>> and T are practical.
>
> and yet more empirical evidence,
No. In my previous example, the proposed approach is demonstratively
practical because you can write *exactly* the same expressions as before
(e.g. "if ((a = check()) == SUCCESS) { ... }"). The additional typing
adds no additional burden on the programmer.
Sincerely yours,
david
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
More information about the systemsafety
mailing list