Re: 64-unclean code in eval.c
Ar an ceathrú lá déag de mí Meitheamh, scríobh Ben Wing:
i'm staring at this code and i don't see what's wrong
even on 64-bit
platforms. i'm pretty sure i wrote this code. it is used for saving
and restoring internal C variables of type `int' and it tries to put it
into a Lisp int but it's careful to use a opaque pointer in the rare
instance where the value won't fit into a Lisp int. the code is careful
with its casting so i don't see what the problem is.
if the problem is this line:
[It is.]
val = (int) get_opaque_ptr (lval);
then something is too smart for its own good.
Yes, the compiler is. But hey, it’s just software.
i would not recommend Aidan's patch because i think it's too
obscure.
instead, put in a comment to the effect that we know the value stored in
the void * is a crypto-int since we put an int into it in the first
place, and i'd use more clever casts to get rid of the problem. for
example, cast to (long) and then to (int).
On AMD64, every C int (32 value bits) will fit into a Lisp int (63 value
bits). So no value other than a Lisp int need ever be saved, and no value
other than a Lisp int need be restored. I believe long is also 32 bits
there; maybe a cast to long long and then a cast to int would work.
btw how can this be an error under C++? when i used to do devwork i
always ran a C++ build as part of my tests, and unless something changed
recently, this code has been around for long before then.
The change is the availablility of the AMD64 platform and its
pointer-bigger-than-int approach. If XEmacs had been running and regularly
compiled under DOS we probably wouldn’t be seeing these errors.
and if it is indeed a problem under C++, use this:
val = reinterpret_cast<int> get_opaque_ptr (lval);
that's the C++ way of saying "abandon hope all ye who enter here" :)
Good to know.
--
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