Future of Linux (.so contracts)

Davide Bolcioni davide.bolcioni at 3di.it
Tue Nov 17 00:44:38 PST 1998


Bruce Stephens wrote:
> 
> Davide Bolcioni <davide.bolcioni at 3di.it> writes:
> 
> > If we say a library is a collection of functions which have a
> > signature and an implementation, the notion of change becomes: 1 -
> > an implementation change which preserves the signature; 2 - a
> > signature change (which may be construed as a deletion followed by
> > an addition, so anybody expecting to find the old function should
> > not find it) which almost always implies an implementation change;
> >
> > The problem, of course, is that we check the signature but care
> > about the implementation (in the sense that we call a function for
> > what it does, although we should not rely on the exact means it uses
> > to get the job done). The implementation includes considerations
> > such as efficiency, i.e. application chose a function with more
> > limited functionality because it was more efficient, so
> > implementation goes into the contract in multiple ways (which is
> > inconvenient).
> 
> I'm probably going off at a bit of a tangent, but it strikes me that a
> potentially useful tool is parts of TenDRA
> <URL:http://alph.dra.hmg.gb/TenDRA/>.  TenDRA as a practical compiler
> probably isn't interesting---I suspect egcs beats it (although
> compiling with more than one compiler is useful for checking
> portability beyond gcc, of course)---from the point of view of
> checking portability, or checking signature of APIs, TenDRA provides
> some features which look nice, however.
> 
> With the TenDRA compiler, I can compile the etags.c from XEmacs, and
> be pretty sure that it requires only features (as in headers, types,
> macros, functions) provided by ISO C and POSIX:
> 
>         % tcc -Yposix -c etags.c
> 
> Even if the compiler itself is ignored, TenDRA provides a language a
> little more subtle than C header files for specifying what an API
> provides.  For example, you can specify that a struct typedef has
> certain elements, but does not say which order they'll come in (and
> the compiler can check that a program does not try to assume an
> ordering).
> 
> In a sense, perhaps this is too much subtlety for programs to be
> shipped in binary: if my glibc implements some important struct
> differently to yours, then no amount of fiddling is going to get your
> binary to work on my machine.  But for checking (syntactic
> only---there's nothing about semantics involved) portability of
> source, this strikes me as useful.
> 
> Indeed, just writing down (in this already defined language) suitable
> definitions of APIs would surely be handy for a number of uses.  The
> formalism strikes me as a little clearer to read than header files, in
> that it strips out implementation details, making the interface that
> I'm supposed to use more visible.
> 
> Here's a few excerpts for apis/ansi/stdio.h, the definition of what
> ANSI C stdio.h provides:
> 
>         +SUBSET "file" := { +TYPE FILE ; } ;
> 
>         +EXP FILE *stdin, *stdout, *stderr ;
>         +SUBSET "eof" := { +CONST int EOF ; } ;
> 
> This says that FILE is a type, but says nothing else about it.
> Similarly, EOF is a constant int.  The SUBSET things indicate that
> other APIs and other header files may reference these subsets of
> stdio.h without importing the whole lot, I think.
> 
>         +IFNDEF __JUST_POSIX
>         +IFNDEF __JUST_XPG3
>         +TYPE fpos_t ;
>         +FUNC int fgetpos ( FILE *, fpos_t * ) ;
>         +FUNC int fsetpos ( FILE *, const fpos_t * ) ;
>         +ENDIF
>         +FUNC int setvbuf ( FILE *, char *, int, size_t ) ;
>         +FUNC int vfprintf ( FILE *, const char *, ~va_list ) ;
>         +FUNC int vprintf ( const char *, ~va_list ) ;
>         +FUNC int vsprintf ( char *, const char *, ~va_list ) ;
>         +ENDIF
> 
> Declarations of functions.  Fairly obvious, I suspect.  (~va_list is
> declared elsewhere.)
> 
> Does this kind of writing down of APIs strike anybody else as useful,
> or am I just insane?

The concept seems very interesting to me, although I wonder if it is
within the scope of LSB; I had the notion that its effort was concerned
with standardizing existing development approaches.
  On the other hand, however, the above approach as far as I can see
does not address one of my major concerns, namely the fact that in a
library function there is more than the signature. In my experience, the
function semantics is the main source of binary incompatibilities
(scenario: the documentation does not tell me enough for what I want to
do, I make tests or look at the source and develop assumptions about how
it works, write my code in a hurry, then at next release of the library
my assumptions break).
  Does anybody know of attempts to address the semantics of APIs, as
opposed to the syntax ?

listmaster at lists.linuxbase.org

Davide Bolcioni
-- 
#include <disclaimer.h> // Standard disclaimer applies
-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GE/IT d+ s:+ a C+++$ UL++++$ P>++ L++@ E@ W+ N++@ o? K? w O- M+ V?
PS PE@ V+ PGP>+ t++ 5? X R+ tv- b+++ DI? D G e+++ h r y?
------END GEEK CODE BLOCK------



More information about the lsb-discuss mailing list