On Mon, Feb 19, 2018 at 08:38:05PM +0100, Ruediger Pluem wrote:
> On 02/19/2018 07:50 PM, Joe Orton wrote:
> > On Sat, Feb 17, 2018 at 02:06:20PM -0000, minf...@apache.org wrote:
> >> Author: minfrin
> >> Date: Sat Feb 17 14:06:20 2018
> >> New Revision: 1824592
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1824592&view=rev
> >> Log:
> >> Update proposal with fix for rpluem/jorton.
> >
> > Extending dav_resource still breaks binary backards compat with all(?)
> > consumers of this API, or am I missing something here?
>
> I don't think so. Modules that just work with pointers to structs created by
> mod_dav shouldn't
> have any issues, but see below.
Looking again, I think the way the mod_dav API is designed does make it
necessary for consumers of the API to allocate dav_resource structures.
There are a number of hooks like ->get_resource():
dav_error * (*get_resource)(
request_rec *r,
const char *root_dir,
const char *label,
int use_checked_in,
dav_resource **resource
);
... which are implemented in repos providers which must allocate that
*resource, and hence changing sizeof(dav_resource) will break binary BC,
even if the structure was not embedded anywhere.
> > Look at what mod_dav_svn does with the struct for an example:
> > https://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/repos.c?view=markup#l80
>
> I guess this gets us back to this _copy / _sizeof discussion we had in
> another thread recently.
> Creating structures / allocating memory for them in modules is IMHO a recipe
> to fail with our current
> backporting policy as we allow to extend structures at the end.
Yup.
In this case would moving ->acls and ->ctx to a pool note of the ->pool
field (actually is ->ctx actually used??) might work to preserve BC?
Regards, Joe
