Re: PSPP & PSPPIRE running as native windows applications.

[John Darrington]

On Wed, Feb 07, 2007 at 11:49:13PM +0900, John McCabe-Dansted wrote:
     On 2/7/07, John Darrington <address@hidden> wrote:
     >Three of the tests were failing merely due to whitespace differences.
     >I've fixed these three tests.
     
     I've done a cvs up and recompiled. Now I get 33 failures instead of just 
32 
     :(
     
     The new log is at:
     http://www.csse.uwa.edu.au/~john/newmake2.log

Hmm. Perhaps I missed a "-b" flag in npar-binomial.sh,
npar-chisquare.sh  and very-long-string.sh --- Try replacing "diff"
with "diff -b". 

     >The differences shown in the  RANK test is interesting.  I suspect the
     >problem is at src/language/stats/rank.q:701
     >
     >  snprintf(func_abb, 4, "%s", function_name[f]);
     >
     >according to my man page " The functions snprintf() and vsnprintf() do
     >not write more than size bytes (including the trailing '\0').", but
     >your version does not seem to include the trailing null in the size,
     >so we're seeing one more character.  Perhaps you should report that
     >to the maintainer of your C library.  Alternatively perhaps we should
     >be using gnulib/autoconf to deal with broken implementations.
     
     I made a testfile. Your suspicions are correct.
      i=snprintf(x,4,"12345");
      Linux: i=5, x="123"
      Wine: i=-1, x="1234"
     
     This is a known bug:
      http://sourceforge.net/mailarchive/message.php?msg_id=38119968
     
     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.

     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.
     
     On the topic of *printf, I had to comment out
      libintl_fprintf libintl_printf and libintl_sprintf
     In intl/printf.c because these symbols conflict with symbols provided by 
     -lintl
     

Didn't Ben's checkin fix this?

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


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.

     RCS file: /sources/pspp/pspp/src/ui/debugger.c,v
     retrieving revision 1.2
     diff -r1.2 debugger.c
     26c26
     < #include <sys/wait.h>
     ---
     >//#include <sys/wait.h>
     38a39,40
     >
     >

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.

     Index: src/output/afm.c
     ===================================================================
     RCS file: /sources/pspp/pspp/src/output/afm.c,v
     retrieving revision 1.5
     diff -r1.5 afm.c
     35a36
     >#include <limits.h>
     
That would seem reasonable.



J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature