Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.sources.d
Subject: Re: Standard C Programming - wot a dumb idea.
Message-ID: <6324@brl-smoke.ARPA>
Date: Sat, 22-Aug-87 15:06:04 EDT
Article-I.D.: brl-smok.6324
Posted: Sat Aug 22 15:06:04 1987
Date-Received: Sun, 23-Aug-87 13:11:10 EDT
References: <1101@laidbak.UUCP> <656@hplabsz.HPL.HP.COM> <1113@laidbak.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22
Keywords: standard c flame

In article <1113@laidbak.UUCP> guardian@laidbak.UUCP writes:
>But there are those who would like to see some standard
>that a shared community can work with.

We're working hard to establish such standards (ANSI X3.159-198x
for C and IEEE 1003.1 for UNIX-like system interface).  However,
they're not quite ready and won't be widely enough implemented
for a couple of years.  It is premature to attempt to dictate C
source standards for "navie user installed" products.  It is
absolutely misguided to demand that C programmers hobble
themselves by not exploiting many of the language's most useful
features, on the grounds that people who don't understand C
would not understand the code.  Why SHOULD such people be
expected to understand the code?  There might be some point to
that for code that is intended to be tutorial, but that's not
what the vast majority of freeware is intended for.

There are some things that programmers CAN do now to improve
source code portability.  For example, I'm working up a list of
library routines and headers that are relatively safe to rely
on, to guide programmers working on a large local project; I'll
post it to comp.lang.c and comp.unix.questions when it's done.