[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-02-05 13:03:52 CET

On Sat, 4 Feb 2006, Greg Stein wrote:

> 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.
>
Then *we* agree... maxb doesn't seem to. It's him you should argue with,
not me:-)

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 5 13:04:42 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.