[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