[Info-vax] C... the only winning move is not to play...

[Paul Sture]

On 2014-02-11, JohnF <john at please.see.sig.for.email.com> wrote:
> Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>
>> If the code is security-relevent, I'd definitely crank up the
>> diagnostics <http://labs.hoffmanlabs.com/node/912>, and I'd also
>> explicitly locate and deprecate some of the older C calls
>> <http://labs.hoffmanlabs.com/node/1317>
>>
>> If the applications are still flaky, then identifying and targetting a
>> few high-error-profile modules or routines within the code for rework
>> or rewrite.
>
> I haven't found any general-purpose technique for successfully
> dealing with flaky code.

Once you get into the nitty gritty of an old project the module's author
name becomes a good guide :-)

> In a preceding post, I mentioned a guy using rms where he could have just
> used fprintf. In the same program he had a func that did use fopen/fgets
> on files with data to be read. This was for a financial app that
> occcasionally had to process "special issues" not following the regular
> rules. But he forgot to fclose these files before returning. And the vms
> account under which it was running had a files open limit of 50. So if a
> portfolio being valued had more than 50 "special issues", all subsequent
> fopen's failed, and the func just quietly returned a 0.0 value without
> asserting any kind of error.

That could be an example of Cargo Cult Programming:

<http://www.catb.org/~esr/jargon/html/C/cargo-cult-programming.html>
<https://en.wikipedia.org/wiki/Cargo_cult_programming>

One of the problems rectifying such programming is that folks tend to
get wrapped up in the details of "the FABs and the RABs"* rather than
taking a step back and doing what you suggest: replacing the lot with
simple open/read/write/close statements using the HLL constructs available.

* aka talking bits and bytes rather than concentrating on the business
requirement

>   I never found this... until the port to unix was complete.
> Then, during parallel testing,... well, you know the end of that
> story. But the point is, how the heck could I have ever noticed
> that bug just reading through the several hundred thousand lines
> of code comprising the entire app??? It was easy enough to spot
> once the parallel testing clued me in to what needed some careful
> looking at. But pretty much impossible to just stumble upon
> otherwise.

But once you've found that one example, a quick search through the
entire codebase for similar pieces of code becomes feasible.
Checking to see if that author (or whoever he/she copied from) has
made that mistake in other modules might be sensible too.



--
Paul Sture