From: Michal Suchanek <hramrach@...>
Date: 2009-02-24T22:20:52+09:00
Subject: [ruby-core:22410] Re: [Feature #908] Should be an easy way of 	reading N characters from am I/O stream

2009/2/24 Michael Selig <michael.selig@fs.com.au>:
> On Mon, 23 Feb 2009 21:35:30 +1100, Michal Suchanek <hramrach@centrum.cz>
> wrote:
>
>>> Theoretically if separate (combining) character accents are considered
>>> part of the character then a character might be quite long - I guess
>>> about ten codepoints which can be themselves up to six bytes. However,
>>> the number of accents one can put together should be limited to
>>> meaningful combinations so this should still be secure - as long as
>>> the code which determines what is a valid character does not have
>>> bugs. This might be tricky in some cases, though.
>>>
>>
>> BTW the same goes for "reading N bytes up to a character boundary"
>> unless you are willing to accept that you might read nothing even if
>> data is available because the character did not fit into N bytes, even
>> for a large N.
>
> The current behaviour of IO#gets "limit" parameter is "read N bytes but
> round *UP* to the next character boundary". Therefore you may get more bytes
> returned than requested. As long as "limit" is 1 or more, you should always
> read something unless the file is at EOF, right?
>
> However I still do not understand why reading N characters (instead of the
> current "limit" implementation) might be described as being "insecure". Can
> someone please explain it? It is clear that the string returned may be
> larger than N bytes long, but why is that "insecure"?
>

The current gets is not any more secure since it rounds up. If you
found a bug in an encoding that could give you an infinite character
either version would break.

Thanks

Michal