You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by gs...@apache.org on 2003/01/21 21:27:58 UTC
cvs commit: apr-util/crypto apr_md5.c
gstein 2003/01/21 12:27:58
Modified: include apr_md5.h
crypto apr_md5.c
Log:
Callers just have blocks of bytes specified by a ptr/len pair.
Invariably, they will not be "unsigned char" buffers, so let's fix the
typing here.
Revision Changes Path
1.4 +2 -2 apr-util/include/apr_md5.h
Index: apr_md5.h
===================================================================
RCS file: /home/cvs/apr-util/include/apr_md5.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- apr_md5.h 1 Jan 2003 00:02:20 -0000 1.3
+++ apr_md5.h 21 Jan 2003 20:27:58 -0000 1.4
@@ -145,7 +145,7 @@
* @param inputLen The length of the next message block
*/
APU_DECLARE(apr_status_t) apr_md5_update(apr_md5_ctx_t *context,
- const unsigned char *input,
+ const void *input,
apr_size_t inputLen);
/**
@@ -164,7 +164,7 @@
* @param inputLen The length of the message block
*/
APU_DECLARE(apr_status_t) apr_md5(unsigned char digest[MD5_DIGESTSIZE],
- const unsigned char *input,
+ const void *input,
apr_size_t inputLen);
/**
1.4 +4 -2 apr-util/crypto/apr_md5.c
Index: apr_md5.c
===================================================================
RCS file: /home/cvs/apr-util/crypto/apr_md5.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- apr_md5.c 1 Jan 2003 00:02:18 -0000 1.3
+++ apr_md5.c 21 Jan 2003 20:27:58 -0000 1.4
@@ -229,9 +229,10 @@
* context.
*/
APU_DECLARE(apr_status_t) apr_md5_update(apr_md5_ctx_t *context,
- const unsigned char *input,
+ const void *_input,
apr_size_t inputLen)
{
+ const unsigned char *input = _input;
unsigned int i, idx, partLen;
#if APR_HAS_XLATE
apr_size_t inbytes_left, outbytes_left;
@@ -348,9 +349,10 @@
/* MD5 in one step (init, update, final)
*/
APU_DECLARE(apr_status_t) apr_md5(unsigned char digest[MD5_DIGESTSIZE],
- const unsigned char *input,
+ const void *_input,
apr_size_t inputLen)
{
+ const unsigned char *input = _input;
apr_md5_ctx_t ctx;
apr_status_t rv;
Re: cvs commit: apr-util/crypto apr_md5.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:15 PM 1/21/2003, Justin Erenkrantz wrote:
>--On Tuesday, January 21, 2003 8:27 PM +0000 gstein@apache.org wrote:
>
>> @@ -145,7 +145,7 @@
>> * @param inputLen The length of the next message block
>> */
>> APU_DECLARE(apr_status_t) apr_md5_update(apr_md5_ctx_t *context,
>>- const unsigned char
>*input,
>>+ const void *input,
>> apr_size_t inputLen);
>> /**
>
>My hunch is that this breaks binary compatibility.
How?
>Do we need to
>bump a version number or do some magic to make our binary compat
>people happy? -- justin
Not if it doesn't. I can't conceive of a platform which would. We are
already casting between point types to byte buffers, it's just a simple
pointer. No incompatibility.
Bill
Re: cvs commit: apr-util/crypto apr_md5.c
Posted by Ben Laurie <be...@algroup.co.uk>.
Branko Čibej wrote:
> Justin Erenkrantz wrote:
>
>
>>--On Tuesday, January 21, 2003 8:27 PM +0000 gstein@apache.org wrote:
>>
>>
>>> @@ -145,7 +145,7 @@
>>> * @param inputLen The length of the next message block
>>> */
>>> APU_DECLARE(apr_status_t) apr_md5_update(apr_md5_ctx_t *context,
>>>- const unsigned char
>>
>>*input,
>>
>>
>>>+ const void *input,
>>> apr_size_t inputLen);
>>> /**
>>
>>
>>My hunch is that this breaks binary compatibility. Do we need to
>>bump a version number or do some magic to make our binary compat
>>people happy? -- justin
>>
>
> It shouldn't. It could only break binary compatibility on systems where
> the representation and/or size of a void* is different than the
> representation of a char*, and I bet APR doesn't work on such systems.
The representation is not _allowed_ to be different.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: cvs commit: apr-util/crypto apr_md5.c
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> --On Tuesday, January 21, 2003 8:27 PM +0000 gstein@apache.org wrote:
>
>> @@ -145,7 +145,7 @@
>> * @param inputLen The length of the next message block
>> */
>> APU_DECLARE(apr_status_t) apr_md5_update(apr_md5_ctx_t *context,
>> - const unsigned char
>
> *input,
>
>> + const void *input,
>> apr_size_t inputLen);
>> /**
>
>
> My hunch is that this breaks binary compatibility. Do we need to
> bump a version number or do some magic to make our binary compat
> people happy? -- justin
>
It shouldn't. It could only break binary compatibility on systems where
the representation and/or size of a void* is different than the
representation of a char*, and I bet APR doesn't work on such systems.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr-util/crypto apr_md5.c
Posted by Justin Erenkrantz <je...@apache.org>.
--On Tuesday, January 21, 2003 8:27 PM +0000 gstein@apache.org wrote:
> @@ -145,7 +145,7 @@
> * @param inputLen The length of the next message block
> */
> APU_DECLARE(apr_status_t) apr_md5_update(apr_md5_ctx_t *context,
>- const unsigned char
*input,
>+ const void *input,
> apr_size_t inputLen);
> /**
My hunch is that this breaks binary compatibility. Do we need to
bump a version number or do some magic to make our binary compat
people happy? -- justin
Re: cvs commit: apr-util/crypto apr_md5.c
Posted by Jeff Trawick <tr...@attglobal.net>.
gstein@apache.org wrote:
> gstein 2003/01/21 12:27:58
>
> Modified: include apr_md5.h
> crypto apr_md5.c
> Log:
> Callers just have blocks of bytes specified by a ptr/len pair.
> Invariably, they will not be "unsigned char" buffers, so let's fix the
> typing here.
nice!