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

[Bill Gunshannon]

In article <ldcqni$bm9$1 at reader1.panix.com>,
	JohnF <john at please.see.sig.for.email.com> writes:
> 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.

Yeah, like people who turn off Warnings rather than fixing the things they
Warn about.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>