[Info-vax] C... the only winning move is not to play...
JohnF
john at please.see.sig.for.email.com
Tue Feb 11 04:32:34 EST 2014
Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> On 2014-02-10 15:12:29 +0000, JohnF said:
>
>> ...There are later standards, e.g., cc/standard=ansi89, but for
>> maintaining old code it's probably easier/safer to just stick with that
>> unless you can't for one reason or another.
>
> I'm somewhat ambivalent about the C diagnostics.
>
> Certainly if the old C code is working and stable or if the customer is
> willing to accept the existing instability and those funky code-smells,
> then definitely stay with however the C code was built.
>
> One potential reason for changing the standards compliance (well within
> that "for one reason or another" mention): If the old code is acting
> like much of the old C code that folks get called in to look at and is
> somewhat flaky and with weird or transient or hard-to-debug errors,
> then enabling the newer diagnostics can uncover latent errors.
>
> I've had good success stabilizing old C code with just getting the
> compiler diagnostics to pass. That can find the triggers for of all
> sorts of flaky bugs and weird crashes.
>
> Old K&R C code can be particularly flaky, in my experience.
Well, flakiness is an attribute of the code/programmer-who-wrote-it
rather than the standard. Well-written code won't be flaky, regardless
of what standards it conforms to. Of course, that's just axiomatically
true by the very definition of "well-written". If the old code you've
looked at is more flaky than later code, that just reflects badly
on the staff at that earlier time.
> /STANDARD=C89? If up-armoring the source code is on the menu, then go
> /STANDARD=LATEST or /STANDARD=C99 if you can, and preferably with
> /ENABLE=WARN QUESTCODE enabled.
>
> 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. 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.
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.
--
John Forkosh ( mailto: j at f.com where j=john and f=forkosh )
More information about the Info-vax
mailing list