Dear all,
thanks for the workaround. The patch below allowed me to get around the XSB bug I reported some time ago. I can thus continue developing an XSB interface for the Parma Polyhedra Library (http://www.cs.unipr.it/ppl/). All the best
Roberto
Luis Fernando Pias de Castro wrote:
Hi,
well, it seems both Kostis and David were right. ;)
The problem is due to a use of numbervars *inside* the singleton checks. The patch below seems to eliminate the segfault in this case, even though it has the side-effect of missing the warning. Any suggestions of how to deal with this better? Or should I commit this?
Thanks, -Luis
=================================================================== RCS file: /cvsroot/xsb/XSB/cmplib/singlton.P,v retrieving revision 1.3 diff -c -r1.3 singlton.P *** singlton.P 18 Aug 1999 22:05:23 -0000 1.3 --- singlton.P 22 Jul 2002 20:33:20 -0000
*** 78,83 **** --- 78,85 ---- arg(NewN, Term, Arg), % We cannot use ll_arg/3 here (Term may be a list) ( Arg = '$VAR'(Number) -> ( integer(Number) ->
Number > 0,Number =< Arity, ll_arg(Number, Occurences, OccCount), ( var(OccCount) -> OccCount = found(_) ; OccCount = found(Times) ->Kostis Sagonas kostis@csd.uu.se writes:
David wrote:
Yup, it's a bug. I'm quite sure it arises because the compiler is using numbervars, and gets confused about your use of $VAR(0) and its use of $VAR(0) for the variable A.
Not quite. Just in case it was not clear from my previous message, the problem is due to the singleton check pass of the XSB compiler, not the use of numbervars.
I bet that in XSB a similar problem can be observed in compiling something like:
p :- A = '$VAR'(87456).
Or using some other big number. NOT related to numbervars!
Kostis.