apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: FW: apr_xlate_conv_buffer
Date Sat, 10 Nov 2001 20:50:58 GMT
"MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <madhusudan_mathihalli@hp.com> writes:

> 	I was just wondering if srclib/apr/i18n/unix/xlate.c :
> apr_xlate_conv_buffer() is supposed to accept "char *inbuf" or "unsigned
> char *inbuf".. It's being used differently in lotsa places - and it shows up
> as a warning when apr_md5.c is being compiled.. Do you guys think it's worth
> applying this patch ?.. I feel it's safer to do this (it atleast doesn't
> harm if the buffer actually contains unsigned char data).. 

it shouldn't matter anyway if buffer has unsigned or signed

Personally, I'd vote for keeping it "char *" instead of "unsigned char
*", since I think "char *" is most natural for folks who'd use the API.

I'd be curious about any comments in favor of making it "unsigned char
*".  That may more closely reflects that it is binary data, but
AFAIK it doesn't hurt anything to be "char *" and like I said before
"char *" seems very natural.  FWIW, X/Open chose "char" instead of
"unsigned char" for the base type of buffers handled by iconv().

Assuming it stays "char *"...

If there are some routines which for their own reasons need to pass
"unsigned char *" into the xlate routines, then those routines need to
typecast to "char *" so that they don't cause warnings to be generated
on systems where char is signed by default.

Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message