You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <ma...@hp.com> on 2001/11/06 03:12:40 UTC

FW: apr_xlate_conv_buffer

Oops.. 'had sent it to the wrong list..

-Madhu


-----Original Message-----
From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
[mailto:madhusudan_mathihalli@hp.com]
Sent: Monday, November 05, 2001 6:10 PM
To: 'dev@httpd.apache.org'
Subject: apr_xlate_conv_buffer


Hi,
	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).. 

Ofcourse, this patch is not complete (it doesn't fully take care of
converting all the local buffers in apr_xlate_conf_buffer())..

Thx
-Madhu

Index: apr_xlate.h
===================================================================
RCS file: /home/cvspublic/apr/include/apr_xlate.h,v
retrieving revision 1.16
diff -u -r1.16 apr_xlate.h
--- apr_xlate.h 2001/08/24 17:55:45     1.16
+++ apr_xlate.h 2001/11/06 01:46:56
@@ -144,9 +144,9 @@
  *                      Output: the amount of the output buffer not yet
used
  */
 APR_DECLARE(apr_status_t) apr_xlate_conv_buffer(apr_xlate_t *convset, 
-                                                const char *inbuf, 
+                                                const unsigned char *inbuf,

                                                 apr_size_t *inbytes_left, 
-                                                char *outbuf,
+                                                unsigned char *outbuf,
                                                 apr_size_t *outbytes_left);
 
 /* @see apr_file_io.h the comment in apr_file_io.h about this hack */

Index: xlate.c
===================================================================
RCS file: /home/cvspublic/apr/i18n/unix/xlate.c,v
retrieving revision 1.23
diff -u -r1.23 xlate.c
--- xlate.c     2001/02/25 20:46:49     1.23
+++ xlate.c     2001/11/06 01:47:41
@@ -282,8 +282,10 @@
     return APR_SUCCESS;
 } 
 
-apr_status_t apr_xlate_conv_buffer(apr_xlate_t *convset, const char *inbuf,
-                                   apr_size_t *inbytes_left, char *outbuf,
+apr_status_t apr_xlate_conv_buffer(apr_xlate_t *convset,
+                                   const unsigned char *inbuf,
+                                   apr_size_t *inbytes_left,
+                                   unsigned char *outbuf,
                                    apr_size_t *outbytes_left)
 {
     apr_status_t status = APR_SUCCESS;

Re: FW: apr_xlate_conv_buffer

Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:

> 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.

I have't seen any preferences from anybody...  Suppose we change
apr_md4 and apr_md5, which pass in unsigned char buffers, to cast to
"char *" to avoid warnings on some platforms.  Does that resolve the
issue for you, or do you still prefer "unsigned char *" for the xlate
stuff? 

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

Re: FW: apr_xlate_conv_buffer

Posted by Jeff Trawick <tr...@attglobal.net>.
"MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <ma...@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:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...