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.lang.c
Subject: Re: MAJOR ANSI C FLAW (my opinion, of course)
Message-ID: <6564@brl-smoke.ARPA>
Date: Wed, 14-Oct-87 09:44:53 EDT
Article-I.D.: brl-smok.6564
Posted: Wed Oct 14 09:44:53 1987
Date-Received: Fri, 16-Oct-87 00:27:15 EDT
References: <1132@gilsys.UUCP> <1246@bsu-cs.UUCP> <6543@brl-smoke.ARPA> <104@aimt.UUCP> <407@ruby.TEK.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <407@ruby.TEK.COM> rjg@ruby.UUCP (Rich Greco) writes:
>This heritage is continued with the C binding.  All functions in the C
>binding of GKS will have six character names.

This is either
	(a) necessary, because you expect there to be a GKS binding in
	    an environment that really cannot support longer external
	    identifiers;
or
	(b) unnecessary, because you don't want to worry about such
	    environments for GKS.

In the former case, all the wishing in the world is not going to help.

In the latter case, the GKS binding standard could require 31-character
case-sensitive external name uniqueness, if the people drawing up the
GKS binding standard felt like doing so.  This would be a requirement
above and beyond those specified for ANSI C, and it would not conflict
with the requirements for ANSI C.  This sort of thing has been done for
the POSIX (IEEE 1003.1) standard, which adds semantics to some of the
ANSI C-defined library functions.  You just have to be careful not to
require something which breaks conformance to the spec; longer extern
significance does not.