On 27/03/2018 00:09, David Lloyd wrote:
:
I think they may have use in some cases e.g. reading a dictionary from
a file, and generally in code which prefers byte buffers over arrays
(completely outside of the direct/heap buffer question), and they were
easy enough to implement. But I'm okay dropping these methods if that
is what is desired.
I'm in two minds on the setDictionary methods. No objection to including
them for consistency reasons, I'm just not sure if they will really be used.
:
I also wonder if the parameter should be renamed to "input" or "source".
I was going for some kind of consistency with the array variants (that
is, name the parameter what it is), though they simply use "b" for
their parameter name so that interpretation might be a stretch.
Should I update them all?
I think this would be good, if you don't mind doing it.
:
I'm not 100% familiar with the new JavaDoc categories (ok I'm 0%
familiar), but the JEP for these says "This category consists of
commentary, rationale, or examples pertaining to the API.". But this
feels more like specification to me since it is "specifications that
apply to all valid implementations, including preconditions,
postconditions, etc.". Which is to say, if you don't provide enough
remaining space in the output buffer, you will have incorrect
operation as a result. WDYT?
The current wording (which pre-dates your changes of course) reads more
like API advice. I think it's a bit confusing too as it doesn't define
what a "flush marker" is. I think we will need to re-word that sentence
to make it clearer.
I don't have cycles just now to go through all the implementation but I
think Sherman is doing that. It will need careful review to avoid being
abused to attack memory outside of the buffer. I did check the use of
position() and limit() to calculate the remaining and these need correct.
I hope this was a typo of "these seem correct" and not a typo of
"these need correcting"?
Oops, this was indeed a typo in my mail.
-Alan
