httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: [PATCH] ap_xlate_* routine for SBCS to convert a char
Date Wed, 10 May 2000 03:59:40 GMT
> On Tue, 9 May 2000, Jeff Trawick wrote:
> > In some situations, the APR client "knows" that it is translating
> > between a pair of SBCS character sets.  Having a lean function to call
> > in this situation to translate a character makes for more readable
> > code and a slight speed improvement over a function that would handle
> > multibyte characters on input and/or output.
> > 
> > ap_xlate_conv_byte() takes a single-byte character as input and
> > returns either the single-byte translated character or -1 (can't
> > convert).  It doesn't return ap_status_t because that would spoil the
> > interface.
> 
> Is it important to have a buffer conversion, rather than one character at
> a time?

I don't know what you mean.

> Is there actually a possible failure for a specific character? 

What happens when translating from US-ASCII (whatever 7-bit ASCII is
called) to some other character set when the input character is 0xF0?
The input is invalid, but I don't know when it might be recognized as
an error.

>                                                                Or in other
> words, can you do an up-front test for success/fail and then blindly
> convert all characters? (without checking for errors)  That would toss the
> ap_int32_t and error checks; it would be an unsigned char return (no
> casting!) and no err checks.

I thought about skipping the error check and blindly assuming that I
have the sbcs array (and I doubt that *I* would normally check for -1
after a call to ap_xlate_conv_byte()).  I didn't want to eliminate
the possibility for future (smarter) conversion code to be able to
signal an error.  

I'm still leaning toward keeping the error return code.  Even if the
caller doesn't check it, it can be helpful.  Consider the case where
a utility routine calls ap_xlate_conv_byte() using a translation
handle provided by the caller.  It thinks it converts bytes here and
there, actually storing 0xFF.  When debugging the problem, all
translated bytes would have that value.  If ap_xlate_conv_byte()
blindly accesses the sbcs array, it will use low core (i.e., addresses
0 and up) as a conversion table :)  On a certain system I'm familar with,
the block 0-255 is always-mapped storage, which will then be used as a
translation table.  When debugging the problem, no such 0xFF pattern
will be seen.  On most (?) systems, accessing zero will be very
painful.

Hmmm... more thought required...

> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 
> 

Thanks,

Jeff

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message