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

2009/2/23 Michal Suchanek <hramrach@centrum.cz>:
> 2009/2/22 Michael Selig <michael.selig@fs.com.au>:
>> On Mon, 23 Feb 2009 03:00:41 +1100, Tanaka Akira <akr@fsij.org> wrote:
>>
>>> In article <6.0.0.20.2.20090220134502.0823ee98@localhost>,
>>> ��Martin Duerst <duerst@it.aoyama.ac.jp> writes:
>>>
>>>> Can you give more specific explanations of why reading a number
>>>> of characters might not be secure?
>>>
>>> I considered ISO-2022-JP, Unicode combining characters and
>>> Punycode.
>>>
>>> In these encodings, fixed number of characters doesn't limit
>>> the number of bytes.
>>
>> Sure, but how does that make it "insecure"?
>>
>>> However they may not cause problem now because Ruby doesn't
>>> support combining characters, etc. ��But Ruby's encoding
>>> system is extensible. ��It is possible to define an encoding
>>> which makes the character-wise limit insecure.
>>
>> Sorry, I do not really understand what you mean by the word "insecure".
>> Perhaps you could explain what you mean in more detail.
>> Also I still do not understand why you say the character limit might be
>> "insecure". Can you give an example, please?
>>
>
> 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.

Thanks

Michal