[m-dev.] Diff: Fix an old CLP(R) bug

Warwick Harvey wharvey at cs.monash.edu.au
Mon Feb 7 15:06:09 AEDT 2000


Last week I wrote:
> Estimated hours taken: 0.25
> 
> Fix an _old_ CLP(R) bug.
> 
> clpr/clpr/init.c:
> 	When checking pointers to determine whether tagging is going to work
> 	OK, check all three kinds of pointers, not just the first two.

Obviously I didn't test this before I committed it.  It turns out that under 
Linux/i386 (at least my Red Hat 6.0(?) installation here), the third kind of 
pointer (local stack variable) has the top bit set, and so the standalone 
CLP(R) refuses to run now.

Either CLP(R) never actually tags pointers to local stack variables (in 
which case my fix was wrong), or it was just lucky that it (apparently) 
worked before.

I can't think of any reason why it should need to tag pointers to local 
stack variables, but from some of the things I've seen in there before, it 
wouldn't surprise me if it did do this somewhere.  And if the intention of 
the sanity check before I changed it was to *not* check local stack 
pointers, then why allocate a stack variable, take a pointer to it, and 
apply the mask, only to ignore the result?

Hmm, I would have sworn I'd made this change years ago to my integer version 
of CLP(R) (which is why I just jumped in and did it on this version), but 
upon checking the repository, apparently I didn't.  Maybe back then I 
discovered this same problem, and decided local stack variables weren't an 
issue.  In which case, I should probably change the test back.  But I can't 
think of any reasonable way of checking that local stack pointers are never 
tagged and untagged, to be sure that putting it back is the right thing to 
do.

Thoughts?

Warwick

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list