On Thu, Feb 15, 2018 at 12:26 PM, Jim Jagielski <[email protected]> wrote:
> 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...
Why would you do that?
The only modules who would call these functions would be those making
a duplicate of the entire structure.
Why does this happen? mod_cluster rearranges shm slots, I'm guessing.
mod_ftp took a completely generic server_rec, duplicated it, then
changed the value of the document_root member, and seeded new
request_rec structures in response to ftp commands. There are many
examples of why a _create() accessor is a good thing for module
developers, but it's not impossible to imagine these modules having a
need to make _copy() of one of our structures.
However we solve, the function template could be macroized, e.g.
#define AP_DECLARE_STRUCT_ACCESSORS(stype) \
AP_DECLARE(struct stype *) ap_##stype##_palloc(apr_pool_t *p); \
AP_DECLARE(apr_size_t) ap_##stype##_sizeof(); \
AP_DECLARE(void) ap_##stype##_copy(struct stype *new, struct stype *orig);
#define AP_IMPLEMENT_STRUCT_ACCESSORS(stype) \
AP_DECLARE(struct stype *) ap_##stype##_palloc(apr_pool_t *p) \
{ return apr_pcalloc(p, sizeof(struct stype)); } \
AP_DECLARE(apr_size_t) ap_##stype##_sizeof() \
{ return sizeof(new); } \
AP_DECLARE(void) ap_##stype##_copy(struct stype *new, struct stype *orig) \
{ return memcpy(new, orig, sizeof(struct stype)); }
The apr_stype_create() call has a whole lot more decorative things to
do by default, and can't really be macroized, but should be split as
necessary into context-free default initialization (ap_stype_create)
and the current phase-specific core logic (e.g. most of
core_create_conn as implemented today.)
