[
https://issues.apache.org/jira/browse/LUCENE-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549536#comment-13549536
]
Uwe Schindler commented on LUCENE-4674:
---------------------------------------
I agree with Robert. We had BytesRef and CharsRef in the past doing that stuff.
But as the name of the class is *Ref not *Buffer, it should only hold a
reference to a byte[] and not change it or grow it. Esspecially it should not
change offset. This is risky, if you get a BytesRef that points to some slice
in a larger buffer and you suddenly resize it, invalidating content that might
be needed by other stuff (e.g. while iterating terms, the previous/next term
gets corrupted).
I would in any case favour to use ByteBuffer instead of this unsafe and
inncomplete "duplicate". BytesRef is for user-facing APIs a mess.
> Consistently set offset=0 in BytesRef.copyBytes
> -----------------------------------------------
>
> Key: LUCENE-4674
> URL: https://issues.apache.org/jira/browse/LUCENE-4674
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-4674.patch
>
>
> BytesRef.copyBytes(BytesRef other) has two branches:
> - either the destination array is large enough and it will copy bytes after
> offset,
> - or it needs to resize and in that case it will set offset = 0.
> I think this method should always set offset = 0 for consistency, and to
> avoid resizing when other.length is larger than this.bytes.length -
> this.offset but smaller than this.bytes.length.
--
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]
