[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ABI breakage

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-23 17:22:50 CET

On Mar 23, 2005, at 2:28 AM, Peter N. Lundblad wrote:
> We have to be more precise when defining what we consider breaks the
> ABI.
> Code can always depend on somethings size. One question is: do we
> consider
> it ABI breakage to extend a struct when none of our functions takes it
> as
> input from the caller? For example, would extending
> svn_client_commit_item_t be valid? You may write a program that
> crashes,
> but do we care? (This may apply to adding new values to enums and use
> previously unused bit fields as well.) Yes, this is getting extreme. We
> have to draw the line somewhere.
> Now, back to the actual question at hand. Since we have
> svn_wc_status_dup,
> you may actually be right about svn_wc_status. <sigh!> A user could do:
> svn_wc_status_t stat;
> svn_wc_status_t *newstat = svn_wc_status_dup (&stat, pool);
> So, if we revise this struct and create svn_wc_status2_t, we really
> want
> to document that users must not allocate them by hand - and possibly
> provide an svn_wc_create_status, but I'm not sure who will use it.
> We really need to learn this once and for all. Never allow API users to
> allocate structs by hand. I'll add an svn_lock_create!

So reading this thread, I'm trying to organize a to-do list here. Is
this about right?

    - add svn_lock_create(), make sure it's being used (lundblad)

    - create svn_wc_status2_t() and svn_wc_create_status()

    - ?? create svn_wc_entry2_t() ?? or deliberately not?

    - ?? is it really necessary to cache lock info separately from

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 23 17:24:37 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.