MinGW port

MinGW port

[Nils Durner]

[-- Attachment #1: Type: text/plain, Size: 82 bytes --]

Hi,

the attached patch fixes compiler errors on Win32/MinGW.

Best,

Nils Durner

[-- Attachment #2: guile-mingw.diff --]
[-- Type: text/plain, Size: 1117 bytes --]

diff -Naur guile-core/libguile/posix.c guile-core.nd/libguile/posix.c
--- guile-core/libguile/posix.c	Sun Jun 18 00:05:46 2006
+++ guile-core.nd/libguile/posix.c	Tue Aug 22 13:42:17 2006
@@ -942,7 +942,11 @@
   scm_dynwind_unwind_handler (free_string_pointers, exec_argv, 
 			    SCM_F_WIND_EXPLICITLY);
 
-  execv (exec_file, exec_argv);
+  execv (exec_file,
+#ifdef __MINGW32__
+	(const char * const *)
+#endif
+	exec_argv);
   SCM_SYSERROR;
 
   /* not reached.  */
@@ -973,7 +977,11 @@
   scm_dynwind_unwind_handler (free_string_pointers, exec_argv, 
 			    SCM_F_WIND_EXPLICITLY);
 
-  execvp (exec_file, exec_argv);
+  execvp (exec_file,
+#ifdef __MINGW32__
+	(const char * const *)
+#endif
+	exec_argv);
   SCM_SYSERROR;
 
   /* not reached.  */
@@ -1012,7 +1020,15 @@
   scm_dynwind_unwind_handler (free_string_pointers, exec_env,
 			    SCM_F_WIND_EXPLICITLY);
 
-  execve (exec_file, exec_argv, exec_env);
+  execve (exec_file,
+#ifdef __MINGW32__
+	(const char * const *)
+#endif
+	exec_argv,
+#ifdef __MINGW32__
+	(const char * const *)
+#endif
+	exec_env);
   SCM_SYSERROR;
 
   /* not reached.  */



[-- Attachment #3: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: MinGW port

[Neil Jerram]

Nils Durner <ndurner@web.de> writes:

> Hi,
>
> the attached patch fixes compiler errors on Win32/MinGW.

> -  execv (exec_file, exec_argv);
> +  execv (exec_file,
> +#ifdef __MINGW32__
> +	(const char * const *)
> +#endif
> +	exec_argv);

Thanks for the patch, but do you understand exactly what the
Win32/MinGW compiler is complaining about?  I thought it was generally
OK to pass a non-const value to a function whose corresponding
parameter is declared as const.

Regards,
     Neil



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: MinGW port

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> do you understand exactly what the
> Win32/MinGW compiler is complaining about?

The function takes "const char * const *" but the actual parameter is
"char **".

I've never understood why that should provoke a complaint.  Const is a
promise by the func that it won't modify the contents (of either the
array or the contained strings) so surely it's acceptable to pass
something that is allowed to be modified, isn't it?

In any case, __MINGW32__ conditionals are pretty horrible, I'd much
prefer to see guile not force "-Werror" on unsuspecting users.  Or not
do it on mingw at least.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: MinGW port

[Rob Browning]

Kevin Ryde <user42@zip.com.au> writes:

> In any case, __MINGW32__ conditionals are pretty horrible, I'd much
> prefer to see guile not force "-Werror" on unsuspecting users.  Or
> not do it on mingw at least.

I still favor -Werror.  It helps catch real errors, and you can
usually work around any spurious warnings (at least with gcc).  In the
(hopefully limited) situations where -Werror really is a problem,
there's always --disable-error-on-warning.

However, that said, I wouldn't be opposed to changing the set of
warning options or even disabling -Werror by default in particular
situations.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: MinGW port

[Nils Durner]

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);
>
> 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.

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

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.


Regards,

Nils


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

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


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: MinGW port

[Kevin Ryde]

Ken Raeburn <raeburn@raeburn.org> writes:
>
> Is the execv declaration (in some header file) part of mingw, or
> Windows?

Looks like mingw process.h.  But I've got an idea the "const * const *"
is a long-standing MSDOS-ism, presumably carried forward into that
horribly bloated overlay manager thing they added, I forget what it's
called ... doors, holes, flywire screen ...


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: MinGW port

[Nils Durner]

> Is the execv declaration (in some header file) part of mingw, or Windows?
It's part of the Windows SDK.

> That's for a function "_execv".  Is "execv" also defined by
> MS-provided headers?
Yes, "for portability". However, the declaration is the same.

> If execv is defined as a macro expanding to _execv, perhaps it should
> be casting its argument's type.
No, it's a function.


Nils


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile