11:20 a.m.
This code in eval.c at l. 6016 gets flagged as 64-bit unsafe
(specifically on amd64 pointers and EMACS_INTs are 64 bits, while ints
are 32 bits). In fact, in C++ it's an error. Anybody know what
should be happening here? I would assume that all C integers that are
visible to Lisp are EMACS_INTs, but if there not changing the
declaration of val to EMACS_INT below would be a disaster.
static Lisp_Object
restore_int (Lisp_Object cons)
{
Lisp_Object opaque = XCAR (cons);
Lisp_Object lval = XCDR (cons);
int *addr = (int *) get_opaque_ptr (opaque);
int val;
if (INTP (lval))
val = XINT (lval);
else
{
val = (int) get_opaque_ptr (lval);
free_opaque_ptr (lval);
}
*addr = val;
free_opaque_ptr (opaque);
free_cons (cons);
return Qnil;
}
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:33 a.m.
Ar an triochadú lá de mí Bealtaine, scríobh Stephen J. Turnbull:
This code in eval.c at l. 6016 gets flagged as 64-bit unsafe
(specifically on amd64 pointers and EMACS_INTs are 64 bits, while ints
are 32 bits). In fact, in C++ it's an error. Anybody know what
should be happening here? I would assume that all C integers that are
visible to Lisp are EMACS_INTs,
The code doesn’t appear to deal with integers that are visible to Lisp, only
those C integers involved in managing the Lisp stack. And an explicit cast
gives an error in C++? What?
The functions are used ultimately by internal_bind_int and the corresponding
unbinding code; the C integers bound are entering_debugger, in_warnings and
inhibit_flags. The below should fix things, if I understand things
correctly; no need to change record_unwind_protect_restoring_int, since
NUMBER_FITS_IN_AN_EMACS_INT on an integer value will always be true on
AMD64.
--- eval.c~ 2007-06-01 04:24:21.000000000 +0200
+++ eval.c 2007-06-01 04:29:56.000000000 +0200
＠＠ -6011,11 +6011,13 ＠＠
if (INTP (lval))
val = XINT (lval);
+#if SIZEOF_EMACS_INT <= SIZEOF_INT
else
{
val = (int) get_opaque_ptr (lval);
free_opaque_ptr (lval);
}
+#endif
*addr = val;
free_opaque_ptr (opaque);
[...] but if there not changing the declaration of val to EMACS_INT
below
would be a disaster.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:32 p.m.
Ar an chéad lá de mí Meitheamh, scríobh Aidan Kehoe:
The functions are used ultimately by internal_bind_int and the
corresponding
unbinding code; the C integers bound are entering_debugger, in_warnings and
inhibit_flags. The below should fix things, if I understand things
correctly; no need to change record_unwind_protect_restoring_int, since
NUMBER_FITS_IN_AN_EMACS_INT on an integer value will always be true on
AMD64.
Still, changing it is clearer:
--- eval.c~ 2007-06-01 04:24:21.000000000 +0200
+++ eval.c 2007-06-02 00:31:01.000000000 +0200
＠＠ -6011,11 +6011,13 ＠＠
if (INTP (lval))
val = XINT (lval);
- else
+#if SIZEOF_EMACS_INT <= SIZEOF_INT
+ else
{
val = (int) get_opaque_ptr (lval);
free_opaque_ptr (lval);
}
+#endif
*addr = val;
free_opaque_ptr (opaque);
＠＠ -6034,7 +6036,7 ＠＠
if (NUMBER_FITS_IN_AN_EMACS_INT (val))
lval = make_int (val);
- else
+ else if (SIZEOF_EMACS_INT <= SIZEOF_INT)
lval = make_opaque_ptr ((void *) val);
return record_unwind_protect (restore_int, noseeum_cons (opaque, lval));
}
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:02 a.m.
Aidan Kehoe <kehoea(a)parhasard.net> writes:
Ar an chéad lá de mí Meitheamh, scríobh Aidan Kehoe:
> The functions are used ultimately by internal_bind_int and the
> corresponding unbinding code; the C integers bound are
> entering_debugger, in_warnings and inhibit_flags. The below
> should fix things, if I understand things correctly; no need to
> change record_unwind_protect_restoring_int, since
> NUMBER_FITS_IN_AN_EMACS_INT on an integer value will always be
> true on AMD64.
Still, changing it is clearer:
--- eval.c~ 2007-06-01 04:24:21.000000000 +0200
+++ eval.c 2007-06-02 00:31:01.000000000 +0200
＠＠ -6011,11 +6011,13 ＠＠
if (INTP (lval))
val = XINT (lval);
- else
+#if SIZEOF_EMACS_INT <= SIZEOF_INT
+ else
{
val = (int) get_opaque_ptr (lval);
free_opaque_ptr (lval);
}
+#endif
*addr = val;
free_opaque_ptr (opaque);
＠＠ -6034,7 +6036,7 ＠＠
if (NUMBER_FITS_IN_AN_EMACS_INT (val))
lval = make_int (val);
- else
+ else if (SIZEOF_EMACS_INT <= SIZEOF_INT)
lval = make_opaque_ptr ((void *) val);
return record_unwind_protect (restore_int, noseeum_cons (opaque, lval));
}
This mixture of preprocessing conditionals and C level conditionals
appears inconsistent.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6181
days inactive
6184
days old
3 comments
3 participants
participants (3)
-
Aidan Kehoe -
David Kastrup -
Stephen J. Turnbull