[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231962#comment-13231962 ]
Michael McCandless 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...? Are you proposing adding an if into that method? That's what I don't want to do... eg, readVLong is called 3 times per term we decode (Lucene40 codec); it's a very low level API... other codecs may very well call it more often. I don't think we should add an if inside BII.readVLong. Or.... maybe you are saying you just want the unrolled code to handle the negative vLong case (ie, unroll the currently missing 10th cycle), and not add an if to BufferedIndexInput.readVLong? And then "for free" we can add a real if (not assert) if that 10th cycle is hit? (ie, if we get to that 10th byte, throw an exception). I think that makes sense! bq. there are other asserts in the index readiung code at places completely outside any loops, executed only once when index is opened. +1 to make those real checks, as long as the cost is vanishingly small. bq. which is also a security issue when you e.g. download indexes through network connections and a man in the middle modifies the stream. I don't think it's our job to protect against / detect that. bq. Disk IO can produce wrong data. True, but all bets are off if that happens: you're gonna get all sorts of crazy exceptions out of Lucene. We are not a filesystem. > 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 > 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: 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