According to Geoff Hutchison:
> I took this to htdig3-dev since that seemed more appropriate.
>
> >I know! That's what I was seeing myself. It was often -1, but sometimes
> >it was 255. This makes me wonder if it's not some odd bug in Serialize
> >or Deserialize. The wierd thing is when I look at the code, it always
>
> This is entirely possible--there's evidence that there's a memory
> leak hiding in there somewhere. Neither Hans-Peter or I were able to
> find it amongst the macros.
>
> As to the -1 v. 255 issue, it may be a problem with picking the size
> of the variable to store. Hans-Peter's code tries things like char,
> short, then int and so on. Since -1 =~ 255 in binary form, this may
> be the culprit. (If so, it's surely an unsigned v. signed issue.)
>
> >I realize that there are many other hopcount related changes in 3.2,
> >and no, I don't intend to backport them all, but the reason I'm caught
> >up on this particular problem is that it seems to me to be a symptom of
> >a deeper underlying problem. If I can rule out that it is, I'm OK with
>
> You mentioned that you'd try switching to use 0 as the default and
> see if that killed the bug. Did that work? If not, then the bug
> certainly indicates *something* is wrong beyond the issue with -1 v.
> 255 IMHO.
Yes, indeed, it does. And, I found out why. The addnum() macro doesn't
add numbers if they're 0, just as addstring() doesn't add empty strings.
This means that Clear() MUST zero out all DocumentRef fields, because
they don't get stored, and therefore don't get read if they're 0.
There's a separate problem with addnum() - it was written assuming that
the number would always be positive. Note the line:
if (var <= (unsigned char) ~1) \
That means any negative number (which will be less than 255) will get
stored as a single byte. That's why the -1 became 255. I'm not sure
why it didn't seem to do this consistently, but I guess all the -1 hop
counts I saw really should have been 0 in the database, and the 255 hop
counts came up after it read a -1 and stored it back again.
Having fixed the default, the question still remains: is it a fair
assumption that none of the number fields in DocumentRef will ever
be negative? If that's correct, I think we're done. If it's incorrect,
then obviously the Serialize & Deserialize macros need more work!
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
