On Sat, 4 Feb 2006, Greg Stein wrote:
> On Sat, Feb 04, 2006 at 10:31:55PM +0100, Peter N. Lundblad wrote:
> >...
> > Hrm!?! Some time ago, I revised the notification API to use a struct
> > instead of lots of parameters just so we could add more in the future if
>
> For a notification API, you're the only one allocating the structure.
> Stating a contract that a client shouldn't allocate it is fine. If a
> structure needs to be alloc'd by a client, then a factory function is
> best (per my previous email).
>
We're discussing forwards-compatibility here, i.e. compiling against 1.4
and dynamically linking against an 1.3 library. If we'd support that, we'd
not allow extension of structures (or enums in some situations) because
the caller would read beyond the returned struct.
> > needed. The reason was to add some field when we implemented locking. If
> > you call that a "little API revving", then go look for that diff...
> >
> > Also, what about our version check macros? Don't they protect applications
> > from such badness?
>
> If the client uses them, then they can help. But they protect against
> going backwards in time, or major revision changes. Increasing minor
> revs are fine, so if you change a struct size across a minor rev, then
> the check macros aren't going to say anything (since that is defined
> as a legal version change).
That's clear. That's why client-allocatable structs are bad, bad, bad.
Thanks,
//P
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 4 22:58:27 2006