Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: extern identifier length
Message-ID: <6147@ut-sally.UUCP>
Date: Tue, 28-Oct-86 13:25:16 EST
Article-I.D.: ut-sally.6147
Posted: Tue Oct 28 13:25:16 1986
Date-Received: Tue, 28-Oct-86 21:28:15 EST
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 27
Approved: jsq@sally.utexas.edu

From: harvard!encore!vaxine!nw (Neil Webber)
Date: Tue, 28 Oct 86 09:52:37 est

> From: gwyn@brl.arpa (VLD/VMB)
> Date:     Mon, 20 Oct 86 9:44:19 EDT
>
> If it doesn't support 32-character extern name uniqueness, it isn't POSIX.
> 1003.1 imposes requirements on a C implementation beyond those of X3J11.
>
While I'm 100% behind this idea, I have to ask the question "how did this
come to be?"  As I recall, the major argument against providing longer
extern names in X3J11 was that it would preclude X3J11 conforming C
implementations on systems with restricted object file formats.  Is it
now impossible to provide a POSIX conforming implementation on those
systems?

This is only a problem for implementations layered on top of an existing
OS.  Being somewhat of a "young one", I haven't worked on any systems
with a 6-character extern limit.  (Life is tough, isn't it?) However, I'd
be interested in knowing what systems suffer from this restriction, and
why it doesn't matter that a POSIX environment can't be provided under
those systems.

Neil Webber     Automatix Inc.          Billerica MA
        {decvax,ihnp4,allegra}!encore!vaxine!nw

Volume-Number: Volume 8, Number 3