1 |
On Friday 24 March 2006 12:40, tvali wrote: |
2 |
> |
3 |
> Interface can be made somewhat automatically checkable. |
4 |
> |
5 |
> For example: |
6 |
> void a(int); |
7 |
> void b(int, int); |
8 |
> void b(int, char); |
9 |
> |
10 |
> Is compatible with: |
11 |
> void a(int); |
12 |
> void b(int, int); |
13 |
> |
14 |
Unfortunately, your wrong. This only makes sure that you have the right |
15 |
slots to put your squares, triangles and circles in. It does not say that |
16 |
b(int,int) from the first lib actually does the same thing as b(int,int) |
17 |
from the second library. |
18 |
|
19 |
To make it worse, suppose that header file 1 defines the following macro: |
20 |
#define c(x,y) { int A = x; int B = y; if (A<B) { b(A,B); } else |
21 |
{ b(B,A); } |
22 |
|
23 |
And header file 2 defines the following macro |
24 |
#define c(x,y) { int A = x; int B = y; if (A>B) { b(A,B); } else |
25 |
{ b(B,A); } |
26 |
|
27 |
And the semantics of B are such that one is supposed to use c(x,y) to call |
28 |
b, and b1 accordingly expects the first argument to be smaller, and b2 |
29 |
expects the second one to be smaller. On the source level, this macro |
30 |
makes it transparent. The libraries, although they may seem different, |
31 |
are incompatible. While they implement the same source interface, they do |
32 |
NOT implement the same binary interface. On a binary (read compiled) |
33 |
level, they can not be exchanged for eachother. |
34 |
|
35 |
While the above example is clearly broken design, this does happen enough |
36 |
in actual libraries in way more subtle ways. And that is disregarding the |
37 |
fact that the linux/elf ABI does not include argument lists in symbol |
38 |
linking. As such b(int,char) is indistinguishable from b(int,int). To |
39 |
overcome this C++ uses name mangling which creates names based on the |
40 |
signature. |
41 |
|
42 |
> And this can be checked automatically - real header must have all |
43 |
> headings that interface describes. Microsoft has actually done good |
44 |
> work in C# on that topic -- first place where i saw something like |
45 |
> that after thinking about it myself :) This MS version is feature of a |
46 |
> language, of course, not a feature of compiler. Anyway, that might |
47 |
> give an idea. |
48 |
|
49 |
There is a reason that MS implements it on the language level, in C#. It |
50 |
is impossible to do while keeping the (admittedly extremely poor) |
51 |
semantics of C and C++. Unfortunately the linux ABI (Application Binary |
52 |
Interface) is based on C. As such one has to take C into account. |
53 |
|
54 |
> I'm actually sure that this all can be calculated up from sourcecode |
55 |
> and bindep would be after that a check if cpu didnt calculate |
56 |
> something wrong :P Another question, how difficult it is and is it |
57 |
> worth the time. |
58 |
|
59 |
Perhaps you should read up your knowledge of the C language. After you |
60 |
found that the C language is a mess, try C++, it makes things worse. |
61 |
After that's finished take a look at solving this problem for ALL |
62 |
languages. |
63 |
|
64 |
Automatic source analysis for dependency calculation is a dead end. Even |
65 |
if you manage to find the proper interfaces (oops, the package had it's |
66 |
own gl.h instead of using the system one), you don't know anything about |
67 |
the semantics of those interfaces. Two things with the same name may very |
68 |
well have very different behaviours. |
69 |
|
70 |
Paul |
71 |
|
72 |
-- |
73 |
Paul de Vrieze |
74 |
Gentoo Developer |
75 |
Mail: pauldv@g.o |
76 |
Homepage: http://www.devrieze.net |