[M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)

[Jay]

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.
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.
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.
 
2) Can anyone confirm my history and the missing source?
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.
In particular, I don't think the 4.1 Stackx86.m3  is what 4.1 actually shipped.
 
3) Or confirm my analysis that leads to the "accusation"? It was tedious.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 10 May 2008 15:40:40 +0000Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)


There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.(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.) The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there. Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult. The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious. 3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok. The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail. 4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it 4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits 5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1 introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: 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 This is all a bit tedious so someone please double check me. The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source. 5.1 in the repository is self consistent, and I contend has the bug. The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?  Inspection says that HiBits / LoBits went static in 2003 here:  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c   and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.  The gcc backend does not reference _lowbits / _highbits.So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.  Thoughts?  Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080514/4922fce7/attachment-0002.html>