Subject: pkg/24757: (patches included) ...pkgsrc/lang/tinyscheme has AMD64 issues.
To: None <gnats-bugs@gnats.netbsd.org>
From: None <rkr@olib.org>
List: netbsd-bugs
Date: 03/12/2004 15:48:05
>Number:         24757
>Category:       pkg
>Synopsis:       (patches included) ...pkgsrc/lang/tinyscheme has AMD64 issues.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 12 21:49:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Richard Rauch
>Release:        NetBSD/amd64 (20040129)
>Organization:
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/
>Environment:
System: NetBSD socrates 1.6ZI NetBSD 1.6ZI (socrates) #2: Thu Jan 29 19:56:35 CST 2004  root@socrates:/usr/netbsd/current/src/sys/arch/amd64/compile/socrates amd64
Architecture: x86_64
Machine: amd64
>Description:
	It seems that most of the LISPs in pkgsrc have more or less serious
	issues when you try to compile them on the AMD64.  I'm coming to
	suspect that inveterate LISPers have spent too much time in typeless
	environments as they tend towards rather sloppy confusion between
	integers and pointers.

	For my purposes, I was looking for a non-GPLed, non-LGPLed LISP, which
	ruled out the only ones that *worked* (xemacs and now emacs).  Almost.
	TinyScheme compiles with just a few warnings about abuses of
	pointers and integers.

	Because of the lack of LISPs (outside of EMACSen) that work on AMD64,
	I felt that this was a serious problem.  (^&
>How-To-Repeat:
	Try to recompile tinyscheme from pkgsrc on an AMD64.  (Or probably any
	box that has different integer and pointer sizes.)
>Fix:
	I patched scheme.c and provide the following which should REPLACE the
	old patch-ab file.  Basicly it involves a few cases of changing {int}
	to {long}.  There is a warning that I did not see fit to fix about
	the SUN_DL symbol being redefined.  (As far as I can tell, the code
	only cares *if* it is defined.)


--- scheme.c.orig	2003-01-07 13:40:51.000000000 -0600
+++ scheme.c	2004-03-11 14:10:22.000000000 -0600
@@ -91,8 +91,16 @@
 # define prompt "> "
 #endif
 
+#ifndef TINYSCHEMEPREFIX
+# define TINYSCHEMEPREFIX	""
+#endif
+
+#ifndef TINYSCHEMEDIR
+# define TINYSCHEMEDIR	""
+#endif
+
 #ifndef InitFile
-# define InitFile "init.scm"
+# define InitFile TINYSCHEMEPREFIX TINYSCHEMEDIR "init.scm"
 #endif
 
 #ifndef FIRST_CELLSEGS
@@ -569,7 +577,7 @@
 	  i = ++sc->last_cell_seg ;
 	  sc->alloc_seg[i] = cp;
 	  /* adjust in TYPE_BITS-bit boundary */
-	  if(((int)cp)%adj!=0) {
+	  if(((long)cp)%adj!=0) {
 	    cp=(char*)(adj*((long)cp/adj+1));
 	  }
         /* insert new segment in address order */
@@ -2055,7 +2063,7 @@
 
 static void s_save(scheme *sc, enum scheme_opcodes op, pointer args, pointer code) 
 { 
-  int nframes = (int)sc->dump; 
+  long nframes = (long)sc->dump; 
   struct dump_stack_frame *next_frame; 
 
   /* enough room for the next frame? */ 
@@ -2075,7 +2083,7 @@
 
 static pointer _s_return(scheme *sc, pointer a) 
 { 
-  int nframes = (int)sc->dump; 
+  long nframes = (long)sc->dump; 
   struct dump_stack_frame *frame; 
 
   sc->value = (a); 
@@ -2115,7 +2123,7 @@
 
 static INLINE void dump_stack_mark(scheme *sc) 
 { 
-  int nframes = (int)sc->dump;
+  long nframes = (long)sc->dump;
   int i;
   for(i=0; i<nframes; i++) {
     struct dump_stack_frame *frame;
>Release-Note:
>Audit-Trail:
>Unformatted: