From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bbn!inmet!ishmael!inmet!ada-uts!offer
From: offer@ada-uts
Newsgroups: comp.lang.ada
Subject: Re: Protection for Ada Binary Libraries
Message-ID: <57900063@ada-uts>
Date: 20 Feb 88 16:04:00 GMT
References: <324@ajpo.sei.cmu.edu>
Nf-ID: #R:ajpo.sei.cmu.edu:-32400:ada-uts:57900063:000:1257
Nf-From: ada-uts!offer    Feb 20 11:04:00 1988
List-Id: <comp.lang.ada>


There are three different issues in your question:

1. Most compilers, and in particular, those that use DIANA, have a
mechanism to not include the source (or some form of internal
representation of the source) in the program library, the reasons
being: reducing the size of those libraries and keeping bodies' source
code proprietary (e.g. the implementation of TEXT_IO). The disadvantage
is clearly the inability the see the source at debug time and also
the inability to provide pretty-printing/interspersed source/assembly
listings.

2. Most compilers, today, support hierarchical library structure. By
protecting part of the library, one can inhibit read access to
certain data in this part (this is both a program library manager and
a debugger functionality). A vendor may put the spec in one library
and the body in another and protect the later.

3. About a binary interface to a reusable component. The only way
to do it without the need to recompile for each compiler, is to agree
on standard binary interface (calling sequence, data reps, etc). The
compiler can then support it via pragma INTERFACE. I believe as more
and more similar requirements appear, those standards will emerge.

Offer Pazy
Intermetrics, Inc.
Cambridge, MA
(617) 661-1840