Related articles |
---|
[14 earlier articles] |
Re: A lesson for compiler warning writers preston@dawn.cs.rice.edu (1992-06-21) |
Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-22) |
Re: A lesson for compiler warning writers prener@watson.ibm.com (1992-06-22) |
Re: A lesson for compiler warning writers derek@knosof.uucp (1992-06-22) |
Re: A lesson for compiler warning writers kendall@centerline.com (1992-06-23) |
Re: A lesson for compiler warning writers rjbodkin@theory.lcs.mit.edu (Ronald Bodkin) (1992-06-23) |
Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-23) |
Newsgroups: | comp.compilers |
From: | mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum) |
Keywords: | C, interpreter, lint |
Organization: | Digital Equipment Corporation, Washington ULTRIX Resource Center |
References: | <19920609091040SEB1525@MVS.draper.com> 92-06-113 |
Date: | Tue, 23 Jun 1992 13:42:55 GMT |
>Of course there are small language differences no matter what you do, but
>either of these approaches has proven practical many times.
As long as they are fairly reasonable, I find this acceptable. Yet
another advantage of developing one's code in an interpreted environment
prior to compiling it is that it is effectively a miniature "port" of the
code - it'll help weed out questionable stuff.
I'm too cynical about "standards" - there are always differences
that creep in. Let's accept that and tailor our development methodologies
to incorporate an awareness of this. If C is "standard" but not everyone's
implementation of "standard C" supports some funky ANSI-ism, then only a
fool will rely on it in code. Yeah, I realize that it's the fault of the
compiler writer for not supporting the feature - but assigning fault
doesn't make the code work so it's a moot point.
mjr.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.