From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/10 Message-ID: #1/1 X-Deja-AN: 146721569 references: <4kdspcINN6ct@keats.ugrad.cs.ubc.ca> <4kf5mrINN47r@keats.ugrad.cs.ubc.ca> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-10T00:00:00+00:00 List-Id: Kazimir says "Dewar: in the absence of clarity in a standard, as an implementor, follow the pack. Look at what most implementations do, and stick to the unwritten standards of the community." That of course completely misunderstands my position and Kazimir's failure to undertand the central issue here is a great illustration of my central point. In fact I could not have asked for anyone to make the point more clearly. I brought up this thread not as a discussion of proper programming practices, but of the importance of specs, and to give an example of portability problems caused by inaccurate specs. Kazimir's view is "so what if the specs are vague, never mind, if people are "rational" or follow "unwritten rules", then it probably won't matter much. The trouble is that it absolutely *does* matter, and it matters much! If programmers continue to follow Kazimir's casual attitude towards specs, then we continue to get libraries, and, as we see in the case of POSIX, even standards, that are unacceptably vague. I am not asking for formal specifications, although with library routines like this it would not be too hard, and would definitely be useful, but I think people need to have more formal training in semantics, so that they understand the critical issue of clear specifications. The bravado attitude of Kazimir and Peter -- "people shouldn't make errors, if they do they get what they deserve", or "people should think clearly, real programmers don't need specs [to be fair that is Kazimir and not Peter]" is actually often more of a menace than incompetence. I have often seen big programs get into horrible trouble because a really clever programmer thought that rigorous engineering could be replaced by programming brilliance. As I have said many times, the details of the read issue are not that important. It is simply a case where different implementatoins have subtly different specs, and consquently a program that is semantically correct in one implmentation is wrong in another. The only cure to this problem is clear specification at an abstract, implementation-independent level. People who think that they can overcome the lack of such clear abstract specifications by guessing what is rational or reasonable are fooling themselves badly.