Xref: utzoo comp.sys.next:4800 gnu.gcc:1284
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!groucho!davis
From: davis@groucho.ucar.edu (Glenn P. Davis)
Newsgroups: comp.sys.next,gnu.gcc
Subject: Re: C compilers for NEXT
Keywords: C, compiler, NEXT
Message-ID: <6108@ncar.ucar.edu>
Date: 25 Jan 90 00:00:10 GMT
References: <642@cscnj.csc.COM> <25BCC24E.10018@paris.ics.uci.edu>
Sender: news@ncar.ucar.edu
Reply-To: davis@groucho.UCAR.EDU (Glenn P. Davis)
Organization: Unidata/UCAR, Boulder CO
Lines: 24

In article <25BCC24E.10018@paris.ics.uci.edu> rfg@ics.uci.edu (Ron Guilmette) writes:
>
>The directive is called "#import" and according to reports I have recieved,
>this directive is being used within (at least some of) NeXT's "system"
>include files (perhaps many of them).  You know... the files that you
>often have to include in typical C programs like <sys/file.h>, etc.
> 
.... more bashing of the #import directive.

A perusal of the documentation will put the blame where it belongs.

The #import directive is inherited from Mach, specifically documented in
the section where the format of remote procedure call specification files
is discussed.

Personally, I don't fault NeXT for using this mechanism.  Its does solve a
problem and has the historical precedent in Mach.  It works in the
context of their system. After all, code like

	[object message:arg] ;

Won't work with gcc on other systems either.

-glenn