On Sat, Feb 04, 2006 at 10:57:34PM +0100, Peter N. Lundblad wrote:
> 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.
I don't get it. That situation is NEVER allowed.
You can compile against 1.3 and dynlink against 1.4. But NOT the other
way around.
Going back to your first post, you're talking about the "good"
direction. So am I missing something else? (and yes, your original
suggestion of function-allocates-and-returns seems appropriate)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 5 06:24:31 2006