<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>1) Just fyi, NT386GNU didn't build with my fix, so it is disabled there only, and the bug could very well be present there.<BR>
Er, then again, this stuff works differently for the gcc backend, so I don't know, I'll have to look, and run the tests, not today.<BR>
Which reminds me also, these symbols should be static hand.c, except for NT386 -- the source can't tell, so it'll have to be a define from the m3makefile.<BR>
<BR>
2) Can anyone confirm my history and the missing source?<BR>
ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1 and 5.1? I don't think 4.1 is accurately marked.<BR>
In particular, I don't think the 4.1 Stackx86.m3 is what 4.1 actually shipped.<BR>
<BR>
3) Or confirm my analysis that leads to the "accusation"? It was tedious.<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: m3devel@elegosoft.com<BR>Date: Sat, 10 May 2008 15:40:40 +0000<BR>Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
There is SOME evidence that this lowbits/highbits<BR>problem is a regression introduced in Critical Mass 5.1.<BR>And there are inconsistent data.<BR>(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.)<BR><BR> <BR>The source history is a little incomplete.<BR>Critical Mass 4.1 did not ship with complete source.<BR>In particular, the compiler source is missing.<BR>Libraries are there.<BR><BR> <BR>Aside: I wonder if the 4.1 release can be made more widely<BR>available, for purposes such as this. For one thing, I can contribute<BR>how to trivially patch the NT386 binary to not care about the registration key.<BR>I did buy it, but finding the key is..difficult.<BR><BR> <BR>The Elegosoft repository claims to have an import of 4.1<BR> followed by an update to 5.1, but it is suspicious.<BR> <BR><BR>3.6 Stackx86.m3 -- no reference to _lowbits / _highbits<BR>3.6 hand.c -- no implementation of ditto<BR>3.6 didn't offer dynamic linking, so it would have been ok.<BR><BR> <BR>The 4.1 CD includes the 3.6 source in "contrib" and some of the<BR>4.1 source in "source". That confused me at first, to have two of everything.<BR>I merely ASSUME what is what. I didn't look in detail.<BR><BR> <BR>4.1 CD hand.c -- no implementation of _lowbits / _highbits<BR>4.1 CD Stackx86.m3 -- source not available, darn it<BR> <BR><BR>4.1 in repository hand.c -- no implementation of ditto<BR>4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits<BR><BR> <BR>5.1 in repository hand.c -- implementation of ditto<BR>5.1 in repositoy Stackx86.m3 -- no change<BR> <BR><BR>The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) <BR><A href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1" target=_blank>http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1</A><BR> <BR><BR>introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff:<BR> <A href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2" target=_blank>http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2</A><BR><BR> <BR>This is all a bit tedious so someone please double check me.<BR> <BR><BR>The 4.1 source in the repository is not self consistent.<BR>I contend it is wrong.<BR>I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.<BR>Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source.<BR> <BR><BR>5.1 in the repository is self consistent, and I contend has the bug.<BR> <BR><BR>The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,<BR> and none of the .dlls in the system import them.<BR><BR> Several versions have LoBits / HiBits be file-level static, further<BR> implying they aren't used outside of hand.c.<BR><BR> It is difficult for me to browse the old version of the tree however.<BR> I guess I should try something like checkout -revision 1 and then search that locally?<BR><BR> Inspection says that HiBits / LoBits went static in 2003 here:<BR> <BR> <A href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c" target=_blank>http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c</A><BR> <BR> and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with<BR> _lowbits / _highbits. This is a bit tangential, but the point is to exonerate<BR> LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.<BR> They are nearly identical. See hand.c for how they relate. There is an extra<BR> entry in one pair or the other, either at the start or the end, and one is uint and the<BR> other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.<BR> The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.<BR> The gcc backend does not reference _lowbits / _highbits.<BR><BR>So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.<BR>And make sure m3tests passes with that.<BR>I didn't look at the code yet.<BR>In general the code quality is not super high so it probably matters little.<BR><BR>Also obviously it would be prudent to review the code here to make sure it is correct,<BR>or to look at the relevant unit test and see if it seems comprhensive.<BR> <BR> <BR>Thoughts?<BR> <BR> <BR>Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??<BR>I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.<BR> <BR><BR> - Jay<BR></BLOCKQUOTE></body>
</html>