[
https://issues.apache.org/jira/browse/LUCENE-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549598#comment-13549598
]
Shai Erera commented on LUCENE-4675:
------------------------------------
ok. While you're at it, what do you think about adding an 'upto' member for
easier iteration on the bytes/ints/chars? (see my comment on LUCENE-4674)
> remove *Ref.copy/append/grow
> ----------------------------
>
> Key: LUCENE-4675
> URL: https://issues.apache.org/jira/browse/LUCENE-4675
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> These methods are dangerous:
> In general if we want a StringBuilder type class, then it should own the
> array, and it can freely do allocation stuff etc. this is the only way to
> make it safe.
> Otherwise if we want a ByteBuffer type class, then its reference should be
> immutable (the byte[]/offset/length should be final), and it should not have
> allocation stuff.
> BytesRef is none of these, its like a C pointer. Unfortunately lucene puts
> these unsafe, dangerous, trappy APIs directly in front of the user.
> What happens if i have a bug in my application and it accidentally mucks with
> the term bytes returned by TermsEnum or the payloads from
> DocsAndPositionsEnum? Will this get merged into a corrupt index?
> I think as a start we should remove these copy/append/grow to minimize this
> closer to a ref class (e.g. more like java.lang.ref and less like
> stringbuilder). Nobody needs this stuff on bytesref, they can already operate
> on the bytes directly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]
