[
https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231506#comment-13231506
]
Robert Muir commented on LUCENE-3738:
-------------------------------------
{quote}
Otherwise you can even produce endless loops at some places. - Of course not
when you have tight loops, but things like checking that the document count is
in line with e.g. some other value from liveDocs is essential.
{quote}
I agree there a ton of places (essentially all metadata) where we should be
using real checks (not asserts).
I see Mike's point though: readVLong() is very general, so someone could be
using it where performance is important.
It just so happens its mostly only used today for metadata type things (except
maybe terms dictionary stats and a few other places).
> 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
>
> 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:
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
