ABI compatibibility includes that you can upgrade your library
binary without recompiling the application.
Alexander L. Belikoff wrote:
> On Wednesday 15 September 2004 10:10, Garrett Rooney wrote:
>
>>It's not a matter of the structure being passed between the client and
>>server, it's a matter of the definition of the structure existing in our
>>public header files, so it's part of our ABI/API. If a client of the
>>code (someone who links against the libsvn_* libraries) was depending on
>>the size of the structure (which is perfectly valid for them to do,
>>since we put the definition right out in the open like that) they could
>>be broken if we change that size in a new release of the software.
>
>
> Hmm... So far, the only problem that is evident to me is the case when the
> client is written to take advantage of the new structure member and then it
> has to get built with the older revision that doesn't have that member. This
> situation would result in a compile-time error and it is sometimes (like
> now :-) ) a justified case of forward incompatibility.
>
> However, I don't buy the argument about dependency on the size of the
> structure. In most of the API I know, such a dependency is strictly
> compile-time. For example:
>
> 1. My program uses Motif 1.2. It includes Widget.h and makes use of the Widget
> structure (e.g. by building an in-core array of Widget structures). The size
> of the structure is 68 bytes. These structures are being passed to the Motif
> library, which is compiled with the same set of headers and it expects a
> 68-byte structure for a Widget.
>
> 2. I upgrade my Motif environment to 2.x. This one has extended the Widget
> structure by 'int super_id', making it 72 bytes (alignment issues aside). My
> program is recompiled with a 2.x version of Widget.h and is now using 72
> bytes per structure. *NOWHERE* in my program do I make an explicit use of the
> old '68' number - instead, I always use sizeof(Widget). As I link to the 2.x
> version of the library, I pass the 72-byte structures to the routines that
> are compiled with the same version of the Widget and are expecting that kind
> of data.
>
> 3. My peer Joe Schmoe still has Motif 1.2 installed but he decides to be
> clever so he grabs my .o files to save some recompilation time. As he links
> to the 1.2 libraries (assuming the worst case of no unresolved symbols etc.),
> he gets a binary that mysteriously coredumps every now and then. Go figure!
>
> The long winded point here is that the 'client' of the API should treat the
> data structure just for what it is - an opaque data structure provided by the
> API, where the client is being offered just a bunch of members (potentially
> having other hidden members). If the client then builds with the same version
> of API headers as the API libraries, he should be OK (save for the forward
> incompatibility issue outlined in the beginning).
>
> Let me know if I am wrong in my interpretation of svn_keywords_t.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 15 16:51:21 2004