[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MinGW port
From: |
Ken Raeburn |
Subject: |
Re: MinGW port |
Date: |
Mon, 11 Sep 2006 20:56:27 -0400 |
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