On Mon, Jun 27, 2005 at 10:46:19AM +0100, Steve Hay wrote:
> win32/win32.c currently generates warnings under gcc. The problem is
> reproduced by:
>
> #include <process.h>
> int main() {
> const char *cmdname;
> const char *const *argv;
> return execv(cmdname, (char *const *)argv);
> }
>
> which causes gcc to complain:
>
> test.c:5: warning: passing arg 2 of `execv' from incompatible pointer type
>
> In MinGW (and VC++) execv's 2nd arg is const char *const *, so simply
> removing the cast makes it happy. However, in Borland C execv's 2nd arg
> is just char * const * (hence the reason for the cast in the first place
> -- must have been written by a Borland C user!), so removing the cast
> makes bcc32 complain:
>
> Warning W8075 test.c 5: Suspicious pointer conversion in function main
>
> How can I keep both compilers (gcc and bcc32) happy? Is #ifdef hell the
> only way, e.g.
>
> #ifdef __BORLANDC__
> return execv(cmdname, (char *const *)argv);
> #else
> return execv(cmdname, argv);
> #endif
>
> Why does gcc complain in the first place, though? I thought that
> passing a non const arg to a function with a const parameter was
> generally not a problem, and indeed, VC++ didn't complain. What is
> gcc's problem?
There's discussion of this (that I didn't understand, but maybe you
will) in the SUSv3 execv page, under Rationale, that implies that gcc
is technically correct in having a problem. If you have to resort to
ifdef hell, I'd make it check for mingw, not for __BORLANDC__, since
mingw is what's getting the prototype wrong.
