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

Re: [API] r18266

From: Greg Stein <gstein_at_lyra.org>
Date: 2006-02-05 06:28:12 CET

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

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.