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

[Stephen Hoffman]

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.

/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.




-- 
Pure Personal Opinion | HoffmanLabs LLC