Re: PSPP & PSPPIRE running as native windows applications.

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Wed, Feb 07, 2007 at 11:49:13PM +0900, John McCabe-Dansted wrote:
>      Presumably wine follows the old incorrect windows behavior. I suspect
>      that we simply shouldn't rely on snprintf being correct on windows,
>      since testing for correctness of snprintf when cross-compiling doesn't
>      really tells us anything useful. Perhaps we should just bundle a
>      portable version of snprintf in the windows.exe, such as the
>      following:
>       http://www.ijs.si/software/snprintf/
>
> I thought that we were in fact doing that (through the use of
> gnulib's) implementation, but obviously not.  Portability is what
> gnulib is all about, so maybe we should discuss this on their list.

To me, it looks like gnulib is simply testing whether snprintf
and vasnprintf are available, not whether their interfaces are
correct.

>      The bad snprintf might also cause segfaults if it fails to terminate
>      the string with '\0'.
>
> Indeed.  In order to mitigate  this problem, it might be a good idea in
> rank.q to increase the length of func_abb (rank.q:700) by 1, and
> initialise it with zeros.

I'd rather seek other solutions (for example, improving gnulib or
fixing mingw) before modifying correct PSPP code, not least
because I'm liable to forget why code has been changed away from
what seems obviously correct.

>      I suspect that "is_special_file_name" in src/data/file-name.c should
>      be replaced with "fn_is_special" as "is_special_file_name" does not
>      occur anywhere else in pspp or indeed the web.
>
> It would seem that you're right.

I checked in this fix, thanks.

>      configure added "-Dunix" to the Makefile. This did not seem good.
>      (Perhaps configure was picking up the host environment).
>
> Yes.  Looking inside ./configure, this symbol is defined according to
> the most naive rules:
>
> if test x"$host_os" != x"msdos" ; then
>   unix_TRUE=
>   unix_FALSE='#'
> else
>   unix_TRUE='#'
>   unix_FALSE=
> fi

We should probably drop this entirely from configure.ac: 

    AM_CONDITIONAL(unix, test x"$host_os" != x"msdos" )
    AM_CONDITIONAL(msdos, test x"$host_os" = x"msdos" )

The "unix" symbol is only used in the source tree, in
src/data/file-name.c and src/ui/terminal/read-line.c, to try to
figure out how we should treat file names and the file system.
We should use a different symbol for this, or determine it some
other way, instead of overloading the existing "unix" symbol.

Better yet, it looks like we can use gnulib features, and a few
assumptions, to get rid of dependence on these variables.

The "msdos" symbol is not used at all.

I'll see what I can do.

> I suggest therefore that we ignore this symbol, and instead use #if
> HAVE_FORK, HAVE_WAIT or whatever is appropriate to the function(s)
> we're trying to protect.

Definitely.

> I think this entire file should be enclosed in #if HAVE_SYS_WAIT_H /
> #endif, then, instead of stubbing fork(), wait() etc, just stub the
> connect_debugger() function.

I agree.  I propose this patch:

--- debugger.c.~1.2.~   2006-12-16 13:15:30.000000000 -0800
+++ debugger.c  2007-02-07 21:37:01.000000000 -0800
@@ -18,6 +18,9 @@
 
 #include <config.h>
 
+#include "debugger.h"
+
+#if HAVE_SYS_TYPES_H && HAVE_SYS_WAIT_H
 #include <errno.h>
 #include <sys/types.h>
 #include <unistd.h>
@@ -25,14 +28,10 @@
 #include <stdlib.h>
 #include <sys/wait.h>
 
-
-#include "debugger.h"
-
 /* Fork, start gdb and connect to the parent process. 
    If that happens successfully, then this function does not return,
    but exits with EXIT_FAILURE. Otherwise it returns.
  */
-   
 void
 connect_debugger (void)
 {
@@ -64,3 +63,12 @@ connect_debugger (void)
   exit (EXIT_FAILURE);
 }
 
+#else /* !(HAVE_SYS_TYPES_H && HAVE_SYS_WAIT_H) */
+/* Don't know how to connect to gdb.
+   Just return.
+ */
+void 
+connect_debugger (void) 
+{
+}
+#endif /* !(HAVE_SYS_TYPES_H && HAVE_SYS_WAIT_H) */



>      diff -r1.5 afm.c
>      35a36
>      >#include <limits.h>
>      
> That would seem reasonable.

I checked this in.
-- 
Ben Pfaff 
address@hidden
http://benpfaff.org