>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
SJT> The point is moot unless somebody fixes the data loss bug I
SJT> reported.
mb> I don't see why your action regarding one bug depends on your
mb> action regarding another bug.
Because I don't want to rip out Matt's code if I can avoid it. It's
easier to fix a bug if we get more reports. "Many eyes." If the
release is going to get delayed because nobody fixes a showstopper,
there's no good reason not to leave Matt's code in, and give it more
time to get fixed, too.
mb> You know, someone else could try to fix this bug too, before I
mb> get around to it.
I will take a look at it. And it would be nice if lots of people
would look at this. But you said you would look at it. And it is a
showstopper. (Matt's isn't, quite, since AFAIK you can QUIT out of it.)
BTW, it strikes me that #define'ing INT_GCBITS to 2, and using bit 0
as a pointer/immediate flag, and bit 1 as a char/int flag when bit
zero is set, would take you quite a ways toward the Holey Grale of
Sun3 support. We have room for 2 30-bit data types and one 31-bit
data type. Currently the 30's are pointers and chars and the 31 is
int. I know swapping ints and chars works fine (I ran for about 3
months with #define BASKIN_ROBBINS_CHARS, but eventually gave up
because Hrvoje vetoed the patch). Pointers are problematic, but
maybe....
I suppose you already thought of that, though?
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."