On Friday 24 March 2006 12:40, tvali wrote: > > Interface can be made somewhat automatically checkable. > > For example: > void a(int); > void b(int, int); > void b(int, char); > > Is compatible with: > void a(int); > void b(int, int); > Unfortunately, your wrong. This only makes sure that you have the right slots to put your squares, triangles and circles in. It does not say that b(int,int) from the first lib actually does the same thing as b(int,int) from the second library.
To make it worse, suppose that header file 1 defines the following macro:
#define c(x,y) { int A = x; int B = y; if (A<B) { b(A,B); } else
{ b(B,A); }
And header file 2 defines the following macro
#define c(x,y) { int A = x; int B = y; if (A>B) { b(A,B); } else
{ b(B,A); }
And the semantics of B are such that one is supposed to use c(x,y) to call
b, and b1 accordingly expects the first argument to be smaller, and b2
expects the second one to be smaller. On the source level, this macro
makes it transparent. The libraries, although they may seem different,
are incompatible. While they implement the same source interface, they do
NOT implement the same binary interface. On a binary (read compiled)
level, they can not be exchanged for eachother.
While the above example is clearly broken design, this does happen enough
in actual libraries in way more subtle ways. And that is disregarding the
fact that the linux/elf ABI does not include argument lists in symbol
linking. As such b(int,char) is indistinguishable from b(int,int). To
overcome this C++ uses name mangling which creates names based on the
signature.
> And this can be checked automatically - real header must have all
> headings that interface describes. Microsoft has actually done good
> work in C# on that topic -- first place where i saw something like
> that after thinking about it myself :) This MS version is feature of a
> language, of course, not a feature of compiler. Anyway, that might
> give an idea.
There is a reason that MS implements it on the language level, in C#. It
is impossible to do while keeping the (admittedly extremely poor)
semantics of C and C++. Unfortunately the linux ABI (Application Binary
Interface) is based on C. As such one has to take C into account.
> I'm actually sure that this all can be calculated up from sourcecode
> and bindep would be after that a check if cpu didnt calculate
> something wrong :P Another question, how difficult it is and is it
> worth the time.
Perhaps you should read up your knowledge of the C language. After you
found that the C language is a mess, try C++, it makes things worse.
After that's finished take a look at solving this problem for ALL
languages.
Automatic source analysis for dependency calculation is a dead end. Even
if you manage to find the proper interfaces (oops, the package had it's
own gl.h instead of using the system one), you don't know anything about
the semantics of those interfaces. Two things with the same name may very
well have very different behaviours.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgp9iE5mTKGuU.pgp
Description: PGP signature
