You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mahadevan R <Ma...@sisl.co.in> on 2003/08/01 05:44:09 UTC

[PATCH] Trivial patch for C++ modules (2.0.47)

Hello All,

While trying to write an Apache2 module in C++, I found that in the 
command table, AP_INIT_TAKE1 has to be used like this:

AP_INIT_TAKE1( "Directive", (cmd_func) drctv_handler, NULL, OR_ALL, 
"help string")

rather than just this:

AP_INIT_TAKE1( "Directive", drctv_handler, NULL, OR_ALL, "help string")

The compiler I'm using (MSVC++ 6.0) does not support "designated 
initializers". Hence
the compiler expects the function drctv_handler to have a signature of
"const char *(*cmd_func) ();" whereas it actually has a signature of
"const char *(*take1) (cmd_parms *parms, void *mconfig, const char *w);".

The situation can be easily solved (worked around?) by changing the 
definition of
AP_INIT_TAKE1 (and its friends) in http_config.h to:

# define AP_INIT_TAKE1(directive, func, mconfig, where, help) \
    { directive, (cmd_func) func, mconfig, where, TAKE1, help }

rather than just:

# define AP_INIT_TAKE1(directive, func, mconfig, where, help) \
    { directive, func, mconfig, where, TAKE1, help }

The attached patch (on 2.0.47) adds this cast into all the AP_* init 
#defines when
the compiler does not have designated initializers.

Please consider this patch for inclusion if you think it is useful.

Regards,
-Mahadevan.



Re: [PATCH] Trivial patch for C++ modules (2.0.47)

Posted by Ben Laurie <be...@algroup.co.uk>.
William A. Rowe, Jr. wrote:

> At 10:44 PM 7/31/2003, Mahadevan R wrote:
> 
> 
>>While trying to write an Apache2 module in C++, I found that in the command table, AP_INIT_TAKE1 has to be used like this:
>>
>>AP_INIT_TAKE1( "Directive", (cmd_func) drctv_handler, NULL, OR_ALL, "help string")
>>
>>The compiler I'm using (MSVC++ 6.0) does not support "designated initializers". Hence
>>the compiler expects the function drctv_handler to have a signature of
>>"const char *(*cmd_func) ();" whereas it actually has a signature of
>>"const char *(*take1) (cmd_parms *parms, void *mconfig, const char *w);".
>>
>>The situation can be easily solved (worked around?) by changing the definition of
>>AP_INIT_TAKE1 (and its friends) in http_config.h to:
>>
>># define AP_INIT_TAKE1(directive, func, mconfig, where, help) \
>>  { directive, (cmd_func) func, mconfig, where, TAKE1, help }
> 
> 
> We have a very strong policy against casts at all costs when it will likely
> mask a developers error.  I would be much more happy to consider a patch
> that introduced specific prototypes for the TAKE1_fn, TAKE12_fn, etc
> function type declarations.

Isn't the point that you can't, because they're unions? So, if you have
designated initialisers, they can be checked, if not, they _have_ to be
cast. From memory.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Re: [PATCH] Trivial patch for C++ modules (2.0.47)

Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 10:44 PM 7/31/2003, Mahadevan R wrote:

>While trying to write an Apache2 module in C++, I found that in the command table, AP_INIT_TAKE1 has to be used like this:
>
>AP_INIT_TAKE1( "Directive", (cmd_func) drctv_handler, NULL, OR_ALL, "help string")
>
>The compiler I'm using (MSVC++ 6.0) does not support "designated initializers". Hence
>the compiler expects the function drctv_handler to have a signature of
>"const char *(*cmd_func) ();" whereas it actually has a signature of
>"const char *(*take1) (cmd_parms *parms, void *mconfig, const char *w);".
>
>The situation can be easily solved (worked around?) by changing the definition of
>AP_INIT_TAKE1 (and its friends) in http_config.h to:
>
># define AP_INIT_TAKE1(directive, func, mconfig, where, help) \
>   { directive, (cmd_func) func, mconfig, where, TAKE1, help }

We have a very strong policy against casts at all costs when it will likely
mask a developers error.  I would be much more happy to consider a patch
that introduced specific prototypes for the TAKE1_fn, TAKE12_fn, etc
function type declarations.

Bill