You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Tony Finch <do...@dotat.at> on 2001/01/18 22:39:28 UTC

module declaration inconsistencies

We aren't declaring module structures consistently in 1.3 or in 2.0
(see PR#7095 for one example of many).

AIUI the correct way in 1.3 is
	module MODULE_VAR_EXPORT foo_module;
and in 2.0 it is
	module AP_DECLARE_DATA foo_module;
with no caveats.

I'll fix later unless someone pops up with a problem.

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
"Then they attacked a town. A small town, I'll admit.
But nevertheless a town of people. People who died."

RE: module declaration inconsistencies

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> So AP_DECLARE_DATA, which seems to be used by most modules, is wrong?

If it's not linked to the core?  Yes.  It's acceptable in the following,
although it doesn't make much difference since the linker 'sees' them
without any extra help:

  &core_module,
  &mpm_winnt_module,
  &so_module,
  &mime_module,
  &access_module,
  &auth_module,
  &negotiation_module,
  &includes_module,
  &autoindex_module,
  &dir_module,
  &cgi_module,
  &userdir_module,
  &alias_module,
  &env_module,
  &config_log_module,
  &asis_module,
  &imap_module,
  &action_module,
  &setenvif_module,
  &isapi_module,

> Another question before I have a go at 1.3, should core_module be
> API_VAR_EXPORT or MODULE_VAR_EXPORT? It doesn't make a practical
> difference; I'm just wondering wehat the semantics are in this case.

Correct, no difference.  I'd suggest MODULE_VAR_EXPORT is possibly
clearer in any case, unless we actually mean to 'import' a module
symbol.  I don't believe we ever do so.

Re: module declaration inconsistencies

Posted by Tony Finch <do...@dotat.at>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>But tagging the imported modules as AP_DECLARE_DATA would be
>very bad, since that would tell the compiler (which is linking
>-into- libhttpd.dll) that all those are imports, not exports.
>And you cannot define an 'imported' symbol (or why the heck
>would you be importing it, anyways.)

So AP_DECLARE_DATA, which seems to be used by most modules, is wrong?

Another question before I have a go at 1.3, should core_module be
API_VAR_EXPORT or MODULE_VAR_EXPORT? It doesn't make a practical
difference; I'm just wondering wehat the semantics are in this case.

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
"Well, as long as they can think we'll have our problems.
But those whom we're using cannot think."

Re: module declaration inconsistencies

Posted by Greg Stein <gs...@lyra.org>.
Careful: I belive the DAV one is special. Ask OtherBill before tweaking.

(it may be that dav_module should be AP_DECLARE_DATA and *other* mod_dav
 data should use the DAV_DECLARE_DATA macro; not sure, so OtherBill should
 comment)

Cheers,
-g

On Thu, Jan 18, 2001 at 10:12:36PM +0000, Tony Finch wrote:
> rbb@covalent.net wrote:
> >
> >Where is the problem here?  The change in 2.0 was done to make things
> >easier and correct for Windows.
> 
> The problem is that not all modules are declared with the magic runes.
> 
> module db_auth_module;
> module DAV_DECLARE_DATA dav_module =
> module MODULE_VAR_EXPORT cache_module;
> module case_filter_module;
> module charset_lite_module;
> module MODULE_VAR_EXPORT disk_cache_module;
> module example_module;
> module ext_filter_module;
> module includes_module;
> module MODULE_VAR_EXPORT suexec_module;
> module action_module;
> module userdir_module;
> module mime_magic_module;
> module rndchunk_module = {
> module test_util_uri_module = {
> module isapi_module;
> AP_DECLARE_DATA module core_module = {
> 
> Tony.
> -- 
> f.a.n.finch    fanf@covalent.net    dot@dotat.at
> "Perhaps on your way home you will pass someone in the dark,
> and you will never know it, for they will be from outer space."

-- 
Greg Stein, http://www.lyra.org/

Re: module declaration inconsistencies

Posted by rb...@covalent.net.

Ahhhh.  I thought you were complaining about the different syntax for 1.3
and 2.0.

+1

Ryan

On Thu, 18 Jan 2001, Tony Finch wrote:

> rbb@covalent.net wrote:
> >
> >Where is the problem here?  The change in 2.0 was done to make things
> >easier and correct for Windows.
> 
> The problem is that not all modules are declared with the magic runes.
> 
> module db_auth_module;
> module DAV_DECLARE_DATA dav_module =
> module MODULE_VAR_EXPORT cache_module;
> module case_filter_module;
> module charset_lite_module;
> module MODULE_VAR_EXPORT disk_cache_module;
> module example_module;
> module ext_filter_module;
> module includes_module;
> module MODULE_VAR_EXPORT suexec_module;
> module action_module;
> module userdir_module;
> module mime_magic_module;
> module rndchunk_module = {
> module test_util_uri_module = {
> module isapi_module;
> AP_DECLARE_DATA module core_module = {
> 
> Tony.
> -- 
> f.a.n.finch    fanf@covalent.net    dot@dotat.at
> "Perhaps on your way home you will pass someone in the dark,
> and you will never know it, for they will be from outer space."
> 
> 


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


RE: module declaration inconsistencies

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Tony Finch [mailto:dot@dotat.at]
> Sent: Thursday, January 18, 2001 4:13 PM
> 
> rbb@covalent.net wrote:
> >
> >Where is the problem here?  The change in 2.0 was done to make things
> >easier and correct for Windows.
> 
> The problem is that not all modules are declared with the magic runes.
> 
> module db_auth_module;
> module DAV_DECLARE_DATA dav_module =
> module MODULE_VAR_EXPORT cache_module;
> module case_filter_module;
> module charset_lite_module;
> module MODULE_VAR_EXPORT disk_cache_module;
> module example_module;
> module ext_filter_module;
> module includes_module;
> module MODULE_VAR_EXPORT suexec_module;
> module action_module;
> module userdir_module;
> module mime_magic_module;
> module rndchunk_module = {
> module test_util_uri_module = {
> module isapi_module;
> AP_DECLARE_DATA module core_module = {

Almost every one of these is correct.

It is pointless (unless you see some reason I do not) to
export a load point for a module linked into the libhttpd.dll
core.  The DAV exception is also quite correct, since DAV
had to grow it's own export dynamics since it is -imported-
by DAV modules (such as dav_fs, dav_syn etc.)

And the MODULE_VAR_EXPORT (prefixed by AP_, which I will add)
is a universal export-always tag, that doesn't care if you
trip flags.

But tagging the imported modules as AP_DECLARE_DATA would be
very bad, since that would tell the compiler (which is linking
-into- libhttpd.dll) that all those are imports, not exports.
And you cannot define an 'imported' symbol (or why the heck
would you be importing it, anyways.)

I'll have a fix later tonight, I'm going through APU_ symbols
right now so I should be caught up to httpd by about 9pm.

Bill


Re: module declaration inconsistencies

Posted by Tony Finch <do...@dotat.at>.
rbb@covalent.net wrote:
>
>Where is the problem here?  The change in 2.0 was done to make things
>easier and correct for Windows.

The problem is that not all modules are declared with the magic runes.

module db_auth_module;
module DAV_DECLARE_DATA dav_module =
module MODULE_VAR_EXPORT cache_module;
module case_filter_module;
module charset_lite_module;
module MODULE_VAR_EXPORT disk_cache_module;
module example_module;
module ext_filter_module;
module includes_module;
module MODULE_VAR_EXPORT suexec_module;
module action_module;
module userdir_module;
module mime_magic_module;
module rndchunk_module = {
module test_util_uri_module = {
module isapi_module;
AP_DECLARE_DATA module core_module = {

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
"Perhaps on your way home you will pass someone in the dark,
and you will never know it, for they will be from outer space."

Re: module declaration inconsistencies

Posted by rb...@covalent.net.
Where is the problem here?  The change in 2.0 was done to make things
easier and correct for Windows.

Ryan

On Thu, 18 Jan 2001, Tony Finch wrote:

> 
> We aren't declaring module structures consistently in 1.3 or in 2.0
> (see PR#7095 for one example of many).
> 
> AIUI the correct way in 1.3 is
> 	module MODULE_VAR_EXPORT foo_module;
> and in 2.0 it is
> 	module AP_DECLARE_DATA foo_module;
> with no caveats.
> 
> I'll fix later unless someone pops up with a problem.
> 
> Tony.
> -- 
> f.a.n.finch    fanf@covalent.net    dot@dotat.at
> "Then they attacked a town. A small town, I'll admit.
> But nevertheless a town of people. People who died."
> 
> 


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------