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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,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/09 Message-ID: X-Deja-AN: 146540146 references: <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <4kcer3$mi4@solutions.solon.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-09T00:00:00+00:00 List-Id: Peter Seebach said "Further, that behavior is a flat out bug; it is never correct, and the portability problem lies in the program, not the language spec. The program needs to be fixed." Gosh, I was a little concerned that when I wrote my "portable programs are portable" note that it would be considered too obvious, but Peter certainly is confused, so perhaps it is worth restating. It is true of any language that a portable program is portable given: a portable program is one using only features of the language whose semantics is target independent. the implementations of the language on the machines involved are correct. But this is quite useless in the discussion of portability problems. It is indeed clear that Peter has not been involved in large porting efforts. His comments are reminiscent of an attitude that says "bugs in programs are not a problem - don't put bugs in your programs". In practice portability problems (i.e. problems in porting programs) stem from several possible sources: o Non-portable constructs introduced deliberately o Non-portable constructs introduced accidentally o Use of third party libraries etc, outside the language o Incomplete or inaccurate implementations In practice, porting large programs tends to run into problems of each variety. The language design is not exactly directly responsible in any of these areas, but it is also not completely independent of them either. Non-portable constructs introduced deliberately Some languages make it more necessary to do non-portabe programming than others, e.g. in C we cannot define integer types that have portable ranges, in Ada we can easily do so. Some languages allow extensions more freely. For example, most languages do not prohibit extensions in the standard -- the standard for COBOL for example (like most others) defines what the required feature set is and has nothing to say about programs outside the valid set. In the case of Ada, the standard requires rejection of any program NOT in the valid set. Non-portble constructs introduced accidentally This is more subjective certainly, but here too language plays a part. For example both C and Ada allow the type model to be broken, C easily with a cast, Ada only with a big syntactic stink about unchecked conversion. Another area where this occurs is when specs are vague, the discussion about read is a good example (although of course not directly relevant since read is not a language feature). An example in C is the exact semantics of X++ in a multi-threaded environment (there are obviously two possible semantics, normally the same, but not in a threaded environment). Use of third party libraries etc This can obviously be alleviated by including more such stuff in the language. Many people took the attitude that the original C language did not include I/O, but the ANSI standard clearly takes an opposite point of view and has incorporated many standard library routines. Similarly, Ada 95 differs from Ada 83 in the addition of a large standard library. Incomplete or inaccurate implementations Small, simple languages are likely to fair better here. FOr example, other things being equal, one would expect a C implementation to more easily and consistently be a full implementation of its spec than an Ada 95 or C++ implementation. Of course th "other things being equal" here is important. External factors such as the quality of validation suites, and the precision of the relevant standard, may well have a significant influence. But the bottom line here Peter is that we all know that in all languages it is possible for a very careful defensive programmer who knows the standard well, and who avoids likely trouble spots, can write portable code, especially if no system-dependent mucking is involved. But this has little to do with the practical issue of the world of portablity problems. I certainly agree that programmers who know the relevant standard are in better shape. It amazes me to find out how few C programmers have read the C standard (similar situations are true with Fortrn and COBOL). Ada interestingly is different, typical professional Ada programmers do have a copy of the Ada standard at hand, at least for reference purposes.