On Tue, Feb 20, 2018 at 9:39 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Tue, Feb 20, 2018 at 2:24 PM, Ruediger Pluem <rpl...@apache.org> wrote: >> >> 1. We continue as we do now and allow extending structures at the end. We >> should probably document more prominently that >> copying / allocating / creating public structures is not allowed and if done >> can require minor version specific recompiling. > [] > > The proposed mod_dav case is worse yet. If we accept that the > API demands the submodule pass the struct to mod_dav, there > is no way to distinguish what is going on, and whether this module > was written for 2.4.27 or 2.4.33. Worse 2x yet, we guaranteed that > no source code revision would be required during 2.4.x.
The issue is that there is nothing we can do for the mod_dav case (besides not extending the struct at all). Neither _sizeof nor _copy would address that, if a module struct compounds an ap_xxx_rec something anywhere but at the end then bets are off (not to talk about this struct being used as a persised file record). How to statically define such a struct when _sizeof() is a function? Offsets make using less friendly to use at runtime too... We possibly need to exclude compound structs from our ABI garantees. > >> 2. We stop allowing extending structures at the end on stable branches. > > I don't think that is realistic. Adding a new member with an acceptable > NULL/unknown purpose, and adding 3) as noted below, should > generally solve for the case of "module which must be recompiled > on each release". I hope we won't do 2., or we may need to release a major version quite often (which wouldn't help module authors either). > >> 3. Like 1., but we add _sizeof / _copy functions for each public struct as >> discussed in the other thread, make the >> existence of the functions mandatory for every new public struct and advice >> module authors that they need to leverage >> them if the want to copy / allocate / create these structures in their >> modules. >> >> We can do 1., 2. or 3. now or set this as the rule for the next major >> release. > > The advantage to _sizeof/_copy and enforcing the "new member > default must be ok-to-be-NULL" rule means that mod_cluster, > mod_ftp, mod_wsgi and many many other edge-case modules > don't need to be recompiled. This situation can be dramatically > improved in 2.next/3.0. Ensuring _create() accessors are always > provided and demanded to initialize everything that shouldn't > default to NULL is the 100% solve. I'm fine with 1 and 3, and would like that we don't guarantee ABI stability for compound structs or persisted files with our structs as record, such constructions should use 3. with runtime tricks (in the first place, IMHO). This probably does not apply to 2.4.x (as a strong statement), in the meantime we at least need the helpers and give a hand at updating the modules, if we can't avoid extending our own structs... Regards, Yann.
