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: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/09 Message-ID: <4kf5mrINN47r@keats.ugrad.cs.ubc.ca>#1/1 X-Deja-AN: 146684931 references: <4kdspcINN6ct@keats.ugrad.cs.ubc.ca> organization: Computer Science, University of B.C., Vancouver, B.C., Canada newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-09T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >Kazimir has now moved on to (perfectly reasonable) discussions of >sound programming practices, with which I of course do not disagree. > >But that was not what caused me to raise the read issue in the first >place. I used it merely as an example of a portability problem caused >by an unclear specification. Seems to me that Kazimir's failure to >find anything approximating a clear spec, and talk of unwritten >rules, means he agrees wit me :-) Right. The discussion was not of programming practices, but of implementation. I think this sums it up: Seebach and Myself: in the absence of clarity in a standard, as a programmer follow the best rational inference to the safest/weakest assumption; program defensively. Then you don't have to worry about which choice is made in the implementation. 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. As a programmer, if you do the former, you don't have to particularly worry whether an implementation does the latter. For example, because I don't assume that select() will not modify the timeval structure, I don't have to care whether it does or not. The trouble is that the combined effect of the two motivations results in nothing being done to fix the standards. Good programmers are careful anyway, so they don't care, and those who are not careful are forgiven by most of the implementations, so they don't care (or don't even know) either. --