It seems like some serious overhead to force a function call for each and every access to a struct field, especially if it's only so we can adjust those struct fields w/o a corresponding change in the ABI...
> On Feb 15, 2018, at 10:03 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > I've long been in favor of every httpd struct having an exposed _create() > function. It hadn't occurred to me to expose either a _sizeof() or _copy() > accessor, but mod_ftp could use this (until Stefan introduced the idea of run > time server_rec merging.) > > What is the preference? _sizeof() or _copy()? > > > > On Feb 15, 2018 03:42, "Joe Orton" <jor...@redhat.com > <mailto:jor...@redhat.com>> wrote: > On Wed, Feb 07, 2018 at 06:52:28PM +0100, Yann Ylavic wrote: > > On Wed, Feb 7, 2018 at 6:33 PM, Jim Jagielski <j...@jagunet.com > > <mailto:j...@jagunet.com>> wrote: > > > So can I assume that a backport req to bump-up the field sizes to, at > > > least, > > > what is in trunk, would not be vetoed? > > > > Not by me, +1. > > It's not getting a veto from me, but as an FYI I know there is at least > one module (mod_cluster) which breaks when proxy_shared_worker is > extended, because it has some fixed dependency on > sizeof(proxy_shared_worker), e.g. it's used in a memcpy or something. > We saw a similar case with mod_wsgi and sizeof(request_rec) a while ago. > > I think it's always reasonable to extend structs unless we document an > explicit ABI guarantee around *not* doing that, so the third-party > modules have to deal with this. > > Regards, Joe
