Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.lang.c Subject: Re: What real non-UNIX 'C' compilers implement... Message-ID: <6504@brl-smoke.ARPA> Date: Sat, 3-Oct-87 19:49:46 EDT Article-I.D.: brl-smok.6504 Posted: Sat Oct 3 19:49:46 1987 Date-Received: Sun, 4-Oct-87 07:04:53 EDT References: <721@sugar.UUCP> <814@sugar.UUCP> <29156@sun.uucp> <1059@moscom.UUCP> <3701@venera.isi.edu> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 32 In article <3701@venera.isi.edu> lmiller@venera.isi.edu.UUCP (Larry Miller) writes: >It is VERY important, for purposes of portability, to make the section 2/ >section 3 distinction. That is, C STANDARD library routines, and system >calls. Why? Because most programmers, particuarly when faced with >something like Turbo C's alphabetical listing of all functions, don't >really know the difference. Then try porting DOS calls to UNIX. > >Further, standard library routines are supposed to perform in a documented >way, conforming to the standard. System routines need not. Consequently, >from a formal verification standpoint, programs are likely to be safer, >more robust. And knowing the distinction allows you to package the stuff >that has to be system-dependent in a way that aids portability. I have to disagree with the way you've packaged "standard" and "system" routines. Rather than bandy about the term "standard", you should refer to the standard document you use as an interface reference. At the moment, it must be mostly K&R, which unfortunately does not specify very many library routines. In the not-too-distant future, the most useful reference spec will be the ANSI standard for C, X3.159-198x. It would indeed be wise to keep separate those library routines that are assumed to be "universally" available from those that are definitely specific to a particular system, using the former whenever possible in code intended to be portable and confining use of the latter to small, isolated system interface modules with well-defined portable interfaces. I'm in the process of preparing a list of standard library functions that can be counted on in a majority of current environments, in sections corresponding to ANSI C, POSIX, and SVID (each assuming the previous ones as a subset). This is not perfect, but it is a useful guide for those programmers who really aren't sure how universally available various routines are. I'll post the list here "soon".