Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!dogie.macc.wisc.edu!indri!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: setjmp/longjmp
Message-ID: <10189@smoke.BRL.MIL>
Date: 2 May 89 05:32:12 GMT
References: <1447@cunixc.cc.columbia.edu> <1989Apr27.165319.23986@utzoo.uucp> <17179@mimsy.UUCP> <1989Apr29.232632.23997@utzoo.uucp> <10203@socslgw.csl.sony.JUNET>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 16

In article <10203@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes:
>Perhaps the marketplace should be encouraged to support this pseudo-standard.
>If customers refuse to buy compilers with misfeatures, even if the compilers
>are compliant, correct results can be obtained.

Please get with the program.  The main reason a C standard was developed
was precisely because of this kind of "every vendor decide for himself"
approach to implementing C, which made portable programming excessively
difficult.  The are sound reasons for virtually every specification in
the forthcoming C standard, and most "why" questions are addressed by the
accompanying Rationale document.  Even if an implementer personally
disagrees with the rationale (and nearly everybody will probably find
some particular point he thinks should have been specified differently),
so long as the specification is unambiguous you do your customers no
favor by deviating from it.  You will probably also lose sales when your
compiler fails standard conformance tests.