PAL CARD CATALOG ENTRY

SHORT DESCRIPTION

Automatically translate C Header files to Ada


MOVEMENT WITHIN THE PAL CARD CATALOG
Move to top-level taxonomy
Move to keyword list

ASSET PROFILE

UNIT NAME
CH2ADA
VERSION
1.0.2
REVIEW CODE
OK
INET ADDRESS
mark@irvine.com
jes@sgi.com
AUTHOR
Mark Schimmel
Irvine Compiler Corporation
34 Executive Prak, Suite 270
Irvine CA 92714, USA
RIGHTS
Approved for public release; distribution unlimited
COPYRIGHT
1992 Irvine Compiler Corporation
DATE CREATED
Not documented in PAL database
DATE RELEASED
21 Jan 94
DATE LAST UPDATED
21 Jan 94
LOCATION
PAL
ENVIRONMENT
Sun sparc at SunOS 4.0.2
Sun motorola at SunOS 4.0.2
Sun Intel at SunOS 4.0.1
Mips R3000 at RISC/os 4.52
Mips R3000 at SGI Irix 4.0.5
Mips R3000 at DEC Ultrix 4.2
IBM RIOS at AIX 3.1
HP700 at HP/UX ????
HP835 at HP/UX ????
LIMITATIONS
None

FILE LISTING

Directory Display


languages/ada/swtools/ch2ada:
  File Name                 Size
  ---------                 ----
  README                   7,617
  ch2ada.zip             243,447


Totals
  ==============  ==============
    2 Files              251,064

ABSTRACT

c2ada/cfront

This is the second release of this translator.  It my hope that it
soon will be provided in source form free of charge.

REVISION ENHANCEMENTS

Added support for C const vars.
Added floating point support.
Fixed Ada/83 record field naming errors.
Changed -Dname defines to have a value of 1.
Added -version flag to support patch identification.

RATIONALE

The C programming language enjoys an enormous amount of popularity
thanks to its free distribution with the Unix operating systems and to
its early acceptance among the accedemic community.  That being the
case there is a large amount of useful software, libraries and
algorithms that are freely available to C programmers.  I'd like to
provide a means of making that software base easily accessible to the
Ada community as well.

PORTING

This translator generates some types that are not immediately portable
to all Ada compilers.  However, most of the generated types are
subtypes from the package C provided in this distribution.  The very
first thing you will need to do before the generated Ada code will
compile is retarget package C to your compiler.  Don't worry about
getting all the unsigneds correct before you start playing with the
translator, just make sure the sizes of the types are correct.  You'll
be able to lookup all the nasty compiler hacks at a later time.

IMPLEMENTATION

This version of the translator is basically a parser for the ansi C
type system.  It also includes a built in C preprocessor that attempts
to make macro definitions available to the Ada community as well.

A major ATTEMPT was made to maintain the exact names from the original
C source.  This is not always possible.

I prefer a loose type system so most types generated by the translator
will follow that philosophy.  It feels like the "right thing" to do
when the language you are interfacing to is so relaxed.  I'm quite
sure this will be a point of contention to many in the Ada community.
There already appears to me to be two factions;  those who derive
everything and those who are forced to cast cast cast cast cast :-).

Anyway, back to the particulars.  Unions, unsigneds and function
pointers are not supported by all Ada compilers.  The code generated
by this translator targets the ICC Ada compiler and will be particular
to it in this release (like I said I'd like to make the sources
available for others to port to verdix, dec, mips, rational ...).

Unions:
        Unions are implemented as records whose fields are overlayed
via rep specs.  The overlaying of fields via rep specs is not allowed
in the Ada language.  However, most compilers realize that it is a
very useful thing to do and will have some mechanism that supports it.
I have already received and rejected feedback from some who'd like to
see this become some sucky variant record.  Sorry to those of you who
hold that opinion but a C union is not an Ada variant record.

        union u1 {
                int field1;
                char *field2;
        };

        type u1 is
           record
              field1: int;
              field2: char_p;
           end record;
        for u1 use
           record
              field1 at 0 range 0 .. 31;
              field2 at 0 range 0 .. 31;
           end record;

Unsigneds:
        Unsigned integers are supported by most compilers through some
mechanism or another.  They are generated by this translator as
subtypes to a type from the package C.  Once you get the package C
ported properly unsigned integers should work just fine.

Function Pointers:
        Function pointers are subtypes of system.address and loose
their prototype information (parameters and return type).  This is
unfortunate, but I haven't yet thought of a good way around it.  I'm
open to any and all suggestions.

Type aliasing:
        C has a very forgiving type system.  This translator attempts
to model that behavior.  I have gotten some good feedback here about
generating derived types from typedefs and will be incorporating that
into the next release.

Anonymous types:
        One important thing that I'd like to mention here in defense
of the current implementation is that user type names are preferred
over generated type names.  For example:

        extern char *p1;
        struct s {
                char *p2;
        };
        typedef char *caddr_t;
        
        
        type s;
        type caddr_t is access char;
        type s is
           record
              p2: caddr_t;
           end record;
        p1: caddr_t;
        pragma interface(c, p1);

I have received negative feedback from many who don't like the fact
that variables with anonymous types (as in p1 and p2) will have their
types promoted to another type.  The reason this is done is to avoid
compiler generated type names.  In the above example the compiler
could have generated some type name for the anonymous char * types of
p1 and p2.  This was not done because the user provided a type name
with a base type of char *.  My contention with compiler generated
type names is that if I use them you will have to go searching through
the output to find the names the translator chose.  If instead you
provide a low level typedef scheme of your own, you can be assured
that the translator will choose your names, which I think is a more
deterministic approach.

RELEASE

As this is only released in binary format at the moment we have
compiled it on all of the major platforms that people have asked for,
and bundled all of the support files into a single tar file per
platform.  The currently supported platforms are:
	Sun sparc    at SunOS 4.0.2
	Sun motorola at SunOS 4.0.2
	Sun Intel    at SunOS 4.0.1
	Mips R3000   at RISC/os 4.52
	Mips R3000   at SGI Irix 4.0.5
	Mips R3000   at DEC Ultrix 4.2
	IBM RIOS     at AIX 3.1
	HP700        at HP/UX ????
	HP835        at HP/UX ????

Please contact Mark Schimmel (mark@irvine.com) with coding bugs or
feature requests, and John Schimmel (jes@sgi.com) with release problems.


REVISION HISTORY

21 Jan 94   1.0.2   Mark Schimmel   Release to the PAL


RELEASE NOTICE

This prologue must be included in all copies of this software.
Restrictions on use or distribution:  NONE

Everyone is permitted to copy and distribute verbatim copies of this
software as long as this document is distributed with it, but changing
it is not allowed.

All rights to this C header file to Ada source translator are
reseverved by Irvine Compiler Corporation.  It has been provided free
of charge without support and without any obligation on the part of
Irvine Compiler.

THIS SOFTWARE IS PROVIDED "AS IS" WITH NO WARRANTIES OF ANY KIND
INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A
PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR
TRADE PRACTICE.

In no event will Silicon Graphics, Inc. be liable for any lost revenue or 
profits or other special, indirect and consequential damages, even if 
Silicon Graphics, Inc.  has been advised of the possibility of such damages.


DISCLAIMER

	This software and its documentation are provided "AS IS" and
without any expressed or implied warranties whatsoever.  No warranties
as to performance, merchantability, or fitness for a particular
purpose exist.
	The user is advised to test the software thoroughly before
relying on it.  The user must assume the entire risk and liability of
using this software.  In no event shall any person or organization of
people be held responsible for any direct, indirect, consequential or
inconsequential damages or lost profits.