|[14 earlier articles]|
|Re: A lesson for compiler warning writers firstname.lastname@example.org (1992-06-21)|
|Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-22)|
|Re: A lesson for compiler warning writers email@example.com (1992-06-22)|
|Re: A lesson for compiler warning writers firstname.lastname@example.org (1992-06-22)|
|Re: A lesson for compiler warning writers email@example.com (1992-06-23)|
|Re: A lesson for compiler warning writers firstname.lastname@example.org (Ronald Bodkin) (1992-06-23)|
|Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-23)|
|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|
|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.
Return to the
Search the comp.compilers archives again.