You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2000/11/29 18:59:36 UTC

Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

On Wed, Nov 29, 2000 at 05:25:01PM -0000, wrowe@locus.apache.org wrote:
> wrowe       00/11/29 09:24:58
> 
>   Added:       src/lib/aputil apu_private.hw
>   Log:
>     Making Win32 build again, one was missed...

Thanks, Bill!

I just made some changes to mpm/winnt/, but couldn't compile them. Since it
was basically just tweaking the types, could you update from CVS and see if
it still compiles properly?

thx!
-g

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

Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:

> On Thu, Nov 30, 2000 at 04:03:13AM -0800, Greg Stein wrote:
> 
>> On Wed, Nov 29, 2000 at 01:55:22PM -0800, William A. Rowe, Jr. wrote:
>> 
>> Euh... those warnings are wrong. We pass in "const char **" for memcpy()'s
>> first parameters which is a "void *". The two "should be" compatible.
>> 
>> Grr... anybody have any ideas on how best to solve the problem? (seems like
>> a problem with the compiler itself)
> 
Probably, yes.

> Ooh... I may know what this is. I changed a few lines that looked like:
> 
>     char const *foo;
> 
> to the standard Apache-style: (hell, everybody's style)
> 
>     const char *foo;
> 
> Do you think that if we put a few of the decls back to the former style,
> that the warnings will go away?

No. The compiler is simply wrong. I suggest the following patch. It 
doesn't cost anything, and gets rid of the warning. An appropriate 
comment wouldn't hurt, either.

Index: apr/misc/unix/getopt.c
===================================================================
RCS file: /home/cvs/apr/misc/unix/getopt.c,v
retrieving revision 1.28
diff -u -p -r1.28 getopt.c
--- apr/misc/unix/getopt.c      2000/11/29 07:41:27     1.28
+++ apr/misc/unix/getopt.c      2000/11/30 20:35:32
@@ -51,6 +51,8 @@ static const char *pretty_path (const ch
 APR_DECLARE(apr_status_t) apr_initopt(apr_getopt_t **os, apr_pool_t *cont,
                                       int argc, const char *const *argv)
 {
+    void *argv_buff;
+
     *os = apr_palloc(cont, sizeof(apr_getopt_t));
     (*os)->cont = cont;
     (*os)->err = 1;
@@ -61,8 +63,9 @@ APR_DECLARE(apr_status_t) apr_initopt(ap
        that's the primary purpose of this function.  But people might
        want to use this function with arrays other than the main argv,
        and we shouldn't touch the caller's data.  So we copy. */
-    (*os)->argv = apr_palloc(cont, (argc + 1) * sizeof(const char *));
-    memcpy((*os)->argv, argv, argc * sizeof(const char *));
+    argv_buff = apr_palloc(cont, (argc + 1) * sizeof(const char *));
+    memcpy(argv_buff, argv, argc * sizeof(const char *));
+    (*os)->argv = argv_buff;
     (*os)->argv[argc] = NULL;

     (*os)->interleave = 0;  


-- 
Brane Čibej
    home:   <br...@xbc.nu>             http://www.xbc.nu/brane/
    work:   <br...@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <br...@acm.org>            http://www.acm.org/



Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:

> On Thu, Nov 30, 2000 at 04:03:13AM -0800, Greg Stein wrote:
> 
>> On Wed, Nov 29, 2000 at 01:55:22PM -0800, William A. Rowe, Jr. wrote:
>> 
>> Euh... those warnings are wrong. We pass in "const char **" for memcpy()'s
>> first parameters which is a "void *". The two "should be" compatible.
>> 
>> Grr... anybody have any ideas on how best to solve the problem? (seems like
>> a problem with the compiler itself)
> 
Probably, yes.

> Ooh... I may know what this is. I changed a few lines that looked like:
> 
>     char const *foo;
> 
> to the standard Apache-style: (hell, everybody's style)
> 
>     const char *foo;
> 
> Do you think that if we put a few of the decls back to the former style,
> that the warnings will go away?

No. The compiler is simply wrong. I suggest the following patch. It 
doesn't cost anything, and gets rid of the warning. An appropriate 
comment wouldn't hurt, either.

Index: apr/misc/unix/getopt.c
===================================================================
RCS file: /home/cvs/apr/misc/unix/getopt.c,v
retrieving revision 1.28
diff -u -p -r1.28 getopt.c
--- apr/misc/unix/getopt.c      2000/11/29 07:41:27     1.28
+++ apr/misc/unix/getopt.c      2000/11/30 20:35:32
@@ -51,6 +51,8 @@ static const char *pretty_path (const ch
 APR_DECLARE(apr_status_t) apr_initopt(apr_getopt_t **os, apr_pool_t *cont,
                                       int argc, const char *const *argv)
 {
+    void *argv_buff;
+
     *os = apr_palloc(cont, sizeof(apr_getopt_t));
     (*os)->cont = cont;
     (*os)->err = 1;
@@ -61,8 +63,9 @@ APR_DECLARE(apr_status_t) apr_initopt(ap
        that's the primary purpose of this function.  But people might
        want to use this function with arrays other than the main argv,
        and we shouldn't touch the caller's data.  So we copy. */
-    (*os)->argv = apr_palloc(cont, (argc + 1) * sizeof(const char *));
-    memcpy((*os)->argv, argv, argc * sizeof(const char *));
+    argv_buff = apr_palloc(cont, (argc + 1) * sizeof(const char *));
+    memcpy(argv_buff, argv, argc * sizeof(const char *));
+    (*os)->argv = argv_buff;
     (*os)->argv[argc] = NULL;

     (*os)->interleave = 0;  


-- 
Brane Čibej
    home:   <br...@xbc.nu>             http://www.xbc.nu/brane/
    work:   <br...@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <br...@acm.org>            http://www.acm.org/



Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Greg Stein" <gs...@lyra.org>
To: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> 
> Try this one. If my guess is right, it will eliminate a few warnings around
> line 600.

Nada - it's compiler problems ... 
 
> Index: service.c
> ===================================================================
> RCS file: /home/cvs/apache-2.0/src/modules/mpm/winnt/service.c,v
> retrieving revision 1.26
> diff -u -r1.26 service.c
> --- service.c   2000/11/29 17:33:03     1.26
> +++ service.c   2000/11/30 18:32:09
> @@ -595,7 +595,7 @@
>       */
>      if (argc > 1) 
>      {
> -        const char **cmb_data;
> +        char const **cmb_data;
>  
>          mpm_new_argv->nalloc = mpm_new_argv->nelts + argc - 1;
>          cmb_data = apr_palloc(mpm_new_argv->cont,
> 
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 


Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 30, 2000 at 09:57:42AM -0800, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <gs...@lyra.org>
> To: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> >
> > Ooh... I may know what this is. I changed a few lines that looked like:
> > 
> >     char const *foo;
> > 
> > to the standard Apache-style: (hell, everybody's style)
> > 
> >     const char *foo;
> > 
> > Do you think that if we put a few of the decls back to the former style,
> > that the warnings will go away?
> 
> Doubt it... I believe the constness tests may be foobared in VC5 (specifically
> VC5... FirstBill - can you compile on VC6 :-?)
> 
> But toss a patch my way and I'll let you know if they do go away.


Try this one. If my guess is right, it will eliminate a few warnings around
line 600.

Index: service.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/modules/mpm/winnt/service.c,v
retrieving revision 1.26
diff -u -r1.26 service.c
--- service.c   2000/11/29 17:33:03     1.26
+++ service.c   2000/11/30 18:32:09
@@ -595,7 +595,7 @@
      */
     if (argc > 1) 
     {
-        const char **cmb_data;
+        char const **cmb_data;
 
         mpm_new_argv->nalloc = mpm_new_argv->nelts + argc - 1;
         cmb_data = apr_palloc(mpm_new_argv->cont,


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

Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 30, 2000 at 04:03:13AM -0800, Greg Stein wrote:
> On Wed, Nov 29, 2000 at 01:55:22PM -0800, William A. Rowe, Jr. wrote:
> >...
> > src\lib\apr\misc\unix\getopt.c(65) : warning C4090: 'function' : different 'const' qualifiers
> > src\lib\apr\misc\unix\getopt.c(65) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1
> > 
> > src\modules\mpm\winnt\service.c(605) : warning C4090: 'function' : different 'const' qualifiers
> > src\modules\mpm\winnt\service.c(605) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1
> > 
> > and ditto at (609), (706), (709), (713) and (1072)
> 
> Euh... those warnings are wrong. We pass in "const char **" for memcpy()'s
> first parameters which is a "void *". The two "should be" compatible.
> 
> Grr... anybody have any ideas on how best to solve the problem? (seems like
> a problem with the compiler itself)

Ooh... I may know what this is. I changed a few lines that looked like:

    char const *foo;

to the standard Apache-style: (hell, everybody's style)

    const char *foo;

Do you think that if we put a few of the decls back to the former style,
that the warnings will go away?

Cheers,
-g

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

Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 30, 2000 at 04:03:13AM -0800, Greg Stein wrote:
> On Wed, Nov 29, 2000 at 01:55:22PM -0800, William A. Rowe, Jr. wrote:
> >...
> > src\lib\apr\misc\unix\getopt.c(65) : warning C4090: 'function' : different 'const' qualifiers
> > src\lib\apr\misc\unix\getopt.c(65) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1
> > 
> > src\modules\mpm\winnt\service.c(605) : warning C4090: 'function' : different 'const' qualifiers
> > src\modules\mpm\winnt\service.c(605) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1
> > 
> > and ditto at (609), (706), (709), (713) and (1072)
> 
> Euh... those warnings are wrong. We pass in "const char **" for memcpy()'s
> first parameters which is a "void *". The two "should be" compatible.
> 
> Grr... anybody have any ideas on how best to solve the problem? (seems like
> a problem with the compiler itself)

Ooh... I may know what this is. I changed a few lines that looked like:

    char const *foo;

to the standard Apache-style: (hell, everybody's style)

    const char *foo;

Do you think that if we put a few of the decls back to the former style,
that the warnings will go away?

Cheers,
-g

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

Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 29, 2000 at 01:55:22PM -0800, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <gs...@lyra.org>
> To: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> 
> > On Wed, Nov 29, 2000 at 11:08:14AM -0800, William A. Rowe, Jr. wrote:
>...
> > > Dirtier than ****, but it -does- compile.  Lots of emits on misparsing the
> > > const (non-recursive const behavior.)  Ohy vey.
> > 
> > I'm not sure that I understand the problem. Is it that MSVC doesn't like
> > seeing two "const" markers in a type?
> 
> src\lib\apr\misc\unix\getopt.c(65) : warning C4090: 'function' : different 'const' qualifiers
> src\lib\apr\misc\unix\getopt.c(65) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1
> 
> src\modules\mpm\winnt\service.c(605) : warning C4090: 'function' : different 'const' qualifiers
> src\modules\mpm\winnt\service.c(605) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1
> 
> and ditto at (609), (706), (709), (713) and (1072)

Euh... those warnings are wrong. We pass in "const char **" for memcpy()'s
first parameters which is a "void *". The two "should be" compatible.

Grr... anybody have any ideas on how best to solve the problem? (seems like
a problem with the compiler itself)

Cheers,
-g

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

Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 29, 2000 at 01:55:22PM -0800, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <gs...@lyra.org>
> To: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> 
> > On Wed, Nov 29, 2000 at 11:08:14AM -0800, William A. Rowe, Jr. wrote:
>...
> > > Dirtier than ****, but it -does- compile.  Lots of emits on misparsing the
> > > const (non-recursive const behavior.)  Ohy vey.
> > 
> > I'm not sure that I understand the problem. Is it that MSVC doesn't like
> > seeing two "const" markers in a type?
> 
> src\lib\apr\misc\unix\getopt.c(65) : warning C4090: 'function' : different 'const' qualifiers
> src\lib\apr\misc\unix\getopt.c(65) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1
> 
> src\modules\mpm\winnt\service.c(605) : warning C4090: 'function' : different 'const' qualifiers
> src\modules\mpm\winnt\service.c(605) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1
> 
> and ditto at (609), (706), (709), (713) and (1072)

Euh... those warnings are wrong. We pass in "const char **" for memcpy()'s
first parameters which is a "void *". The two "should be" compatible.

Grr... anybody have any ideas on how best to solve the problem? (seems like
a problem with the compiler itself)

Cheers,
-g

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

Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Greg Stein" <gs...@lyra.org>
To: "William A. Rowe, Jr." <wr...@rowe-clan.net>


> On Wed, Nov 29, 2000 at 11:08:14AM -0800, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <gs...@lyra.org>
> > To: <ne...@apache.org>
> > 
> > 
> > > I just made some changes to mpm/winnt/, but couldn't compile them. Since it
> > > was basically just tweaking the types, could you update from CVS and see if
> > > it still compiles properly?
> > 
> > Dirtier than ****, but it -does- compile.  Lots of emits on misparsing the
> > const (non-recursive const behavior.)  Ohy vey.
> 
> I'm not sure that I understand the problem. Is it that MSVC doesn't like
> seeing two "const" markers in a type?

src\lib\apr\misc\unix\getopt.c(65) : warning C4090: 'function' : different 'const' qualifiers
src\lib\apr\misc\unix\getopt.c(65) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1

src\modules\mpm\winnt\service.c(605) : warning C4090: 'function' : different 'const' qualifiers
src\modules\mpm\winnt\service.c(605) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1

and ditto at (609), (706), (709), (713) and (1072)

> > Otoh, apr_file_lock broke win32, and I have a few other priorities on the
> > plate today.  I'll get there as I can
> 
> *nod* ... I had some code in mod_dav 1.0 to do the locking on Windows, but
> it used a file descriptor. The apr_file_t structure only had a HANDLE, so I
> wasn't sure where to go with that.

I guessed as much, and will tackle this asap




Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Greg Stein" <gs...@lyra.org>
To: "William A. Rowe, Jr." <wr...@rowe-clan.net>


> On Wed, Nov 29, 2000 at 11:08:14AM -0800, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <gs...@lyra.org>
> > To: <ne...@apache.org>
> > 
> > 
> > > I just made some changes to mpm/winnt/, but couldn't compile them. Since it
> > > was basically just tweaking the types, could you update from CVS and see if
> > > it still compiles properly?
> > 
> > Dirtier than ****, but it -does- compile.  Lots of emits on misparsing the
> > const (non-recursive const behavior.)  Ohy vey.
> 
> I'm not sure that I understand the problem. Is it that MSVC doesn't like
> seeing two "const" markers in a type?

src\lib\apr\misc\unix\getopt.c(65) : warning C4090: 'function' : different 'const' qualifiers
src\lib\apr\misc\unix\getopt.c(65) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1

src\modules\mpm\winnt\service.c(605) : warning C4090: 'function' : different 'const' qualifiers
src\modules\mpm\winnt\service.c(605) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1

and ditto at (609), (706), (709), (713) and (1072)

> > Otoh, apr_file_lock broke win32, and I have a few other priorities on the
> > plate today.  I'll get there as I can
> 
> *nod* ... I had some code in mod_dav 1.0 to do the locking on Windows, but
> it used a file descriptor. The apr_file_t structure only had a HANDLE, so I
> wasn't sure where to go with that.

I guessed as much, and will tackle this asap




Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 29, 2000 at 11:08:14AM -0800, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <gs...@lyra.org>
> To: <ne...@apache.org>
> 
> 
> > I just made some changes to mpm/winnt/, but couldn't compile them. Since it
> > was basically just tweaking the types, could you update from CVS and see if
> > it still compiles properly?
> 
> Dirtier than ****, but it -does- compile.  Lots of emits on misparsing the
> const (non-recursive const behavior.)  Ohy vey.

I'm not sure that I understand the problem. Is it that MSVC doesn't like
seeing two "const" markers in a type?

If you can give an example of "bad" and "good", then I'd be happy to get
stuff changed. And if you want to post the compilation output (or mail
directly to me), then I can clean up anything that doesn't follow the
bad/good pattern of const usage.

> Otoh, apr_file_lock broke win32, and I have a few other priorities on the

*nod* ... I had some code in mod_dav 1.0 to do the locking on Windows, but
it used a file descriptor. The apr_file_t structure only had a HANDLE, so I
wasn't sure where to go with that.

> plate today.  I'll get there as I can

I'll help if you can shoot me the compilation output and/or a good/bad
example.

thx!
-g

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

Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 29, 2000 at 11:08:14AM -0800, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <gs...@lyra.org>
> To: <ne...@apache.org>
> 
> 
> > I just made some changes to mpm/winnt/, but couldn't compile them. Since it
> > was basically just tweaking the types, could you update from CVS and see if
> > it still compiles properly?
> 
> Dirtier than ****, but it -does- compile.  Lots of emits on misparsing the
> const (non-recursive const behavior.)  Ohy vey.

I'm not sure that I understand the problem. Is it that MSVC doesn't like
seeing two "const" markers in a type?

If you can give an example of "bad" and "good", then I'd be happy to get
stuff changed. And if you want to post the compilation output (or mail
directly to me), then I can clean up anything that doesn't follow the
bad/good pattern of const usage.

> Otoh, apr_file_lock broke win32, and I have a few other priorities on the

*nod* ... I had some code in mod_dav 1.0 to do the locking on Windows, but
it used a file descriptor. The apr_file_t structure only had a HANDLE, so I
wasn't sure where to go with that.

> plate today.  I'll get there as I can

I'll help if you can shoot me the compilation output and/or a good/bad
example.

thx!
-g

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

Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Greg Stein" <gs...@lyra.org>
To: <ne...@apache.org>


> I just made some changes to mpm/winnt/, but couldn't compile them. Since it
> was basically just tweaking the types, could you update from CVS and see if
> it still compiles properly?

Dirtier than ****, but it -does- compile.  Lots of emits on misparsing the
const (non-recursive const behavior.)  Ohy vey.

Otoh, apr_file_lock broke win32, and I have a few other priorities on the
plate today.  I'll get there as I can

Bill


Re: cvs commit: apache-2.0/src/lib/aputil apu_private.hw

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Greg Stein" <gs...@lyra.org>
To: <ne...@apache.org>


> I just made some changes to mpm/winnt/, but couldn't compile them. Since it
> was basically just tweaking the types, could you update from CVS and see if
> it still compiles properly?

Dirtier than ****, but it -does- compile.  Lots of emits on misparsing the
const (non-recursive const behavior.)  Ohy vey.

Otoh, apr_file_lock broke win32, and I have a few other priorities on the
plate today.  I'll get there as I can

Bill