From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.bugs Subject: Re: MinGW port Date: Mon, 11 Sep 2006 20:56:27 -0400 Message-ID: References: <44EB33E7.2010507@web.de> <87lkoz8ea5.fsf@ossau.uklinux.net> <4503047A.7080403@web.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1158086578 5782 80.91.229.2 (12 Sep 2006 18:42:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 12 Sep 2006 18:42:58 +0000 (UTC) Cc: bug-guile@gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue Sep 12 20:42:56 2006 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GNDDc-0001ko-8U for guile-bugs@m.gmane.org; Tue, 12 Sep 2006 20:42:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GNDDb-0001M1-Pp for guile-bugs@m.gmane.org; Tue, 12 Sep 2006 14:42:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GMwc4-0003VT-Du for bug-guile@gnu.org; Mon, 11 Sep 2006 20:58:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GMwc3-0003UC-JT for bug-guile@gnu.org; Mon, 11 Sep 2006 20:58:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMwc3-0003Tw-FM for bug-guile@gnu.org; Mon, 11 Sep 2006 20:58:55 -0400 Original-Received: from [206.18.177.53] (helo=alnrmhc11.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GMwdR-0004VX-5X for bug-guile@gnu.org; Mon, 11 Sep 2006 21:00:21 -0400 Original-Received: from raeburn.org (c-65-96-168-237.hsd1.ma.comcast.net[65.96.168.237]) by comcast.net (alnrmhc13) with ESMTP id <20060912005704b13003agh4e>; Tue, 12 Sep 2006 00:57:04 +0000 Original-Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) by raeburn.org (8.12.11/8.12.11) with ESMTP id k8C0v3M8023365; Mon, 11 Sep 2006 20:57:03 -0400 (EDT) In-Reply-To: <4503047A.7080403@web.de> Original-To: Nils Durner X-Mailer: Apple Mail (2.752.2) X-Mailman-Approved-At: Tue, 12 Sep 2006 14:42:21 -0400 X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:3345 Archived-At: 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 _______________________________________________ Bug-guile mailing list Bug-guile@gnu.org http://lists.gnu.org/mailman/listinfo/bug-guile