Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn) Newsgroups: net.lang.c Subject: Re: ANSI C: CPP predefined constants vs. Message-ID: <5401@brl-tgr.ARPA> Date: Fri, 19-Oct-84 18:31:56 EDT Article-I.D.: brl-tgr.5401 Posted: Fri Oct 19 18:31:56 1984 Date-Received: Sat, 20-Oct-84 07:20:42 EDT References: <420@diku.UUCP> Organization: Ballistic Research Lab Lines: 29 I don't see how conditional tests for different run-time environments is going to solve the problem, since there will always be some unanticipated environments and in any case few programmers are going to prearrange code to accommodate all known systems; that's a lot of extra work! The cleanest approach seems to me to establish a common environment for portable programs. The /usr/group C environment standard was supposed to be one such common environment. Unfortunately they added things like the locking call that can't be reasonably provided on all systems and omitted things like tty ioctls that are needed by many applications. The policy in my Division is to target applications for a UNIX System V environment (minus unique features like real-time IPC) unless it can be demonstrated that a specific application depends on "native OS" features in a way that cannot be accessed in the (emulated) UNIX System V environment. On foreign systems, someone has to implement the common environment just once, then the applications come up with practically no trouble. This is much easier for the application developer than trying to accommodate a variety of different environments directly in his code. So far I have implementations for: UNIX System V (trivial, just directory access routines) VAX 4.2BSD Gould UTX-32 (preliminary version) JHU/BRL PDP-11 UNIX and am working on one for the Apple ][ (Aztec C under ProDOS).