Quick Question: module structure initialization

["Ralf S. Engelschall" <rs...@engelschall.com>]

Just a quick question:

Is it correct that ANSI C _guarantees_ C compilers initialize missing entries
(at the end) in structure initializations like our "module" structure to
0/NULL?

In other words: Is it safe when I add (inside the mod_ssl patch) two more hook
pointers to the "module" structure definition in http_config.h but the module
sources contain no explicit additional NULLs in their initialization of the
"module" structure?

I hope this is the case because else it would be not possible to extend the
set of hooks without requireing third party modules to change their structure,
too. But NULLs for the additional hooks are needed or the stuff would
segfault...
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Re: Quick Question: module structure initialization

[Eric Prud'hommeaux <er...@w3.org>]

On Sun, 25 Oct 1998, Marc Slemko wrote:

> On Sat, 24 Oct 1998, Eric Prud'hommeaux wrote:
> 
> > On Sat, 24 Oct 1998, Ralf S. Engelschall wrote:
> > 
> > > 
> > > Just a quick question:
> > > 
> > > Is it correct that ANSI C _guarantees_ C compilers initialize missing entries
> > > (at the end) in structure initializations like our "module" structure to
> > > 0/NULL?
> > > 
> > > In other words: Is it safe when I add (inside the mod_ssl patch) two more hook
> > > pointers to the "module" structure definition in http_config.h but the module
> > > sources contain no explicit additional NULLs in their initialization of the
> > > "module" structure?
> > > 
> > > I hope this is the case because else it would be not possible to extend the
> > > set of hooks without requireing third party modules to change their structure,
> > > too. But NULLs for the additional hooks are needed or the stuff would
> > > segfault...
> > 
> > Could this be handled in the future (2.0) by having a macro that went into
> > the end of the module declaration?
> 
> While I don't really know that this is a huge issue (since they are NULL
> if they aren't there), it does make it look a little ugly with various
> handlers tacked on the end.

I was looking for a non intrusive (not patch based) way to insure the
length of the static module structure. If a mechanism is needed to store
extra info at a specific offset in everyone's modules, then this space
needs to be pre-allocated at compile time.  While a patch to http_config.h
may work for one such extension, there will be collisions it two
extensions attempt to reserve space at specific offsets in the module
structure.

> What you suggest could be one way to deal with it, perhaps with a few
> modifications.  But the thing that would have to be decided first is if we
> even want to keep up with the (exposed) module structure idea; in a lot of
> ways it would be cleaner to just make modules register their phases with
> explicit function calls.  Internally it could be implemented the same, but
> the struct isn't visable any longer then.

If folks favor an ephemoral module interface, it may be better to malloc
the structure once it's size is known, or have an interface like this:

static table ap_xtraModuleStuff;

ap_put (module * pModule, char * key, void * value);
ap_get (module * pModule, char * key);

but I preffer the more direct approach because you don't have to worry
about allocations stored in the void *.

-eric

Re: Quick Question: module structure initialization

[Marc Slemko <ma...@znep.com>]

On Sat, 24 Oct 1998, Eric Prud'hommeaux wrote:

> On Sat, 24 Oct 1998, Ralf S. Engelschall wrote:
> 
> > 
> > Just a quick question:
> > 
> > Is it correct that ANSI C _guarantees_ C compilers initialize missing entries
> > (at the end) in structure initializations like our "module" structure to
> > 0/NULL?
> > 
> > In other words: Is it safe when I add (inside the mod_ssl patch) two more hook
> > pointers to the "module" structure definition in http_config.h but the module
> > sources contain no explicit additional NULLs in their initialization of the
> > "module" structure?
> > 
> > I hope this is the case because else it would be not possible to extend the
> > set of hooks without requireing third party modules to change their structure,
> > too. But NULLs for the additional hooks are needed or the stuff would
> > segfault...
> 
> Could this be handled in the future (2.0) by having a macro that went into
> the end of the module declaration?

While I don't really know that this is a huge issue (since they are NULL
if they aren't there), it does make it look a little ugly with various
handlers tacked on the end.

What you suggest could be one way to deal with it, perhaps with a few
modifications.  But the thing that would have to be decided first is if we
even want to keep up with the (exposed) module structure idea; in a lot of
ways it would be cleaner to just make modules register their phases with
explicit function calls.  Internally it could be implemented the same, but
the struct isn't visable any longer then.

Re: Quick Question: module structure initialization

[Eric Prud'hommeaux <er...@w3.org>]

On Sat, 24 Oct 1998, Ralf S. Engelschall wrote:

> 
> Just a quick question:
> 
> Is it correct that ANSI C _guarantees_ C compilers initialize missing entries
> (at the end) in structure initializations like our "module" structure to
> 0/NULL?
> 
> In other words: Is it safe when I add (inside the mod_ssl patch) two more hook
> pointers to the "module" structure definition in http_config.h but the module
> sources contain no explicit additional NULLs in their initialization of the
> "module" structure?
> 
> I hope this is the case because else it would be not possible to extend the
> set of hooks without requireing third party modules to change their structure,
> too. But NULLs for the additional hooks are needed or the stuff would
> segfault...

Could this be handled in the future (2.0) by having a macro that went into
the end of the module declaration?

proposal:
. modules declare extra variables in <module>.conf.
. extra variables are prefixed with module name.
. some config script reads <module>.conf and generates STANDARD_MODULE_END.
. all modules are expected to include STANDARD_MODULE_END at the end of
  their module definition.

example:
module1.conf:
int module1_someInt
char * module1_someCharPtr

module2.conf:
int module2_someOtherInt = 5

produces:
#define MODULE_EXTRA_STUFF \
int module1_someInt, \
char * module1_someCharPtr, \
int module2_someOtherInt = 5, \
char ap_sacrificialByteToMakeSureTherezNoCommaAtTheEnd

used in each module decl:
module myModule {
...
MODULE_END_STUFF
}

-eric

PS. I didn't grep the 2.0 code for name collisions on ap_sacrifi...