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.
--
Alexander L. Belikoff
PGP/GPG fingerprint: 0D58 A804 1AB1 4CD8 8DA9 424B A86E CD0D 8424 2701
(http://pgp5.ai.mit.edu for the key)
---------------------------------------------------------------------
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:33:36 2004