This commit was manufactured by cvs2svn to create tag 'ACE-4_4_34'.ACE-4_4_34

10 files changed, 0 insertions, 2711 deletions

diff --git a/TAO/TAO_IDL/docs/ANNOUNCEMENT b/TAO/TAO_IDL/docs/ANNOUNCEMENT
deleted file mode 100644
index 870db6f6006..00000000000
--- a/TAO/TAO_IDL/docs/ANNOUNCEMENT
+++ /dev/null
@@ -1,131 +0,0 @@
-WHAT:
-
-SunSoft, Inc., Mountain View, California, has placed the source code to
-Project DOE's Interface Definition Language (IDL) compiler front end
-(CFE) on OMG's file server, making the implementation publicly
-available. This release is identified by the version number 1.3.
-
-Project DOE is SunSoft's corporate-wide development effort to integrate
-distributed object technology into the Solaris O/S.  OMG (Object Management
-Group) is the industry wide body formed to create specifications for
-distributed object technology. It currently has more than 370 members. OMG
-IDL is part of OMG's CORBA 1.1 specification and provides a standardized
-way for defining object interfaces. OMG IDL forms the basis for distributed
-object interactionin Project DOE.
-
-The SunSoft OMG IDL CFE provides a complete framework for building
-CORBA 1.1-compliant preprocessors for OMG IDL.  By using this standard
-implementation, developers of OMG IDL compilers will save many months
-of work and enhance the portability and interoperability of OMG
-IDL-interfaced objects.
-
-The SunSoft OMG IDL CFE allows convenient and fast integration of new back
-ends to the compiler.  The release consists of a front end which converts
-OMG IDL to an intermediate format, a compiler framework driver, an example
-implementation of a compiler back end, and a set of protocols for
-interaction between the front and back ends.  The SunSoft OMG IDL CFE
-parser uses components generated by yacc and lex.
-
-The SunSoft OMG IDL CFE is designed to allow easy extension of OMG IDL
-without impacting existing back-end implementations.  As the CORBA
-specification evolves, any new updates to the IDE CFE will be placed
-by SunSoft on the OMG server.
-
-This release provides a directory with many examples of OMG IDL
-specifications to allow users to become familiar with the process of
-writing OMG IDL code.
-
-For more information send email to idl-cfe@sun.com.
-
-HOW:
-
-The SunSoft OMG IDL CFE is available at no charge through anonymous FTP
-in source form on the OMG file server, omg.org. Please retrieve the
-file OMG_IDL_CFE_1.3.tar.Z from the directory pub/OMG_IDL_CFE_1.3. Please
-let us know who you are if you retrieve the compiler front end using this
-method, by sending email to idl-cfe@sun.com.
-
-You can also retrieve the software by using the OMG mail server program.
-Send email with the subject 'help' to omg_idl@omg.org, and the mail server
-will respond with instructions on how to retrieve the software.
-
-WHEN:
-
-The SunSoft OMG IDL CFE is available now.
-
-CONTACT:
-
-Please let us know who you are if you decide to use this software, and how
-you use it. Please send email to:
-
-     idl-cfe@sun.com
-
-This address can also be used to report problems, bugs, suggestions and
-send general comments.
-
-We ask that if you make extensions or modifications to this source release,
-please make these extensions available to others using the OMG IDL compiler
-front end, by sending the modified sources to the above email address. This
-will help us evaluate your extensions for inclusion in a future version. It
-also ensures your investment in these extensions when new versions of the
-CFE are released.
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
-
-COPYRIGHT NOTICE:
-
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043
diff --git a/TAO/TAO_IDL/docs/BUG_REPORT b/TAO/TAO_IDL/docs/BUG_REPORT
deleted file mode 100644
index 28c34ae141d..00000000000
--- a/TAO/TAO_IDL/docs/BUG_REPORT
+++ /dev/null
@@ -1,144 +0,0 @@
-OMG IDL COMPILER FRONT END PROBLEM REPORT FORM
--============================================-
-
-Checklist: Did you:
-- include configuration information?
-- include compiler version number (use -V to obtain)?
-- include script of run?
-- include IDL file causing problem?
-- make any changes to the CFE? If so, did you include a diff against
-  original version?
-
-PLEASE SEND THE COMPLETED BUG REPORT TO: idl-cfe@sun.com.
-
-THANK YOU FOR REPORTING THIS PROBLEM! THROUGH YOUR COLLABORATION, SUNSOFT
-WILL BE ABLE TO IMPROVE THE FUNCTIONALITY OF THIS PRODUCT. RECEIPT OF BUG
-REPORTS WILL BE ACKNOWLEDGED BUT NO OBLIGATION IS UNDERTAKEN BY SUNSOFT TO
-CORRECT THE REPORTED PROBLEM. SEE YOUR COPYRIGHT AND LICENSE INFORMATION.
-
-
-CONFIGURATION INFORMATION (describe your hardware platform, operating
-system and which compilers you used to compile the CFE):
-
-
-
-
-
-
-COMPILER VERSION INFORMATION (include output from idl -V here):
-
-
-
-
-
-
-
-PROBLEM DESCRIPTION (describe problem, include script if available):
-
-
-
-
-
-
-
-
-IDL INPUT CAUSING PROBLEM (include IDL input causing problem):
-
-
-
-
-
-
-
-
-
-DID YOU MAKE ANY CHANGES TO THE CFE? [Y] _ [N] _
-IF YES, INCLUDE A DIF OF YOUR VERSION AGAINST ORIGINAL VERSION:
-
-
-
-
-
-
-
-
-
-PROPOSED FIX (if you believe you know the cause of the problem, please
-include a proposed change to the software to correct it):
-
-
-
-
-
-
-
-
-ANY OTHER RELEVANT INPUT (include here any other information you believe
-may be relevant to the resolution of the problem you described):
-
-
-
-
-
-
-PLEASE SEND THIS PROBLEM REPORT TO idl-cfe@sun.com.
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
-
-COPYRIGHT NOTICE:
-
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043
diff --git a/TAO/TAO_IDL/docs/CHANGES b/TAO/TAO_IDL/docs/CHANGES
deleted file mode 100644
index ae6fca7bcea..00000000000
--- a/TAO/TAO_IDL/docs/CHANGES
+++ /dev/null
@@ -1,122 +0,0 @@
-CHANGES WHICH AFFECT BE WRITERS
--=============================-
-
-INTRODUCTION
-
-This file describes changes that affect BE writers. It contains IMPORTANT
-INFORMATION for BE writers who wish to migrate a BE written to operate with
-release 1.2 to operate with release 1.3. It is likely that not following
-these instructions will result in a compilable but malfunctioning compiler.
-
-AST INHERITANCE CHANGES
-
-The AST has been reorganized so that AST_Union and AST_Exception now
-inherit from AST_Structure. This means that constructors of BE classes
-which inherit from AST_Union or AST_Exception now need to explicitly call
-an initializer for AST_Structure in their init section.
-
-We repeat below the information given in the file WRITING_A_BE, in the
-section entitled "WRITING A BE".
-
-AST_EXCEPTION
-
-The signature for constructors of classes inheriting from AST_Exception
-should now be:
-
-	BE_Exception::BE_Exception(UTL_ScopedName *n,
-				   UTL_StrList *p)
-		    : AST_Decl(AST_Decl::NT_except, n, p),
-		      AST_Structure(AST_Decl::NT_except, n, p),
-		      UTL_Scope(AST_Decl::NT_except)
-
-AST_UNION
-
-The signature for constructors of classes inheriting from AST_Union should
-now be:
-
-	BE_Union::BE_Union(AST_ConcreteType *dt,
-			   UTL_ScopedName *n,
-			   UTL_StrList *p)
-		: AST_Union(dt, n, p),
-		  AST_Structure(AST_Decl::NT_union, n, p),
-		  AST_Decl(AST_Decl::NT_union, n, p),
-		  UTL_Scope(AST_Decl::NT_union)
-
-IDL_BOOL TYPE
-
-To increase portability and reduce dependency of the sources on POSIX
-compliance in targets of ports, IDL now provides its own boolean type which
-is named idl_bool. It provides two truth values, I_TRUE and I_FALSE.
-
-UTL_SCOPEDNAME TYPE
-
-The UTL_ScopedName type is now a list of Identifier nodes; in previous
-releases it used to be a list of String nodes. If your BE constructs scoped
-names this change will prevent recompilation until you modify your
-constructor calls to invoke constructors for Identifier instead of for
-String. The signature of the constructor is:
-
-	Identifier::Identifier(char *, long x=1, long y=0, long z=I_FALSE)
-
-The additional arguments which can be defaulted to the values indicated are
-included for future use.
-
-COPYRIGHT
-
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
diff --git a/TAO/TAO_IDL/docs/CLI b/TAO/TAO_IDL/docs/CLI
deleted file mode 100644
index a61c2bae365..00000000000
--- a/TAO/TAO_IDL/docs/CLI
+++ /dev/null
@@ -1,187 +0,0 @@
-OMG INTERFACE DEFINITION LANGUAGE COMPILER FRONT END: COMMAND LINE INTERFACE
--==========================================================================-
-
-INTRODUCTION
-
-This document describes general OMG Interface Definition Language compiler
-command line options. Options that are specific to a given back end, object
-adapter or language are not described here. These should be described in a
-document detailing the interface implemented by each specific back end.
-
-OMG INTERFACE DEFINITION LANGUAGE COMMAND LINE OPTIONS
-
-OMG Interface Definition Language compiler options are described below.
-Unless otherwise noted, only one occurrence of each option is allowed.
-The following conventions are used
-
-- Text in '[..]' is optional.
-- Text followed by '*' can be repeated zero or more times.
-- Text followed by '+' can be repeated once or more times.
-- '{' and '}' are used to group text to cause '+' or '*' to apply to
-  the entire grouped text.
-- 'aa|bb' means either 'aa' or 'bb'.
-
-COMMAND LINE SUMMARY
-
-	idl [flag | file-name]*
-
-Flags are command line words that start with a '-'. All other command line
-words are assumed to be file names. If no file names are given, input is
-taken from stdin.
-
-COMMAND LINE FLAGS
-
--A[xyz]	A local escape. This can be used to specify additional options that
-	are specific to a given implementation. More than one -A option is
-	allowed
-
--Dname[=value]
-	Defines name and an optional value to be passed to a compliant C++
-	preprocessor, as if by #define. White space between the -D option
-	and the name is optional. More than one -D option is allowed.
-
--d	If no parse errors were found, prints out a representation of the
-	IDL input to stderr.
-
--E	Runs the C++ preprocessor on the OMG Interface Definition Language
-	input and sends the result to the standard output.
-
--Idirectory
-	Causes directory to be added to the search path for include files.
-	More than one -I option is allowed. This option is processed by a
-	compliant C++ preprocessor.
-
--Uname	Undefines name, as if by #undef. White space between the -U option
-	and the name is optional. More than one -U option is allowed.
-
--V	Causes the version information of the CFE to be displayed. No other
-	work is done, regardless of any other options.
-
--W[b|p][,arg]+
-	Hands off the arguments supplied to a specific portion of the OMG
-	Interface Definition Language compiler:
-
-	- -Wb arguments are handed to the loaded back end
-	- -Wp arguments are handed to a compliant C++ preprocessor
-
--Yp,pathname
-	Specifies an alternate path for finding a C++ compliant
-	preprocessor. Specifiers other than 'p' may be defined in future
-	versions of the CFE. More than one -Y option may appear. The last
-	one specifying each component takes effect.
-
-	This option exists but currently does nothing. Instead, we use the
-	preprocessing facilities provided by invoking CC -E always.
-
--bback_end
-	Causes the CFE to use a different compiler back end than the
-	default one (if dynamic loading is supported). Legal values for
-	this option and the default value are implementation specific.
-
--u	Prints a usage message from the CFE. All possible options are
-	shown. No other work is done regardless of any other options.
-
--v	Causes the CFE to produce informational output as the various
-	phases of the compiler execute.
-
--w	Suppresses IDL compiler warning messages.
-
-
-WHITESPACE
-
-All option arguments may be separated from their option letter by
-whitespace. For example, -D FOO is equivalent to -DFOO.
-
-UNKNOWN OPTIONS
-
-If an unknown option is passed to the CFE, the offending option is
-displayed to the user together with a usage message, and no compilation is
-performed.
-
-PASSING OPTIONS TO COMPILER PHASES
-
-The order in which options appear on the command line is preserved when
-they are passed to various compiler phases.
-
-MUTUALLY EXCLUSIVE OPTION COMBINATIONS
-
-Mutually exclusive or ambiguous option combinations are resolved by using
-the option that appears later on the command line. For example,
-
-    -DFOO -UFOO
-
-has no effect and leaves FOO undefined for the preprocessor.
-
-OPTION SCOPE
-
-All options are in effect for the entire IDL compilation run. If multiple
-IDL source file names are given on the command line, all options apply to
-each file. If different IDL source files require different sets of options
-for successfull compilation, they must be compiled separately.
-
-EXIT STATUS
-
-IDL Compilers exit with status equal to zero for successfull compilations.
-If errors were found by the CFE, the exit status is a count of the errors.
-The exit status for unsuccessfull compilations aborted by BEs is defined by
-each BE.
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
-
-COPYRIGHT NOTICE:
-
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043
diff --git a/TAO/TAO_IDL/docs/COPYRIGHT b/TAO/TAO_IDL/docs/COPYRIGHT
deleted file mode 100644
index 461ad949518..00000000000
--- a/TAO/TAO_IDL/docs/COPYRIGHT
+++ /dev/null
@@ -1,57 +0,0 @@
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
diff --git a/TAO/TAO_IDL/docs/INSTALL b/TAO/TAO_IDL/docs/INSTALL
deleted file mode 100644
index 6fcaa710042..00000000000
--- a/TAO/TAO_IDL/docs/INSTALL
+++ /dev/null
@@ -1,229 +0,0 @@
-INTERFACE DEFINITION LANGUAGE INSTALLATION GUIDE
--==============================================-
-
-INTRODUCTION
-
-This file describes the installation process for OMG_IDL_CFE version 1.3.
-This file explains how to:
-
-- install the source code
-- modify the sources to customize them for different configurations
-- modify the sources to implement your own back end
-
-TESTED CONFIGURATIONS
-
-This release has been tested and is believed to operate correctly on:
-- SunPro Sparcworks 2.x and 3.0 on SunOS 4.1.x
-- SunPro Sparcworks 2.x and 3.0 on Solaris 2.3
-- g++ 2.5.8 on SunOS 4.1.x
-- g++ 2.5.8 on Solaris 2.3
-
-This is the first release of OMG IDL CFE which is preconfigured to compile
-correctly for Solaris 2.x and with SunPro SparcWorks compilers.
-
-CUSTOMIZATION
-
-The release contains a file idl_make_vars in the current directory, which
-is included in each Makefile. This file defines all the customizable
-variables for the CFE.
-
-OSV should be set to a string denoting the operating system upon which you
-wish to build the CFE. The CFE as shipped is preconfigured to compile
-correctly on Solaris 2.x (OSV=SOLARIS2), and has also been tested on SunOS
-4.1.x (OSV=SUNOS4). It contains code donated by HP which enables it to be
-compiled on Apollo Domain systems (OSV=apollo) and HPUX systems (OSV=hpux),
-but these two configurations have not been tested.
-
-C++ and CCC should be set to identify the C++ compiler you will use to
-compile this release. Their values should be identical. Both are set to
-address differences between various make programs - some predefine CCC,
-others use C++ to denote the C++ compiler. The possible values are CC
-(which uses the Sparcworks compilers on SunOS 4.1 and Solaris 2.3) and g++,
-which uses the installed version of GNU C++.
-
-CCFLAGS should be set to a list of flags to pass to the C++ compiler. As
-shipped, this list is -g. NOTE: We have not extensively tested the release
-with optimization turned on.
-
-CPP_FLAGS should be set to a list of flags to pass to the C++ preprocessor.
-Use this variable to enable or disable specific customizations you make to
-the BE or CFE sources.
-
-YFLAGS should be set to a list of flags to pass to the Yacc program. As
-shipped, the list is -d -t, which causes Yacc to generate y.tab.h and
-y.tab.c files.
-
-LEXFLAGS should be set to a list of flags to pass to the Lex program. As
-shipped, the list -t.
-
-RANLIB should be set to the location of the ranlib program on your system.
-As shipped this is ranlib. If your system has no ranlib you can set this
-variable to ':' or /bin/true. As shipped the variable is preset to
-/bin/true since Solaris 2.x does not use ranlib.
-
-AR should be set to the location of the ar program on your system. As
-shipped this is ar. If your system has a different mechanism for creating
-libraries, you should modify the value of this variable accordingly.
-
-ARFLAGS should be set to the flags to be passed to the ar program. As
-shipped this is 'crv'.
-
-INSTALLATION
-
-a. Disk space requirements
-
-This distribution requires approximately 350 KBytes when compressed. When
-uncompressed, untarred and compiled, approximately 10 MBytes of disk space
-are consumed on a Sun 4.
-
-b. Getting the software
-
-Use anonymous FTP to omg.org and supply your e-mail address as password.
-Change directories to pub/OMG_IDL_CFE_1.3, set bin and get the compressed
-tar file OMG_IDL_CFE_1.3.tar.Z.
-
-The distribution may, in the future, be made available from other archives
-on the Internet. However, omg.org will always have the most up-to-date
-version of this software.
-
-After transferring this file, uncompress it and untar it in a directory of
-your choice.
-
-c. Compiling it
-
-If you are using a Sparcstation running Solaris 2.x and have the SunPro
-Sparcworks compilers installed, you may directly install the software. If
-your hardware or operating system configurations are different, read and
-follow the instructions in the previous section first.
-
-At the root directory of the release, issue
-
-   % make
-
-or
-
-   % make all
-
-This will compile the provided sources and the sources found in the be
-directory. Executing this make target causes 'make all' to be invoked in
-each subdirectory, resulting in building the libraries for each component
-and finally a link step producing an executable IDL compiler.
-
-In order to make only the compiler front end components, without compiling
-the sources found in the be directory and without building an executable,
-issue
-
-  % make libs
-
-This will build the libraries in the ast, fe, util, driver and narrow
-directories. To build only the be, issue
-
-  % make be
-
-To build all libraries without creating an executable, issue
-
-  % make all_libs
-
-To remove all files created by the build process, issue
-
-  % make clean
-
-This will not remove any files created by Yacc and Lex, because you may be
-using the ones provided in the distribution (see below).
-
-d. Yacc and Lex
-
-Some installations may not have a C++ aware Yacc and Lex processor. For
-these installations, we have included the output of yacc and lex in the
-release. If you need to use these files to build the release because you
-don't have access to a C++ capable Yacc or Lex, go to the "fe" directory,
-issue the command:
-
-   % touch lex.yy.cc y.tab.cc y.tab.hh
-
-This will ensure that the processed files appear to be newer than the
-source files they were produced from and will cause "make" to skip their
-production.
-
-NOTE: The files provided in the distribution have been produced on Solaris
-2.3 and may contain OS-specific #include directives. If you intend to use
-these files, you may have to edit them to make them work in your
-environment. The provided files are known to compile cleanly without
-modification with both SunPro Sparcworks compilers and GNU C++ on both
-SunOS 4.1 and Solaris 2.3.  We have not tested the grammar and lexer input
-files with bison or flex.
-
-IMPLEMENTING A BACK END
-
-To implement your own back end, you can start with the provided sources in
-the be directory and modify them. The Makefile understands the 'make all'
-target and will generate libbe.a in the demo_be directory. As set up, the
-variable CPP_FLAGS allows you to place include files either in the current
-directory or in the include directory. Alternatively, you can place your
-include files in a new directory and modify CPP_FLAGS to cause the C++
-preprocessor to search this new directory for referenced include files, by
-adding a new -I directive.
-
-Additional detail on the structure and function of back ends, and on the
-protocol which a back end must implement, are found in the document
-entitled WRITING_A_BE.
-
-COPYRIGHT
-
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
diff --git a/TAO/TAO_IDL/docs/PROBLEMS b/TAO/TAO_IDL/docs/PROBLEMS
deleted file mode 100644
index 65cfb6a1893..00000000000
--- a/TAO/TAO_IDL/docs/PROBLEMS
+++ /dev/null
@@ -1,132 +0,0 @@
-OMG INTERFACE DEFINITION LANGUAGE COMPILER FRONT END: KNOWN PROBLEMS
--==================================================================-
-
-INTRODUCTION
-
-This file describes what configurations are known to work correctly with
-this release, and what are the known problems with this release as shipped.
-Comments about future possible enhancements do not imply a commitment on
-the part of Sun or any of its subsidiaries to produce these enhancements.
-
-TESTED CONFIGURATIONS
-
-This release has been tested and is known to operate correctly on:
-
-- Sparcstation 2 running SunOS 4.1.2, when compiled with SparcWorks 3.0
-- Sparcstation 10 running Solaris 2.3, when compiled with SparcWorks 3.0.1
-- Sparcstation 10 running Solaris 2.3, when compiled with SparcWorks 4.0
-
-We are aware of a bug in GNU C++ (the latest version we tested was 2.5)
-which causes up-casting (changing the type of an instance from a base class
-to a more derived class, also known as "narrowing") to fail or cause a
-program crash.
-
-PROBLEMS:
-
-This is a list of known problems with the current version of the CFE:
-
-- The following syntax, although legal, is not accepted by the CFE:
-
-  .. sequence <string <10>> ..
-
-  This causes a parse error. The cause of this problem is that the '>>' is
-  read as a right shif operater and not as two '>'s. You can avoid this
-  problem by instead writing
-
-  .. sequence <string <10> > ..
-
-- The following syntax, although legal, is not accepted by the CFE:
-
-  const string foo = "abc" " and" " another" " string";
-
-  Instead, write:
-
-  const string foo = "abc and another string";
-
-- The printout produced by the -d option for dumping the AST is not always
-  perfect. Specifically, dumping of sequences and arrays is deficient.
-
-POSSIBLE FUTURE ENHANCEMENTS:
-
-This is a list of areas in which the code of the CFE may change in future
-releases:
-
-- The current release is restricted in its use of C++ because it must
-  be possible to compile it using C++ 2.1. However, we have also provided
-  files that depend on features which are only present in C++ 3.0, such as
-  templates. If your compiler supports templates and you wish to use them,
-  copy the files in include/utl_tmpl to include, and copy the files in
-  util/utl_tmpl to util. You will also need to make compiler dependent
-  modifications to Makefiles throughout the CFE directory hierarchy to
-  enable the use of templates.
-
-  The code using templates was donated by Steve Vinoski of HP.
-
-  In a future release of the CFE only the template code may be included,
-  and hence users will need to use a C++ 3.0 or higher compiler.
-
-- The UTL_list classes defined in the util directory are rudimentary. More
-  features may be added to make the functionality richer.
-
-- The UTL_String class may be rewritten or replaced by a standard ANSI C++
-  String implementation. Applications will be shielded from this change.
-
-COPYRIGHT:
-
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
diff --git a/TAO/TAO_IDL/docs/README b/TAO/TAO_IDL/docs/README
deleted file mode 100644
index 6d73554acce..00000000000
--- a/TAO/TAO_IDL/docs/README
+++ /dev/null
@@ -1,233 +0,0 @@
-INTERFACE DEFINITION LANGUAGE COMPILER FRONT END
--==============================================-
-
-INTRODUCTION
-
-Welcome to the publicly available source release of SunSoft's
-implementation of the compiler front end (CFE) for OMG Interface Definition
-Language! This is Release 1.3 of the CFE.
-
-The Interface Definition Language (IDL) implementation is divided into
-three parts:
-
-- A main program for driving the compilation process
-- A parser and attendant utilities
-- One or more back ends (BEs) for taking the processed input and producing
-  output in a target language and target format
-
-WARNINGS
-
-This is a preliminary version. This software is made available AS IS and
-WITH NO GUARANTEES. Please read  the copyright notice attached at the
-bottom of this file.
-
-IMPORTANT NOTICE FOR USERS OF OMG IDL CFE VERSION 1.2.
-
-Please carefully read the file CHANGES to obtain IMPORTANT INFORMATION on
-changes in that may affect the manner in which a BE is constructed. You
-must follow instructions contained in the file CHANGES to obtain a
-functional BE if you are migrating an existing BE from OMG IDL CFE v. 1.2.
-
-TARGET AUDIENCE
-
-Who should use this release?
-
-- You can use this source release to create a stand alone parser for OMG
-  Interface Definition Language. This may be useful to verify the legality
-  of IDL input.
-- Developers of OMG Interface Definition Language compilers should use this
-  release as a basis for writing their back ends, to obtain a common
-  framework for their compiler and to provide portable and uniform
-  parsing of IDL input.
-
-HOW TO OBTAIN THIS SOFTWARE
-
-Please use anonymous FTP to omg.org and supply your e-mail address as the
-password. Then change directories to pub/OMG_IDL_CFE_1.3, set binary transfer
-and get the file OMG_IDL_CFE_1.3.TAR.Z. This file includes copies of all
-individual documentation files in the directory.
-
-Precompiled binaries constructed from the sources in this release will be
-made available shortly, in the directory pub/OMG_IDL_CFE_1.3/bin. These
-binaries are useful for parsing IDL source and for learning about the
-language. Precompiled binaries for Solaris 2.x and for SunOS 4.x will be
-provided.
-
-You can also use the mail server program to retrieve this software. Send
-email with the subject 'help' to omg_idl@omg.org, and the mail server will
-respond with instructions on how to retrieve the software.
-
-Copies of this software may be made available from archives other than
-omg.org. New versions made available by Sun will be placed on omg.org and a
-message will be sent to this newsgroup announcing its availability.
-
-Finally, the SunSoft OMG IDL CFE is also available on magnetic tape for a
-nominal media charge directly from SunSoft. Please refer to part number
-DIDL-100-STP when ordering.
-
-CONTACT POINT
-
-Please let us know who you are if you decide to use this software, and how
-you use it. Please send e-mail to:
-
-     idl-cfe@sun.com
-
-This address can also be used to report problems, bugs, suggestions and
-send general comments.
-
-WHAT IS PROVIDED IN THE RELEASE
-
-Provided in this release are:
-
-- A main program for driving an Interface Definition Language compiler
-- A parser for the Interface Definition Language grammar which builds an
-  internal representation of the input parsed. This internal
-  representation, named an Abstract Syntax Tree (AST), is used as input to
-  a back end
-- Some utility functions used by the parser
-- A demonstration back end (BE) which exercises the front end but produces
-  no translated output
-- Documentation of the public interfaces and of the contract between
-  the compiler front end and a back end
-
-OPERATION
-
-A complete compiler operates in two passes:
-
-- The first pass, provided in this release, parses the IDL input and
-  produces an internal representation, called an Abstract Syntax Tree (AST).
-  This pass also does a complete syntax and semantics check of the input
-  provided to ensure that exactly legal IDL input is accepted. If a syntax
-  or semantic error is discovered, the second pass is not invoked.
-- The second pass, provided by compiler developers, takes the AST and
-  produces output in the language and format of choice. A demonstration
-  back end is provided in the release.
-
-HOW TO USE THIS SOFTWARE
-
-To create a complete compiler from OMG Interface Definition Language to a
-target language, compiler developers will:
-
-- Write a back end (BE) to take the internal representation of the input
-  parsed and translate it to the target language and format. You will
-  probably want to replace the BE directory in this source tree with your
-  own BE directory
-- Link the BE with the sources provided here to produce a complete
-  compiler.
-
-DOCUMENTATION
-
-The OMG Interface Definition Language is fully described in the CORBA
-documentation, Chapter 4. This document may be obtained from OMG.
-
-This release also provides the following documents:
-
-- This README file, describing the release
-- INSTALL, describing installation of the software
-- WRITING_A_BE contains all the information needed to start writing a back
-  end for this distribution
-- CHANGES_IN_AST describes changes that affect migration of BEs written
-  against version 1.2 to version 1.3.
-- CLI, describing the command line interface to the CFE
-- ROADMAP, describing the directory structure for the source code. This
-  file will assist a developer in understanding the structure of the code
-  and navigating it
-- PROBLEMS, describing a list of issues that may be addressed in future
-  releases
-- BUG_REPORT, containing a form for use in reporting bugs and problems
-  with the IDL CFE
-
-ENVIRONMENT
-
-The INSTALL file explains how to customize the software for specific
-platforms. The source distribution expects the following environment:
-
-- Sparcstation 1, 2, or 10 hardware
-- SunPro SparcWorks 3.x or 4.0
-
-As preconfigured, it compiles on Solaris 2.x. It can be reconfigured to
-compile on SunOS 4.x, HPUX or Apollo Domain OS. As far as is known, no use
-is made of Sun Make-specific features, and the Makefiles should be usable
-with other make programs.
-
-This release has been tested and is believed to operate correctly with:
-- SunPro Sparcworks 2.x and 3.0 on SunOS 4.1.x
-- SunPro Sparcworks 2.x and 3.0 on Solaris 2.3
-- g++ 2.5.8 on SunOS 4.1.x
-- g++ 2.5.8 on Solaris 2.3
-
-INSTALLATION
-
-This release is targetted for Sun workstations running Solaris 2.x. The
-process of installing this software is described in detail in the file
-INSTALL in this directory. The INSTALL file also describes how to customize
-the release for your own environment if it is different.
-
-KNOWN PROBLEMS
-
-A list of known deficiencies is provided in the file PROBLEMS in this
-directory. If you find a problem which is not mentioned in it, please
-report it as described below. Please read this file now to be apprised of
-the problems found so far with this release.
-
-COPYRIGHT
-
-This copyright notice appears on all files. Please read it!
-
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
diff --git a/TAO/TAO_IDL/docs/ROADMAP b/TAO/TAO_IDL/docs/ROADMAP
deleted file mode 100644
index 5da0d83823c..00000000000
--- a/TAO/TAO_IDL/docs/ROADMAP
+++ /dev/null
@@ -1,126 +0,0 @@
-INTERFACE DEFINITION LANGUAGE SOURCE TREE ROADMAP
--===============================================-
-
-INTRODUCTION
-
-This file provides an overview of the directory structure of the sources
-for the compiler front end for OMG Interface Definition Language. This will
-be of use in understanding the source structure and will aid developers of
-BEs.
-
-DIRECTORIES
-
-The following directories are present:
-
-- idl_specs:  Contains many examples of IDL specifications, including the
-	      IDL specifications of several Object Services, and several
-	      files that somewhat exhaustively test features of the IDL
-	      language
-- include:    Contains all include (".hh") files
-- ast:	      Contains implementations for all classes comprising
-	      the AST internal representation of the input parsed
-- fe:	      Contains the Yacc grammar and Lex specification for
-	      the OMG Interface Definition Language, and some utilities
-- driver:     Contains the main program which drives the compilation
-	      process
-- util:	      Contains utility classes used throughout the CFE. These
-	      classes may also be of use in writing a BE
-- narrow:     Contains an implementation of a narrowing mechanism used
-	      in the CFE. Since C++ does not provide compiler support
-	      for narrowing, this is provided as an explicit service
-- demo_be:    Contains a demonstration back end which subclasses all
-	      the AST classes but adds no functionality
-
-NAMING CONVENTIONS
-
-The file names start with two or three characters identifying the component
-to which they belong:
-
-- idl_:	      This is the prefix for all files which contain global
-	      elements of the CFE
-- ast_:	      This is the prefix for all files containing implementations
-	      or definitions of the AST
-- fe_:	      This is the prefix for all files belonging to the parser
-- drv_:	      This is the prefix for all files belonging to the compiler
-	      driver
-- utl_:	      This prefix is used to identify files belonging to the set of
-	      utlities provided with the CFE
-- nr_:	      This prefix identifies files belonging to the narrowing mechanim
-- be_:	      This is the prefix for all files belonging to the back end
-
-All C++ files use the ".cc" extension, and all include files have the ".hh"
-extension. All make files are named Makefile. Each directory contains a
-make file. Lex input files have the ".ll" extension, and Yacc input files
-use the ".yy" extension. All files containing IDL specifications have a
-name ending with the ".idl" suffix.
-
-INCLUDE FILE HIERARCHY
-
-There are two main include files which must be included in all source
-files. These are idl.hh and idl_extern.hh. The idl.hh file includes the
-definitions for all the facilities provided by the CFE. The idl_extern.hh
-file declares globally accessible data and exported application programmer
-interface entry points.
-
-Each component has an include file for its own. Back end writers will want
-to modify be.hh and possibly be_extern.hh.
-
-COPYRIGHT
-
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
diff --git a/TAO/TAO_IDL/docs/WRITING_A_BE b/TAO/TAO_IDL/docs/WRITING_A_BE
deleted file mode 100644
index 5c3c069f7a1..00000000000
--- a/TAO/TAO_IDL/docs/WRITING_A_BE
+++ /dev/null
@@ -1,1350 +0,0 @@
-OMG INTERFACE DEFINITION LANGUAGE COMPILER FRONT END PROTOCOLS
-==============================================================
-
-INTRODUCTION
-------------
-
-Welcome to the publicly available source release of SunSoft's
-implementation of the compiler front end (CFE) for OMG Interface Definition
-Language!
-
-This document explains how to use the release to create a fully functional
-OMG Interface Definition Language to target language compiler for your
-selected target system configuration. The section OVERVIEW explains this
-document's structure.
-
-CONTEXT
--------
-
-The implementation has three parts:
-
-1. A main program driving the compilation process
-2. A parser and attendant utilities for converting the IDL input into
-   an internal form
-3. One or more back ends which take as input the internal form representing
-   the IDL input, and which produce output in a target language and target
-   format
-
-The release contains components 1 and 2, and a demonstration implementation
-of component 3. To use this release, you
-
-- write a back end which takes the internal representation of the parsed input
-  and translates it to the target language and format. You may replace or
-  modify the demonstration back end provided.
-- link the back end with the provided main program and parser sources
-  to produce a complete compiler.
-
-OVERVIEW
---------
-
-This document does not explain IDL nor does it introduce IDL features. 
-For this information, refer to the OMG CORBA specification, available by
-anonymous FTP from omg.org.
-
-This document does not explain C++, except to demonstrate how it is
-used to construct the CFE. The ARM by Stroustrup and Ellis provides a
-thorough explanation of C++.
-
-This document consists of two independent parts. The first part
-s all CFE supported protocols and the required
-application programmer's interface entry points that a conformant 
-BE must provide. The second part steps through the process of
-constructing a working BE.
-
-The first part describes:
-
-- The compilation process
-- The Abstract Syntax Tree (AST) internal representation of parsed IDL
-  input
-- How access to member data fields is managed
-- How the AST is generated from the IDL input (Generator protocol)
-- How definition scopes are nested and how name lookup works
-- The narrowing mechanism
-- How definition scopes are managed and how nodes are added to scopes
-- How BEs get control during the AST construction process (Add protocol)
-- The inheritance scheme used by the AST and how it affects BEs
-- How errors are handled and reported
-- How the CFE is initialized
-- How the command line arguments are parsed
-- What global variables and functions are provided
-- What API is required to be supported by a BE in order to link
-  with the CFE
-- What files must be included in each BE file
-
-The second part describes
-
-- The API to be supplied by each BE
-- How to subclass from the AST to add BE specific functionality
-- How to subclass from the Generator protocol to create BE specific
-  extended AST nodes
-- How to write constructors for the derived BE classes
-- How to use the Add protocol to store BE specific information
-- How to maintain BE specific information which applies to the entire
-  AST generated from the IDL input
-- How to use data members in your BE
-- How to build a complete compiler
-
-PART I. FEATURES OF THE CFE
--=========================-
-
-THE COMPILATION PROCESS
------------------------
-
-The OMG IDL compiler operates as follows:
-
-- Parses command line arguments. If an option is directed at a
-  BE, an appropriate operation provided by the BE is invoked to process
-  the option.
-- Performs global initialization.
-- Forks a copy of the compiler for each file specified as input.
-- An ANSI-compatible preprocessor preprocesses the IDL input.
-- Parses the file using the CFE parser, and constructs an AST describing the
-  IDL input.
-- Prints the AST for verification, if requested.
-- Invokes the BE to process the AST and produce the output
-  characteristic of that BE.
-
-ABSTRACT SYNTAX TREE
---------------------
-
-The AST (Abstract Syntax Tree) is the primary mechanism for communication
-between a BE and the CFE. It consists of a tree of instances of classes
-defined in the CFE or refinements of those classes as defined in a BE.
-The class hierarchy of the AST closely resembles the structure of the IDL
-syntax. Most AST classes have direct equivalents in IDL constructs.
-
-The UTL_Scope class defines common functionality for definition scope
-management and name lookup. This is explained in a following section.
-UTL_Scope is defined in include/utl_scope.hh and implemented in
-util/utl_scope.cc.
-
-The AST provides the following classes:
-
-AST_Decl	    Base of the AST class hierarchy. Each class in the AST
-		    inherits from AST_Decl. Defined in include/ast_decl.hh
-		    and implemented in ast/ast_decl.cc
-
-AST_Type	    Common base class for all classes which represent IDL
-		    type constructs. Defined in include/ast_type.hh and
-		    implemented in ast/ast_type.cc. Inherits from AST_Decl.
-
-AST_ConcreteType    Common base class for all classes which represent IDL
-		    types other than interfaces. Defined in the file
-		    include/ast_concrete_type.hh and implemented in
-		    ast/ast_concrete_type.cc. Inherits from AST_Type.
-
-AST_PredefinedType  Instances of this class represent all predefined types
-		    such as long, char and so forth. Defined in the file
-		    include/ast_predefined_type.hh and implemented in
-		    ast/ast_predefined_type.cc. Inherits from
-		    AST_ConcreteType.
-
-AST_Module	    Represents the IDL module construct. Defined in the
-		    file include/ast_module.hh and implemented in
-		    ast/ast_module.cc. Inherits from AST_Decl and
-		    UTL_Scope.
-
-AST_Root	    Represents the root of the abstract syntax tree being
-		    constructed. Is a subclass of AST_Module. Can be
-		    subclassed in BEs to store information associated with
-		    the entire AST. Defined in the file include/ast_root.hh
-		    and implemented in ast/ast_root.cc. Inherits from
-		    AST_Module.
-
-AST_Interface	    Represents the IDL interface construct. Defined in
-		    include/ast_interface.hh and implemented in the file
-		    ast/ast_interface.cc. Inherits from AST_Type and
-		    UTL_Scope.
-
-AST_InterfaceFwd    Represents a forward declaration of an IDL interface.
-		    Defined in include/ast_interface_fwd.hh and implemented
-		    in ast/ast_interface_fwd.cc. Inherits from AST_Decl.
-
-AST_Attribute	    Represents an IDL attribute construct. Defined in
-		    include/ast_attribute.hh and implemented in the file
-		    ast/ast_attribute.cc. Inherits from AST_Decl.
-
-AST_Exception	    Represents an IDL exception construct. Defined in
-		    include/ast_exception.hh and implemented in the file
-		    ast/ast_exception.cc. Inherits from AST_Decl.
-
-AST_Structure	    Represents an IDL struct construct. Defined in the file
-		    include/ast_structure.hh and implemented in the file
-		    ast/ast_structure.cc. Inherits from AST_ConcreteType
-		    and UTL_Scope.
-
-AST_Field	    Represents a field in an IDL struct or exception
-		    construct. Defined in include/ast_field.hh and
-		    implemented in ast/ast_field.cc. Inherits from
-		    AST_Decl.
-
-AST_Operation	    Represents an IDL operation construct. Defined in the
-		    file include/ast_operation.hh and implemented in
-		    ast/ast_operation.cc. Inherits from AST_Decl and
-		    UTL_Scope.
-
-AST_Argument	    Represents an argument to an IDL operation construct.
-		    Defined in include/ast_argument.hh and implemented in
-		    ast/ast_argument.cc. Inherits from AST_Field.
-
-AST_Union	    Represents an IDL union construct. Defined in
-		    include/ast_union.hh and implemented in
-		    ast/ast_union.cc. Inherits from AST_ConcreteType and
-		    from UTL_Scope.
-
-AST_UnionBranch	    Represents an individual branch in an IDL union
-		    construct. Defined in include/ast_union_branch.hh and
-		    implemented in ast/ast_union_branch.cc. Inherits from
-		    AST_Field.
-
-AST_UnionLabel	    Represents the label of an individual branch in an IDL
-		    union construct. Defined in include/ast_union_label.hh
-		    and implemented in ast/ast_union_label.cc
-
-AST_Constant	    Represents an IDL constant construct. Defined in
-		    include/ast_constant.hh and implemented in the file
-		    ast/ast_constant.cc. Inherits from AST_Decl.
-
-AST_Enum	    Represents an IDL enum construct. Defined in the file
-		    include/ast_enum.hh and implemented in ast/ast_enum.cc.
-		    Inherits from AST_ConcreteType and UTL_Scope.
-
-AST_EnumVal	    Represents an enumerator in an IDL enum construct.
-		    Defined in include/ast_enum_val.hh and implemented in
-		    ast/ast_enum_val.cc. Inherits from AST_Constant.
-
-AST_Sequence	    Represents an IDL sequence construct. Defined in
-		    include/ast_sequence.hh and implemented in
-		    ast/ast_sequence.cc. Inherits from AST_Decl.
-
-AST_String	    Represents an IDL string construct. Defined in the file
-		    include/ast_string.hh and implemented in
-		    ast/ast_string.cc. Inherits from AST_Decl.
-
-AST_Array	    Represents an array modifier to the type of an IDL
-		    field or typedef declaration. Defined in the file
-		    include/ast_array.hh and implemented in
-		    ast/ast_array.cc. Inherits from AST_Decl.
-
-AST_Typedef	    Represents an IDL typedef construct. Defined in the file
-		    include/ast_typedef.hh and implemented in
-		    ast/ast_typedef.cc. Inherits from AST_Decl.
-
-AST_Expression	    Represents an IDL expression. Defined in the file
-		    include/ast_expression.hh and implemented in
-		    ast/ast_expression.cc.
-
-AST_Root	    A subclass of AST_Module, an instance of this class
-		    is used to represent the distinguished root node of
-		    the AST. Defined in include/ast_root.hh and implemented
-		    in ast/ast_root.cc. Inherits from AST_Module.
-
-
-USING INSTANCE DATA
--------------------
-
-The AST classes define member data fields in addition to defining
-operations on instances. These member data fields are all private, to allow
-only the instance in which they are stored direct access. Other objects
-(including other instances of the same class) can obtain access to the
-member data fields of an instance through accessor functions. These
-accessor functions allow retrieval of the data, and in some cases update
-functions are also provided to store new values.
-
-There are several reasons why this approach is taken. First, it hides the
-actual implementation of the member data fields from outside the class. For
-example, a Thermometer class would not expose whether its temperature
-reading is stored in Farenheit or Celsius units, and it could allow access
-through either unit method.
-
-Second, protecting access to member data in this manner restricts the
-ability to update it to the instance itself, save where update functions
-are explicitly provided. This makes for more reliable implementations,
-since the manipulation of the data is isolated in the class implementation
-itself.
-
-Third, wrapping a function call around access to member data allows such
-access and update operations to be protected in a multithreaded
-environment. While the CFE itself is not multithreaded and the access
-operations as currently defined do no special work to protect against
-mutliple conflicting access operations, this may be changed in a future
-version. Moving the CFE to a multithreaded environment without protecting
-access to member data in this manner would be extremely difficult.
-
-The protocol defined in the CFE is that member data fields are all private
-and have names which start with the prefix "pd_" (denoting Private Data).
-The access functions have names which are the same as the name of the field
-sans the prefix. For example, AST_Decl has a field pd_defined_in and an
-access function defined_in().
-
-The update functions have names starting with "set_" followed by the name
-of the corresponding access function. Thus, AST_Decl defines a function
-set_in_main_file(boolean) which sets the pd_in_main_file data member's
-value to the boolean provided.
-
-GENERATION OF THE AST
----------------------
-
-The CFE generates the abstract syntax tree after parsing IDL
-input. The nodes of the AST are defined by classes introduced in the
-previous section, or by subclasses thereof as defined by each BE. In
-writing the CFE, we were faced with the following problem: how to generate
-the AST containing nodes of the derived classes as defined in each BE
-without knowledge of the types and conventions of these BE classes.
-
-One alternative was to define a naming scheme which predetermines the names
-of each subclass a BE can define. The AST would then be generated by
-calling an appropriate constructor on the BE derived class. This scheme
-suffers from some shortcomings:
-
-- It breaks the modularity of the compiler and imports knowledge about
-  types defined in a BE into the CFE, where this information does not belong.
-- It restricts a compiler to having only one BE loaded at a time because the
-  names of these classes can be in use in only one BE at a time.
-- It requires a BE to provide derived classes for all AST classes, even for
-  those classes where the BE adds no functionality.
-
-The mechanism we chose is different. We define the AST_Generator class
-which has an operation for each constructor defined on each AST class. The
-operation takes arguments appropriate to the constructor, invokes it and
-returns the created AST node, using the type known to the CFE. All such
-operations on the generator are declared virtual. The names of all
-operations start with "create_" and contain the name of the construct.
-Thus, an operation which invokes a constructor of an AST_Module is named
-create_module. AST_Generator is defined in include/ast_generator.hh and
-implemented in ast/ast_generator.cc.
-
-If a BE derives from any AST class, it must also derive from the
-AST_Generator class and redefine the relevant operations to invoke
-constructors of the BE provided class instead of the AST provided class.
-For example, if BE_Module is a subclass of AST_Module in a BE, the BE would
-also define BE_Generator and redefine create_module to call the constructor
-of BE_Module instead of that provided by AST_Module.
-
-During initialization, the CFE causes an instance of the BE derived
-generator to be created and saved. This is explained in the section on
-REQUIRED ENTRY POINTS SUPPLIED BY A BE. During parsing, actions in the Yacc
-grammar invoke operations on the saved instance to create new nodes for the
-AST as it is being built. These operations invoke constructors for BE
-derived classes or for AST provided classes if they were not overridden.
-
-DEFINITION SCOPES
------------------
-
-IDL is a nested scoped language. The scoping rules are defined by the CORBA
-spec and closely follow those of C++.
-
-Scope management is implemented in two classes provided in the utilities
-library, UTL_Scope and UTL_Stack. UTL_Scope manages associations between
-names and AST nodes, and UTL_Stack manages scope nesting and entry and exit
-from definition scopes as the parse is proceeding. UTL_Scope is defined in
-include/utl_scope.hh and implemented in util/utl_scope.cc. UTL_Stack is
-defined in include/utl_stack.hh and implemented in util/utl_stack.cc.
-
-During initialization, the CFE creates an instance of UTL_Stack and saves
-it. During parsing, as definition scopes are entered and exited, AST nodes
-are pushed onto, or popped from, the stack represented by the saved
-instances. Nodes on the stack are stored as instances of UTL_Scope. Section
-THE NARROWING MECHANISM explains how to obtain the real type of a node
-retrieved from the stack.
-
-All definition scopes are linked in a tree rooted in the distinguished AST
-root node. This linkage is implemented by UTL_Scope and AST_Decl. The
-linkage is a permanent record of the scope nesting while the stack is a
-dynamic record which at each instant represents the current state of the
-parse.
-
-The nesting information is used to do name lookup. IDL uses scoped names  
-which are concatenations of definition scope names ending with individual
-construct names. For example, in
-
-	  interface a {
-		    struct b {
-			   long c;
-		    };
-		    const long k = 23;
-		    struct s {
-			   long ar[k];
-		    };
-	   };
-
-the name a::b::c represents the long field in the struct b inside the
-interface a.
-
-Lookup is performed by searching down the linkage chain for the first component
-of the name, then, when found, recursively resolving the remaining
-components in the scope defined by the first component. Lookup is relative
-to the scope of use; in the above example, k could also have been referred to
-as a::k within the struct s.
-
-Nodes are stored in a definition scope as instances of AST_Decl. Thus, name
-lookup returns instances of AST_Decl. The next section, THE NARROWING
-MECHANISM, explains how to obtain the real type of a node retrieved from a
-definition scope.
-
-THE NARROWING MECHANISM
------------------------
-
-Here we give only a cursory explanation of how narrowing works. We
-concentrate on defining the problem and showing how to use our narrowing
-mechanism. The narrowing mechanism is defined in include/idl_narrow.hh.
-
-As explained above, nodes are stored on the scope stack as instances of
-UTL_Scope, and inside definition scopes as instances of AST_Decl. Also,
-nodes are linked in a nesting tree as instances of AST_Decl. Given a node
-retrieved from the stack or a definition scope, one is faced with the task
-of obtaining its real class. C++ does not currently provide an implicit
-mechanism for narrowing to a derived class, so the CFE defines its own
-mechanism. This mechanism requires some work on your part as BE implementor
-and requires some explicit code to be written when it is to be used.
-
-The class AST_Decl defines an enum whose members encode specific AST node
-classes. AST_Decl provides an accessor function, node_type(), which
-retrieves a member of the enum representing the AST type of the node. Thus,
-if an instance of AST_Decl really is an instance of AST_Module, the
-node_type() accessor returns AST_Decl::NT_module.
-
-The class UTL_Scope also provides an accessor function, scope_node_type(),
-which returns a member of the enum encoding the actual type of the node.
-Thus, given an UTL_Scope instance which is really an instance of
-AST_Operation, scope_node_type() would return AST_Decl::NT_op.
-
-Perusing the header files for classes provided by the AST, you will note
-the use of some macros defined in include/idl_narrow.hh. These macros
-define the explicit narrowing mechanism:
-
-DEF_NARROW_METHODSx(<class name>,<parent_x>) for x equal to 0,1,2 or 3,
-defines a narrowing method for the specified class which has 0,1,2 or 3
-immediate base classes from which it inherits. For example, ast_module.hh
-which defines AST_Module contains the following line:
-
-      DEF_NARROW_METHODS2(AST_Module, AST_Decl, UTL_Scope)
-
-This is because AST_Module inherits directly from AST_Decl and UTL_Scope.
-
-DEF_NARROW_FROM_DECL(<class name>) appears in class definitions for classes
-which are derived from AST_Decl and which can be stored in a definition
-scope. This macro declares a static operation narrow_from_decl(AST_Decl *)
-on the class in which it appears. The operation returns the provided
-instance as an instance of <class name> if it can be narrowed, or NULL.
-
-DEF_NARROW_FROM_SCOPE(<class name>) appears in class definitions of classes
-which are derived from UTL_Scope and which can be stored on the scope
-stack. This macro declares a static operation narrow_from_scope(UTL_Scope *) 
-on the class in which it appears. The operation returns the provided
-instance as an instance of <class name> if it can be narrowed, or NULL.
-
-Now look in the files implementing these classes. You will note occurrences
-of the following macros:
-
-IMPL_NARROW_METHODSx(<class name>,<parent_x>) for x equal to 0,1,2 or 3,
-implements a narrowing method for the specified class which has 0,1,2 or 3
-immediate base classes from which it inherits. For example, ast_module.cc
-which implements AST_Module contains the following line:
-
-      IMPL_NARROW_METHODS2(AST_Module, AST_Decl, UTL_Scope)
-
-IMPL_NARROW_FROM_DECL(<class name>) implements a method to narrow from an
-instance of AST_Decl to an instance of <class name> as defined above.
-
-IMPL_NARROW_FROM_SCOPE(<class name>) implements a method to narrow from an
-instance of UTL_Scope to an instance of <class name> as defined above.
-
-To put it all together: In the file ast_module.hh, you will find:
-
-  // Narrowing
-  DEF_NARROW_METHODS2(AST_Module, AST_Decl, UTL_Scope);
-  DEF_NARROW_FROM_DECL(AST_Module);
-  DEF_NARROW_FROM_SCOPE(AST_Module);
-
-In the file ast_module.cc, you will see:
-
-/*
- * Narrowing methods
- */
-IMPL_NARROW_METHODS2(AST_Module, AST_Decl, UTL_Scope)
-IMPL_NARROW_FROM_DECL(AST_Module)
-IMPL_NARROW_FROM_SCOPE(AST_Module)
-
-The CFE uses narrowing internally to obtain the correct type of nodes in
-the AST. The CFE contains many code fragments such as the following:
-
-	  AST_Decl *d = get_an_AST_Decl_from_somewhere();
-	  AST_Module *m;
-	  ...
-	  if (d->node_type() == AST_Decl::NT_module) {
-	    m = AST_Module::narrow(d);
-	    if (m == NULL) {	// Narrow failed
-	      ...
-	    } else {		// Success, do normal processing
-	      ...
-	    }
-	  }
-	  ...
-
-Similar code implements narrowing instances of UTL_Scope to their actual
-types.
-
-In your BE classes which derive from UTL_Scope you must include a line
-defining how to narrow from a scope, so:
-
-	 DEF_NARROW_FROM_SCOPE(<your BE class>)
-
-and similarly for your BE classes which derive from AST_Decl.
-
-The narrowing mechanism is defined only for narrowing from AST_Decl and
-UTL_Scope. If your BE class inherits directly from one or more classes
-which themselves are derived from AST_Decl and/or UTL_Scope, you must
-include a line
-
-	DEF_NARROW_METHODSx(<your class name>,<parent 1>,<parent 2>)
-
-To make this concrete, here is what you'd write in a definition of BE_union
-which inherits from AST_Union:
-
-        DEF_NARROW_METHODS1(BE_Union, AST_Union);
-	DEF_NARROW_FROM_DECL(BE_Union);
-	DEF_NARROW_FROM_SCOPE(BE_Union);
-
-and in the implementation file of BE_Union:
-
-/*
- * Narrowing methods:
- */
-IMPL_NARROW_METHODS1(BE_Union, AST_Union)
-IMPL_NARROW_FROM_DECL(BE_Union)
-IMPL_NARROW_FROM_SCOPE(BE_Union)
-
-Then, in BE code which expects to see an instance of your derived BE_Union
-class, you will write:
-
-	  AST_Decl *d = get_an_AST_Decl_from_somewhere();
-	  BE_Union *u;
-	  ...
-	  if (d->node_type() == AST_Decl::NT_union) {
-	    u = BE_Union::narrow_from_decl(d);
-	    if (u == NULL) {	// Narrow failed
-	      ...
-	    } else {		// Success, do normal processing
-	      ...
-	    }
-	  }
-	  ...
-
-
-SCOPE MANAGEMENT
-----------------
-
-Instances of classes which are derived from UTL_Scope implement definition
-scopes. A definition scope can contain any kind of AST node as long as it
-is derived from AST_Decl. However, specific kinds of definition scopes such
-as interfaces and unions can contain only a restricted subset of all AST
-node types.
-
-UTL_Scope provides operations to add instances of each AST provided class
-to a definition scope. The names of these operations are constructed by
-prepending the string "add_" to the name of the IDL construct. So, to add
-an interface to a definition scope, invoke the operation add_interface.
-The operations are all defined virtual and are intended to be overridden in
-classes derived from UTL_Scope.
-
-If the node was successfully added to the definition scope, the node is
-returned as the result. Otherwise the node is not added to the definition
-scope and NULL is returned.
-
-All add operation implementations in UTL_Scope return NULL. Thus,
-only the operations which implement legal additions to a specific kind of
-definition scope must be overridden in the implementation of that
-definition scope. For example, in AST_Module the add_interface operation is
-overridden to add the provided instance of AST_Interface to the scope and
-to return the provided instance if the addition was successful. Operations
-which were not overridden return NULL to indicate that the addition is
-illegal in this context. For example, in AST_Operation the definition of
-add_interface is not overridden since it is illegal to store an interface
-inside an operation definition scope.
-
-The add operations are invoked in the actions in the Yacc grammar. The
-following fragment is a representative example of code using the add
-operations:
-
-	AST_Constant *d = construct_a_new_constant();
-	...
-	if (current_scope->add_constant(d) == NULL) { // Failed
-	   ...
-	} else {				      // Succeeded
-	  ...
-	}
-
-BE INTERACTION DURING THE PARSING PROCESS
------------------------------------------
-
-The add operations can be overridden in BE derived classes to let the BE
-perform additional house-keeping work during the process of constructing
-the AST. For example, a BE could keep separate lists of interfaces as they
-are being added to a module.
-
-If you override an add operation in your BE, you must invoke the overridden
-operation in the superclass of your derived class to allow the CFE to
-perform its own house-keeping tasks. A good rule is to invoke the operation
-on the superclass before you do your own processing; then, if the
-superclass operation returns NULL, this indicates that the addition failed
-and your own code should immediately return NULL. An example explains this:
-
-AST_Interface *
-BE_Module::add_interface(AST_Interface *i)
-{
-  if (AST_Module::add_interface(i) == NULL)	// Failed, bail out!
-    return NULL;
-  ...	   					// Do your own work here
-  return i;					// Return success indication   
-}
-
-We strongly advise you to only define add operations that override add
-operations provided by the AST classes. Add operations which
-do not override equivalent operations in the AST in effect
-extend the semantics of the language accepted by the compiler. For
-example, the CFE does not have an add_interface operation on
-AST_Operation. If you were to define one in your BE_Operation class,
-the resulting compiler would allow an interface to be
-stored in an operation definition scope. The current CORBA specification
-does not allow this.
-
-AST INHERITANCE SCHEME
-----------------------
-
-The AST classes all use public virtual inheritance to construct the
-inheritance tree. This ensures that a class may appear several times in the
-inheritance tree through different paths and the derived class's instances
-will have only one copy of the inherited class's data.
-
-The use of public virtual inheritance has several important effects on how
-a BE is constructed. We explain those effects below.
-
-First, you must define a default constructor for your BE class, since
-your class may be used as a virtual base class of some other class. In this 
-case the compiler may want to call a default constructor for your class. It
-is a good idea to have a default constructor anyway, even if you do not
-plan to subclass your BE class, since for most C++ compilers this causes
-the code to be smaller. Your default constructor should initialize all
-constant data members. Additionally, it may initialize any non-constant
-data member whose value must be set before the first time the instance is
-used.
-
-Second, the constructor of your BE derived class must explicitly call all
-constructors of virtual base classes which perform useful work. For
-example, if a class in the AST from which your BE class inherits has an
-initializer for a data member, you must call that constructor. This rule is
-discussed in detail in the C++ ARM. An example may help here.
-
-Suppose you define a class BE_attribute which inherits from AST_Attribute.
-Its constructor should be as follows:
-
-    BE_Attribute::BE_Attribute(boolean ro,
-			       AST_Type *ft,
-			       UTL_ScopedName *n,
-			       UTL_StrList *p)
-		: AST_Attribute(ro, ft, n, p),
-		  AST_Field(ft, n, p),
-		  AST_Decl(AST_Decl::NT_attr, n, p)
-    {
-    }
-
-The calls to the constructors of AST_Attribute, AST_Field and AST_Decl are
-needed because these constructors do useful initializations on their
-classes. 
-
-Note that there is some redundancy in the data passed to these
-constructors. We chose to preserve this redundancy since it should be
-possible to create BEs which subclass only some of the classes supplied by
-the AST. This means that the constructors on each class provided by the AST
-should take arguments which are sufficient to construct the instance if
-the AST class is the most derived one.
-
-The code supplied with this release contains a demonstration BE which
-subclasses all the AST provided classes. The constructors for each class
-provided by the BE are found in the file be/be_classes.cc.
-
-INITIALIZATION
---------------
-
-The following steps take place at initialization:
-
-- The global data instance is created, stored in idl_global and filled with
-  default values (in driver/drv_init.cc).
-- The command line arguments are parsed (in driver/drv_args.cc).
-- For each IDL input file, a copy of the compiler process is forked (in
-  driver/drv_fork.cc).
-- The IDL input is preprocessed (in driver/drv_preproc.cc).
-- FE initialization stage 1 is done: the scopes stack is created and stored
-  in the global data variable idl_global->scopes() field (in fe/fe_init.cc).
-- BE_init is called to create the generator instance and the returned
-  instance is stored in the global data variable idl_global->gen() field.
-- FE initialization stage 2 is done: the global scope is created, pushed on
-  the scopes stack and populated with predefined types (in fe/fe_init.cc).
-
-GLOBAL STATE AND ENTRY POINTS
------------------------------
-
-The CFE has one global variable named idl_global, which stores an instance
-of a class IDL_GlobalData as explained below:
-
-The CFE defines a class IDL_GlobalData which defines the global
-information used in a specific run of the compiler. IDL_GlobalData is
-defined in include/idl_global.hh and implemented in the file
-util/utl_global.cc.
-
-Initialization creates an instance of this class and stores it in the value
-of the global variable idl_global. Thus, the individual pieces of
-information stored in the instance are accessible everywhere.
-
-ERROR HANDLING
---------------
-
-All error handling is defined by a class provided by the CFE, UTL_Error.
-This class is defined in include/utl_error.hh and implemented in the file
-util/utl_error.cc. The class provides several methods for reporting
-specific errors as well as generic error reporting methods taking zero to
-three arguments.
-
-The CFE instantiates the class and stores the instance as part of the
-global state, accessible as idl_global->err(). Thus, to cause an error
-report, you would write code similar to the following:
-
-	if (error condition found)
-	   idl_global->err()->specific_error_message(arg1, ..);
-
-or
-
-	if (error condition found)
-	  idl_global->err()->generic_error_message(flag, arg1, ..);
-
-The flag argument is one of the predefined error conditions found in the
-enum at the head of the UTL_Error class definition. The arguments to the
-specific error message routine are defined by the signature of that
-routine. The arguments to a generic error message routine are always
-instances of AST_Decl.
-
-The running count of errors is accessible as idl_global->err_count(). If
-the value returned by this operation is non-zero after the IDL input has
-been parsed, the BE is not invoked.
-
-HANDLING OF COMMAND LINE ARGUMENTS
-----------------------------------
-
-Defined command line arguments are specified in the document CLI, in this
-directory. The CFE calls the required BE API entry point BE_prep_arg to
-process arguments passed within a -Wb flag.
-
-REQUIRED ENTRY POINTS SUPPLIED BY A BE
---------------------------------------
-
-The following API entry points must be supplied by a BE in order to
-successfully link with the CFE:
-
-extern "C" AST_Generator   *BE_init();
-
-       Creates an instance of the generator object and returns it. Note
-       that the global scope is not yet set up and the scopes stack is
-       empty when this routine is called.
-
-extern "C" void		   BE_produce();
-
-       Called by the compiler main program after the IDL input has been
-       successfully parsed and processed. The job of this routine is to
-       carry out the specific function of the BE. The AST is accessible as
-       the value of idl_global->root().
-
-extern "C" void	    	   BE_prep_arg(char *, idl_bool);
-
-       Called to process an argument passed in with a -Wb flag. The boolean
-       will always be FALSE.
-
-extern "C" void	      	   BE_abort();
-
-       Called when the CFE decides to abort the compilation. Can be used in
-       a BE to clean up after itself, e.g. remove temporary files or
-       directories it created while the parse was in progress.
-
-extern "C" void	      	   BE_version();
-
-       Called when a -V argument is processed. This should produce a
-       message for the user identifying the BE that is loaded and its
-       version information.
-
-PART II. WRITING A BACK END
--=========================-
-
-REQUIRED API THAT EACH BE MUST SUPPORT
---------------------------------------
-
-Below are the API entry points that each BE must supply in order to use the
-CFE framework. This is a repeat of the BE API section:
-
-extern "C" AST_Generator   *BE_init();
-
-       Creates an instance of the generator object and returns it. Note
-       that the scopes stack is still not set up at the time this routine
-       is called.
-
-extern "C" void		   BE_produce();
-
-       Called by the compiler main program after the IDL input has been
-       successfully parsed and processed. The job of this routine is to
-       carry out the specific function of the BE. The AST is accessible as
-       the value of idl_global->root().
-
-extern "C" void	    	   BE_prep_arg(char *, boolean);
-
-       Called to process an argument passed in with a -Wb flag. The boolean
-       will always be FALSE.
-
-extern "C" void	      	   BE_abort();
-
-       Called when the CFE decides to abort the compilation. Can be used in
-       a BE to clean up after itself, e.g. remove temporary files or
-       directories it created while the parse was in progress.
-
-extern "C" void	      	   BE_version();
-
-       Called when a -V argument is processed. This should produce a
-       message for the user identifying the BE that is loaded and its
-       version information.
-
-WHAT FILES TO INCLUDE
----------------------
-
-To use the CFE, each implementation file of your BE must include the
-following two header files:
-
-#include  <idl.hh>
-#include  <idl_extern.hh>
-
-Following this, you can include any header files needed by your BE.
-
-HOW TO SUBCLASS THE AST
------------------------
-
-Your BE may subclass from any of the classes provided by the AST. Your
-class should use public virtual inheritance to ensure that only one copy of
-the class's data members is present in each instance. Read the section on
-HOW TO WRITE CONSTRUCTORS to learn about additional considerations that you
-must take into account when writing constructors for your BE classes.
-
-HOW TO SUBCLASS THE GENERATOR TO CREATE BE ENHANCED AST NODES
--------------------------------------------------------------
-
-Your BE subclasses from classes provided by the AST. To ensure that
-instances of these classes are constructed when the AST is built, you must
-also subclass AST_Generator and return an instance of your subclass from
-the call to BE_init.
-
-The AST_Generator class provides operations to create instances of all
-classes defined in the AST. For example, the operation to create an
-AST_Attribute node is as follows:
-
-	AST_Attribute *
-	AST_Generator::create_attribute(...)
-	{
-	  return new AST_Attribute(...);
-	}
-
-In your BE_Generator subclass of AST_Generator, you will override methods
-for creation of nodes of all AST classes which you have subclassed. Thus,
-if your BE has a class BE_Attribute which is a subclass of AST_Attribute,
-your BE_Generator class definition has to override the create_attribute
-method to ensure that instances of BE_Attribute are created.
-
-The definition of the overriden operations should call the constructor of
-the derived class and return the new node as an instance of the inherited
-class. Thus, the implementation of create_attribute is as follows:
-
-	AST_Attribute *
-	BE_Generator::create_attribute(...)
-	{
-	  return new BE_Attribute(...);
-	}
-
-The Yacc grammar actions call create_xxx operations on the generator
-instance stored in the global variable idl_global->gen() field. By storing
-an instance of your derived generator class BE_Generator you ensure that
-instances of the BE classes you defined will be created.
-
-HOW TO WRITE CONSTRUCTORS FOR BE CLASSES
-----------------------------------------
-
-As mentioned above, the AST uses public virtual inheritance to derive the
-AST class hierarchy. This has two important effects on how you write a BE,
-specifically how you write constructors for derived BE classes.
-
-First, you must define a default constructor for your BE class, since
-your class may be used as a virtual base class of some other class. In that
-case the compiler may want to call a default constructor for your class. It
-is a good idea to have a default constructor anyway, even if you do not
-plan to subclass your BE class, since for most C++ compilers this causes
-the code to be smaller. Your default constructor should initialize all
-constant data members. Additionally, it may initialize any non-constant
-data member whose value must be set before the first time the instance is
-used.
-
-Second, the constructor for your BE class must explicitly call all
-constructors of virtual base classes which do some useful work. For
-example, if a class in the AST from which your BE class inherits, directly
-or indirectly, has an initializer for a data member, your BE class's
-constructor must call the AST class's constructor. This is discussed
-extensively in the C++ ARM.
-
-Below is a list showing how to write constructors for subclasses of each
-class provided by the BE. For each AST class we show a definition of a
-constructor for a derived class which calls all neccessary constructors on
-AST classes:
-
-AST_Argument:
-
-	BE_Argument::BE_Argument(AST_Argument::Direction d,
-				 AST_Type *ft,
-				 UTL_ScopedName *n,
-				 UTL_StrList *p)
-		   : AST_Argument(d, ft, n, p),
-		     AST_Field(AST_Decl::NT_argument, ft, n, p),
-		     AST_Decl(AST_Decl::NT_argument, n, p)
-	{
-	}
-
-AST_Array:
-
-	BE_Array::BE_Array(UTL_ScopedName *n,
-			   unsigned long nd,
-			   UTL_ExprList *ds)
-		: AST_Array(n, nd, ds),
-		  AST_Decl(AST_Decl::NT_array, n, NULL)
-
-	{
-	}
-
-AST_Attribute:
-
-	BE_Attribute::BE_Attribute(boolean ro,
-				   AST_Type *ft,
-				   UTL_ScopedName *n,
-				   UTL_StrList *p)
-		    : AST_Attribute(ro, ft, n, p),
-		      AST_Field(AST_Decl::NT_attr, ft, n, p),
-		      AST_Decl(AST_Decl::NT_attr, n, p)
-	{
-	}
-
-AST_ConcreteType:
-
-	BE_ConcreteType::BE_ConcreteType(AST_Decl::NodeType nt,
-					 UTL_ScopedName *n,
-					 UTL_StrList *p)
-		       : AST_Decl(nt, n, p)
-	{
-	}
-
-AST_Constant:
-
-	BE_Constant::BE_Constant(AST_Expression::ExprType t,
-				 AST_Expression *v,
-				 UTL_ScopedName *n,
-				 UTL_StrList *p)
-		   : AST_Constant(t, v, n, p),
-		     AST_Decl(AST_Decl::NT_const, n, p)
-	{
-	}
-
-AST_Decl:
-
-	BE_Decl::BE_Decl(AST_Decl::NodeType nt,
-			 UTL_ScopedName *n,
-			 UTL_StrList *p)
-	       : AST_Decl(nt, n, p)
-	{
-	}
-
-AST_Enum:
-
-	BE_Enum::BE_Enum(UTL_ScopedName *n,
-			 UTL_StrList *p)
-	       : AST_Enum(n, p),
-		 AST_Decl(AST_Decl::NT_enum, n, p),
-		 UTL_Scope(AST_Decl::NT_enum)
-	{
-	}
-
-AST_EnumVal:
-
-	BE_EnumVal::BE_EnumVal(unsigned long v,
-			       UTL_ScopedName *n,
-			       UTL_StrList *p)
-		  : AST_EnumVal(v, n, p),
-		    AST_Constant(AST_Expression::EV_ulong,
-		    		 AST_Decl::NT_enum_val,
-				 new AST_Expression(v),
-				 n,
-				 p),
-		    AST_Decl(AST_Decl::NT_enum_val, n, p)
-	{
-	}
-
-AST_Exception:
-
-	BE_Exception::BE_Exception(UTL_ScopedName *n,
-				   UTL_StrList *p)
-		    : AST_Decl(AST_Decl::NT_except, n, p),
-		      AST_Structure(AST_Decl::NT_except, n, p),
-		      UTL_Scope(AST_Decl::NT_except)
-	{
-	}
-
-AST_Field:
-
-	BE_Field::BE_Field(AST_Type *ft,
-			   UTL_ScopedName *n,
-			   UTL_StrList *p)
-		: AST_Field(ft, n, p),
-		  AST_Decl(AST_Decl::NT_field, n, p)
-	{
-	}
-
-AST_Interface:
-
-	BE_Interface::BE_Interface(UTL_ScopedName *n,
-				   AST_Interface **ih,
-				   long nih,
-				   UTL_StrList *p)
-		    : AST_Interface(n, ih, nih, p),
-		      AST_Decl(AST_Decl::NT_interface, n, p),
-		      UTL_Scope(AST_Decl::NT_interface)
-	{
-	}
-
-AST_InterfaceFwd:
-
-	BE_InterfaceFwd::BE_InterfaceFwd(UTL_ScopedName *n,
-					 UTL_StrList *p)
-		       : AST_InterfaceFwd(n, p),
-			 AST_Decl(AST_Decl::NT_interface_fwd, n, p)
-	{
-	}
-
-AST_Module:
-
-	BE_Module::BE_Module(UTL_ScopedName *n,
-			     UTL_StrList *p)
-		 : AST_Decl(AST_Decl::NT_module, n, p),
-		   UTL_Scope(AST_Decl::NT_module)
-	{
-	}
-
-AST_Operation:
-
-	BE_Operation::BE_Operation(AST_Type *rt,
-				   AST_Operation::Flags fl,
-				   UTL_ScopedName *n,
-				   UTL_StrList *p)
-		    : AST_Operation(rt, fl, n, p),
-		      AST_Decl(AST_Decl::NT_op, n, p),
-		      UTL_Scope(AST_Decl::NT_op)
-	{
-	}
-
-AST_PredefinedType:
-
-	BE_PredefinedType::BE_PredefinedType(
-				AST_PredefinedType::PredefinedType *pt,
-				UTL_ScopedName *n,
-				UTL_StrList *p)
-			 : AST_PredefinedType(pt, n, p),
-			   AST_Decl(AST_Decl::NT_pre_defined, n, p)
-	{
-	}
-
-AST_Root:
-
-	BE_Root::BE_Root(UTL_ScopedName *n, UTL_StrList *p)
-	       : AST_Module(n, p),
-	         AST_Decl(AST_Decl::NT_module, n, p),
-		 UTL_Scope(AST_Decl::NT_module)
-	{
-	}
-
-
-AST_Sequence:
-
-	BE_Sequence::BE_Sequence(AST_Expression *ms, AST_Type *bt)
-		   : AST_Sequence(ms, bt),
-		     AST_Decl(AST_Decl::NT_sequence,
-		     	      new UTL_ScopedName(new String("sequence"), NULL),
-			      NULL)
-	{
-	}
-
-AST_String:
-
-	BE_String::BE_String(AST_Expression *ms)
-		 : AST_String(ms),
-		   AST_Decl(AST_Decl::NT_string,
-		   	    new UTL_ScopedName(new String("string"), NULL),
-			    NULL)
-	{
-	}
-
-AST_Structure:
-
-	BE_Structure::BE_Structure(UTL_ScopedName *n,
-				   UTL_StrList *p)
-		    : AST_Decl(AST_Decl::NT_struct, n, p),
-		      UTL_Scope(AST_Decl::NT_struct)
-	{
-	}
-
-AST_Type:
-
-	BE_Type::BE_Type(AST_Decl::NodeType nt,
-			 UTL_ScopedName *n,
-			 UTL_StrList *p)
-	       : AST_Decl(nt, n, p)
-	{
-	}
-
-AST_Typedef:
-
-	BE_Typedef::BE_Typedef(AST_Type *bt,
-			       UTL_ScopedName *n,
-			       UTL_StrList *p)
-		  : AST_Typedef(bt, n, p),
-		    AST_Decl(AST_Decl::NT_typedef, n, p)
-	{
-	}
-
-AST_Union:
-
-	BE_Union::BE_Union(AST_ConcreteType *dt,
-			   UTL_ScopedName *n,
-			   UTL_StrList *p)
-		: AST_Union(dt, n, p),
-		  AST_Structure(AST_Decl::NT_union, n, p),
-		  AST_Decl(AST_Decl::NT_union, n, p),
-		  UTL_Scope(AST_Decl::NT_union)
-	{
-	}
-
-AST_UnionBranch:
-
-	BE_UnionBranch::BE_UnionBranch(AST_UnionLabel *fl,
-				       AST_Type *ft,
-				       UTL_ScopedName *n,
-				       UTL_StrList *p)
-		      : AST_UnionBranch(fl, ft, n, p),
-		        AST_Field(ft, n, p),
-			AST_Decl(AST_Decl::NT_union_branch, n, p)
-	{
-	}
-
-AST_UnionLabel:
-
-	BE_UnionLabel::BE_UnionLabel(AST_UnionLabel::UnionLabel lk,
-				     AST_Expression *lv)
-		     : AST_UnionLabel(lk, lv)
-	{
-	}
-
-HOW TO USE THE ADD PROTOCOL
----------------------------
-
-As explained the section SCOPE MANAGEMENT, the CFE manages scopes by
-calling type-specific functions to add new nodes to the scope to be
-augmented. These functions can be overridden in your BE classes to do work
-specific to your BE class. For example, in a BE_module class, you might
-override add_interface to do additional work.
-
-The protocol defined by the "add_" functions is that they return NULL to
-indicate failure. They return the node that was added (and which was given
-as an argument) if the operation succeeded. Your functions in your BE class
-should follow the same protocol.
-
-The "add_" functions defined in the BE must call the overridden function in
-the base class defind in the CFE in order for the CFE scope management
-mechanism to work.  Otherwise, the CFE does not get an opportunity to
-augment its scopes with the new node to be added. It is good practice to
-call the overridden "add_" function as the first action in your BE
-function, because the success or failure of the CFE operation indicates
-whether your function should complete its task or abort early.
-
-Here is an example. Suppose you have defined a class BE_module which
-inherits from AST_Module. You may wish to override the add_interface
-function as follows:
-
-	 class BE_Module : public virtual AST_Module
-	 {
-	 	....
-		/*
-		 * ADD protocol
-		 */
-		virtual AST_Interface	*add_interface(AST_Interface *);
-		...
-	};
-
-The implementation of this function would look something like the following:
-
-    AST_Interface *
-    BE_Module::add_interface(AST_Interface *new_in)
-    {
-    	/*
-	 * Check that the CFE operation succeeds. If it returns
-	 * NULL, stop any further work
-	 */
-	if (AST_Module::add_interface(new_in) == NULL)
-	  return NULL;
-	/*
-	 * OK, non-NULL, this means the BE can do its own work here
-	 */
-	...
-	/*
-	 * Finally, don't forget to return the argument to indicate
-	 * success
-	 */
-	return new_in;
-    }	  
-
-HOW TO MAINTAIN BE SPECIFIC INFORMATION
----------------------------------------
-
-The CFE provides a special class AST_Root, a subclass of AST_Module. An
-instance of the AST_Root class is used as the distinguished root of the
-abstract syntax tree built during a parse.
-
-Your BE can subclass BE_Root from AST_Root and override the create_root
-operation in your BE_Generator class derived from AST_Generator. This will
-cause the CFE to create an instance of your BE_Root class as the root of
-the tree being constructed.
-
-You can use the instance of the BE_Root class as a convenient place to
-store information specific to an individual tree. For example, you could
-add operations on the BE_Root class to count how many nodes of each class
-are created.
-
-HOW TO USE MEMBER DATA
-----------------------
-
-As explained above, the AST classes provide access and update functions for
-manipulating data members. Your BE classes must use these functions when
-they require access to data members defined in the AST classes, since the
-data members themselves are private.
-
-It is good practice to follow the same scheme in your BE classes. Make all
-data members private. Prepend the names of all such fields with "pd_".
-Define access functions with names equal to the name of the field without the
-prefix. Define update functions according to need by prepending the name of
-the access function with the prefix "set_".
-
-Using these techniques will allow your BE to enjoy the same benefits that
-are imparted onto the CFE. Your BE will be easier to move to a
-multithreaded environment and its data members will be better protected and
-hidden.
-
-HOW TO BUILD A COMPLETE COMPILER
---------------------------------
-
-We now have all information needed to write a BE and to link it in with the
-CFE, to produce a complete IDL compiler.
-
-The following assumes that your BE will be stored in the "be" directory
-under the "release" directory. See the document ROADMAP for an explanation
-of the directory structure of the source release. If you decide to use a
-different directory to store your BE, you may have to modify the CPP_FLAGS in
-"idl_make_vars" in the top-level directory to allow your BE to find the
-include files it needs. You will also need to modify several targets in
-the Makefile in the top-level directory to correctly compile your BE into a
-library and to correctly link it in with the CFE to produce a complete
-compiler.
-
-You can get started quickly on writing your BE by modifying the sources
-found in the "demo_be" directory. The Makefile supports all the the targets
-that are needed to build a complete system and the maintenance target
-"clean" which assists in keeping the files and directories tidy. The files
-provided in the "demo_be" directory also provide all the API entry points
-that are mandated by this document.
-
-To build a complete compiler, invoke "make" or "make all" in the top-level
-directory. This will compile your BE and all the CFE sources, if this is
-the first invocation. On subsequent invocations this will recompile only
-the modified files. You will rarely if at all modify the CFE sources, so
-the overhead of compiling the CFE is incurred only the first time. To build
-just your BE, you can invoke "make all" or "make" in the "demo_be"
-directory. You can also, from the top-level directory, invoke "make
-demo_be/libbe.a".
-
-HOW TO OBTAIN ASSISTANCE
-------------------------
-
-First, read all the documents provided. If you have unanswered questions,
-mail them to
-
-	idl-cfe@sun.com
-
-Sun does not promise to support the IDL CFE source release in any manner.
-However, we will attempt to answer questions and correct problems as time
-allows.
-
-NOTE:
-
-SunOS, SunSoft, Sun, Solaris, Sun Microsystems or the Sun logo are
-trademarks or registered trademarks of Sun Microsystems, Inc.
-
-COPYRIGHT NOTICE
-----------------
-
-Copyright 1992, 1993, 1994 Sun Microsystems, Inc.  Printed in the United
-States of America.  All Rights Reserved.
-
-This product is protected by copyright and distributed under the following
-license restricting its use.
-
-The Interface Definition Language Compiler Front End (CFE) is made
-available for your use provided that you include this license and copyright
-notice on all media and documentation and the software program in which
-this product is incorporated in whole or part. You may copy and extend
-functionality (but may not remove functionality) of the Interface
-Definition Language CFE without charge, but you are not authorized to
-license or distribute it to anyone else except as part of a product or
-program developed by you or with the express written consent of Sun
-Microsystems, Inc. ("Sun").
-
-The names of Sun Microsystems, Inc. and any of its subsidiaries or
-affiliates may not be used in advertising or publicity pertaining to
-distribution of Interface Definition Language CFE as permitted herein.
-
-This license is effective until terminated by Sun for failure to comply
-with this license.  Upon termination, you shall destroy or return all code
-and documentation for the Interface Definition Language CFE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED AS IS WITH NO WARRANTIES OF
-ANY KIND INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS
-FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM A COURSE OF
-DEALING, USAGE OR TRADE PRACTICE.
-
-INTERFACE DEFINITION LANGUAGE CFE IS PROVIDED WITH NO SUPPORT AND WITHOUT
-ANY OBLIGATION ON THE PART OF Sun OR ANY OF ITS SUBSIDIARIES OR AFFILIATES
-TO ASSIST IN ITS USE, CORRECTION, MODIFICATION OR ENHANCEMENT.
-
-SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES SHALL HAVE NO LIABILITY WITH
-RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY
-INTERFACE DEFINITION LANGUAGE CFE OR ANY PART THEREOF.
-
-IN NO EVENT WILL SUN OR ANY OF ITS SUBSIDIARIES OR AFFILIATES BE LIABLE FOR
-ANY LOST REVENUE OR PROFITS OR OTHER SPECIAL, INDIRECT AND CONSEQUENTIAL
-DAMAGES, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-Use, duplication, or disclosure by the government is subject to
-restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
-Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
-52.227-19.
-
-Sun, Sun Microsystems and the Sun logo are trademarks or registered
-trademarks of Sun Microsystems, Inc.
-
-SunSoft, Inc.  
-2550 Garcia Avenue 
-Mountain View, California  94043