lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3738) Be consistent about negative vInt/vLong
Date Sat, 17 Mar 2012 14:09:38 GMT


Uwe Schindler commented on LUCENE-3738:

bq. The check is only ommitted in the unrolled loop, the for-loop still contains the check.

I'm confused... I don't see how/where BufferedIndexInput.readVLong is
checking for negative result now...?

I mean that the actual "if (b & mask != 0)" is also in the original while loop. The original
while loop then simply proceeds with reading bytes util the highest bit is null. The unrolled
loop behaves different (and thats a real bug), because it will silently not read those remaining
bytes, so the file pointer is on a different byte after the call. This also affects readVInt!!!

In my opinion, we should unroll *all* readVInt/readVLong loops so all behave 100% identical!
And in the case of the last byte read (where the current assert is), throw exception. If we
don't unroll all readVInts we have to somehow also make the loop exit after too many bytes
are read, which would be an costly extra check in the loop - thats the reason why I want to
unroll all loops to fail after 5 or 9 bytes.
> Be consistent about negative vInt/vLong
> ---------------------------------------
>                 Key: LUCENE-3738
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Michael McCandless
>            Assignee: Uwe Schindler
>             Fix For: 3.6, 4.0
>         Attachments: LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch
> Today, write/readVInt "allows" a negative int, in that it will encode and decode correctly,
just horribly inefficiently (5 bytes).
> However, read/writeVLong fails (trips an assert).
> I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number...
it's badly trappy today.  But, unfortunately, we sometimes rely on this... had we had this
assert in 'since the beginning' we could have avoided that.
> So, if we can't add that assert in today, I think we should at least fix readVLong to
handle negative longs... but then you quietly spend 9 bytes (even more trappy!).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message