[
https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196929#comment-13196929
]
Uwe Schindler commented on LUCENE-3738:
---------------------------------------
The correct fix for longs would be to add one more unrolled loop iteration (for
10th byte). Then it would work with negative numbers as vInts. But very
wasterful.
About negative vInts: We have them unfortunately in pre-4.0 formats with
version numbers. I think e.g. stored fields reader reads the first vInt from
file, if its >=0 its a pre-very-ancient format and is some offset/count/foo/bar
(no idea). If its negative, its a version number.
We should fix the unrolled vLong reader in 3.x and trunk to have one more loop
so its consisten with writer (the assert stays -> ist an assert for the
continuation bit not set on last byte).
We should try to never write negative numbers for post 4.0 formats, maybe add
conditional assert (like for utf8 strings), so preflex can write using negative
vints and dont trip assert.
> Be consistent about negative vInt/vLong
> ---------------------------------------
>
> Key: LUCENE-3738
> URL: https://issues.apache.org/jira/browse/LUCENE-3738
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Fix For: 3.6, 4.0
>
>
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
