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
entry_t?
---------------------------------------------------------------------
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