[
https://issues.apache.org/jira/browse/LUCENE-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549625#comment-13549625
]
Adrien Grand commented on LUCENE-4674:
--------------------------------------
bq. I still like the idea of fixing this myself (maybe Shai's idea?). i don't
like this kind of dangerous stuff!!!!!!
The 'upto' idea or "allocating a new byte[] if someOtherStuff offset + length >
this.offset + length?" ?
bq. I ultimately think LUCENE-4675 is the next logical step, but can we remove
this a.copy()-overwrites-b trap as an incremental improvement?
Regarding the idea to switch to the java.nio buffers, are there some traps
besides backward compatibility? Should we start migrating our internal APIs to
this API (and maybe even the public ones for 5.0?).
> 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]
