Re: MinGW port

[Ken Raeburn]

On Sep 9, 2006, at 14:14, Nils Durner wrote:
> Hi,
>
> first of all, sorry for the late reply.
>
> > > - execv (exec_file, exec_argv);
> > > + execv (exec_file,
> > > +#ifdef __MINGW32__
> > > + (const char * const *)
> > > +#endif
> > > + exec_argv);

Is the execv declaration (in some header file) part of mingw, or  
Windows?

The SUSv2 spec (http://opengroup.org/onlinepubs/007908799/xsh/ 
exec.html) and the POSIX.1 2004 spec (http://www.opengroup.org/ 
onlinepubs/000095399/functions/exec.html) say "char *const argv[]",  
i.e., no "const" qualifier on the character data.  So does the Mac OS  
X man page I just pulled up, and the Linux (GNU libc) one.  Sounds  
like Windows/Mingw is the odd one out -- and, one could argue, wrong.

> > Thanks for the patch, but do you understand exactly what the
> > Win32/MinGW compiler is complaining about?
> No, I don't.
> IMHO, gcc treats "const char *const *" wrong.

It treats it consistently with the ANSI C standard.  A "char **"  
value can't be assigned to a "const char * const *" lvalue without  
explicit conversion.  You can add qualifiers at the first level of  
indirection only.

There's a weird broken case you can construct if you allow that, but  
I forget the details.  I think it was something like:

void function1 () {
  char **stringarray = calloc(10, sizeof(char*));
  function2 (stringarray); // invalid
  stringarray[0][0] = 0;
}
void function2 (const char **ptr) {
  static const char x[] = { /*...*/ };
  ptr[0] = x;
}

Now, if you allow the call to function2 without casting, this code  
would have no type errors but the assignment at the end of function1  
would be writing into storage defined as const.  (String literals  
introduce some similar unfortunate lossage, when they're treated as  
"char*" values, but that's a known issue, and not what's happening  
here.)

The C++ rules are more complicated, and allow adding qualifiers at  
different levels of indirection, but with other restrictions that  
still prevent this sort of thing from happening.

> > I thought it was generally
> > OK to pass a non-const value to a function whose corresponding
> > parameter is declared as const.
> Right.

First level of indirection only.  Same for "volatile".

> The sample code for execv() at
>
> http://msdn.microsoft.com/library/en-us/vccore98/HTML/_crt__execv. 
> 2c_._wexecv.asp
> triggers the same warning with GCC.
> I have no access to a Visual C compiler ATM, but I doubt MS' sample  
> code
> causes warnings with their compiler.

That's for a function "_execv".  Is "execv" also defined by MS- 
provided headers?  By mingw?  By Guile?  If execv is defined as a  
macro expanding to _execv, perhaps it should be casting its  
argument's type.

Ken