--On Tuesday, April 12, 2005 5:03 PM -0400 Garrett Rooney
<rooneg@electricjellyfish.net> wrote:
> Yes, it would require a new structure, which means reving each and every
> function that returns an svn_error_t. Fun. The issue isn't that you're
> adding an API, its that you're changing the ABI for that structure by
> increasing its size, which is part of its ABI by virtue of the fact that
> it's publicly declared in our header files. In some special cases we
> document that the size is not part of the ABI (svn_client_ctx_t for
> example), but I don't think we did that for svn_error_t.
>
> That said, the common case is to create svn_error_t's via our constructor
> functions, and I can't think of a good reason someone would be depending
> on the size, but it is technically a violation of our compat policy.
I really don't think adding a field to the end of the structure violates
our compatibility policy. So, this doesn't warrant bumping the structure
number. No one is likely to be allocating it themselves (as we provide it)
and we only return a pointer to the svn_error_t not the structure itself.
I don't envisioning any applications breaking here if we add a field in a
minor release.
> And yes, for what it's worth, I think in 2.0 we should just do away with
> publicly declared structures entirely, it's just not worth the pain when
> we finally do need to rev them. Even pulling the "the size can change!"
Yah, this is why APR uses opaque structures for almost everything. We
learned this lesson over the years. httpd still has a lot of open
structures though.
> card isn't really good enough, since I've already seen at least one
> example on the users list where someone went right past the note on
> svn_client_ctx_t about using the constructor function and allocated it on
> the stack themselves instead.
They deserve broken code. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 13 20:28:57 2005