jakarta-oro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Takashi Okamoto" <tokam...@rd.nttdata.co.jp>
Subject Re: [PATCH] for unicode problem over 0xff characters
Date Tue, 14 Nov 2000 03:31:32 GMT
Thank you, daniel.

> The problem is that it can cause excessive memory use (e.g., up to
> 8K per character class) since it follows the same bitfield approach
> used for the 8-bit ASCII character classes.
  
I agree my solution is poor(;_;
But 8k memory is garbage for recent high performance PC:-)

> ArrayOutOfBoundsExceptions to be thrown if the input contains
> characters outside of the upper limit of the range of the character
> class range:

> !  if((__program[current + (nextChar >> 4)] &

I mistook.

 __program = new char[Character.MAX_VALUE >> 4];

This isn't  enough allocation for upper limit. 
Limit of __program depend on both 'char >> 4' and 'current'.
How many limit is it?

> It also doesn't make the necessary changes to Perl5Debug, which
> would break after this patch was applied.  

Excuse me , I have never used Perl5Debug. 
Is it fatal error? 
If you have your idea , could you tell me your idea ?

> So the question is, do people feel we should implement a temporary
> stopgap measure, or just wait to "do it right"?

How long will we wait for "proper" solution?
If I need many time for 'proper' release , I want temporary.


Jakarta-regexp ,gnu-regexp and xerces-j(IBM Regexp4j) didn't have this
problem. 
Not english people may run away to their library.
ORO have more function . This problem is just one disappointment for us.

Regards.
-------------
Takashi Okamoto


Mime
View raw message