Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.lang.c Subject: Re: 'C' Standards Message-ID: <6422@brl-smoke.ARPA> Date: Sat, 12-Sep-87 16:17:21 EDT Article-I.D.: brl-smok.6422 Posted: Sat Sep 12 16:17:21 1987 Date-Received: Sun, 13-Sep-87 08:39:44 EDT References: <166@qetzal.UUCP> <157@hobbes.UUCP> <875@bsu-cs.UUCP> <2196@xanth.UUCP> <181@sas.UUCP> <1141@laidbak.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 18 In article <1141@laidbak.UUCP> guardian@laidbak.UUCP writes: >If you want to set a standard, how about just saying what will work under >certain conditions and under different versions of an OS. That information might be useful for some purposes, but it cannot replace true standards. The essential problem requiring standards is that software developers cannot really afford to take into account the uncontrolled vagaries of all past, present, and future operating systems. Even just keeping abreast of them is beyond most organizations' budgets. The practical advantage of standards is that applications can be developed to use a known set of facilities with known properties, and they will then work across a wide variety of systems with negligible porting effort. If the standard environment is sufficiently rich, such applications can even be useful (unlike many that assume only the lowest common denominator environment). Of course, for this to work, there must be agreement on what the standards ARE, and they must be readily implementable across all those systems.