apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: nasty apr-util xlate bug
Date Fri, 19 Mar 2004 23:01:34 GMT
On Fri, Mar 19, 2004 at 05:08:00PM -0500, Jeff Trawick wrote:
> Joe Orton wrote:
> >Hmm.  Is this sbcs thing really safe at all?  Just because a character
> >set translation gives a particular mapping for 0x00-0xff in that order
> >why is it guaranteed that it will for any other ordering of bytes? 
> >
> >e.g. invent a mapping which does "0xff <end>" -> "0xff" but "0xff 0xf1"
> >-> "0x42".  I'd be surprised if a mapping between two real charsets does
> >*not* exist which does something like this, given the range of extremely
> >weird and wonderful charsets out there.
> to rule out this issue completely, 256 calls to iconv() would be required 
> in check_sbcs() to test each proposed byte/char individually ;)

My example is a bit bogus since iconv presumably can't handle a charset
where "0xff" and "0xff 0xf1" represent different characters, but the
point is there.  Yes, logically, it would be necessary to do 256
individual iconv() calls to accurately deduce a single-byte lookup table
for a particular mapping if one is available.

So it seems no optimisation is really possible here; what performance
problem is this code solving?  The overhead of iconv surely in
iconv_open() anyway: I think the right thing to do is remove the
check_sbcs() functions. 


View raw message