[PATCH, libiberty] correct md5_process_bytes with unaligned pointers

[PATCH, libiberty] correct md5_process_bytes with unaligned pointers

[Pierre Vittet]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

Hello,

The patch is the result of the following threads:

Here is a patch correcting md5_process_bytes when we are in the case of
unaligned pointers.A pair of brace was missing, leading the buffer to be
shift 2 times losing a part of its content.


The patch also remove a preprocessor #if testing if
_STRING_ARCH_unaligned is defined. This symbol is never defined in gcc
and could be only used in CFLAGS. Looking at the code, it does not looks
usefull to define it (and it is only tested on libiberty/md5.c and
libiberty/sha1.c), as we already check the pointer alignement, so
removing it clean the code. I searched on google, and it does not looks
to be used. Does anyone want it or thing that it should not be removed?

Ok for trunk ?

Thanks!

Pierre Vittet

PS: I also write a small gcc plugin, allowing to easily test
md5_process_bytes, if can change your environment in a way where the
pointer buffer is not aligned, you should get the bug.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: md5_process_bytes_add_brace-178905.diff --]
[-- Type: text/x-patch; name="md5_process_bytes_add_brace-178905.diff", Size: 915 bytes --]

Index: libiberty/md5.c
===================================================================
--- libiberty/md5.c	(révision 178905)
+++ libiberty/md5.c	(copie de travail)
@@ -227,7 +227,6 @@ md5_process_bytes (const void *buffer, size_t len,
   /* Process available complete blocks.  */
   if (len > 64)
     {
-#if !_STRING_ARCH_unaligned
 /* To check alignment gcc has an appropriate operator.  Other
    compilers don't.  */
 # if __GNUC__ >= 2
@@ -244,10 +243,11 @@ md5_process_bytes (const void *buffer, size_t len,
             len -= 64;
           }
       else
-#endif
-      md5_process_block (buffer, len & ~63, ctx);
-      buffer = (const void *) ((const char *) buffer + (len & ~63));
-      len &= 63;
+	{
+	  md5_process_block (buffer, len & ~63, ctx);
+	  buffer = (const void *) ((const char *) buffer + (len & ~63));
+	  len &= 63;
+	}
     }
 
   /* Move remaining bytes in internal buffer.  */

[-- Attachment #3: md5_process_bytes_add_brace-178905.ChangeLog --]
[-- Type: text/plain, Size: 140 bytes --]

2011-09-16  Pierre Vittet  <piervit@pvittet.com>

	* md5.c (md5_process_bytes): Remove unused _STRING_ARCH_unaligned, add
	missing braces.


[-- Attachment #4: micro_plugin_md5.tar.gz --]
[-- Type: application/x-gzip, Size: 878 bytes --]

Re: [PATCH, libiberty] correct md5_process_bytes with unaligned pointers

[Basile Starynkevitch]

On Fri, 16 Sep 2011 14:46:57 +0200
Pierre Vittet <piervit@pvittet.com> wrote:

> Hello,
[...]

> The patch also remove a preprocessor #if testing if
> _STRING_ARCH_unaligned is defined. This symbol is never defined in gcc
> and could be only used in CFLAGS. Looking at the code, it does not looks
> usefull to define it (and it is only tested on libiberty/md5.c and
> libiberty/sha1.c), as we already check the pointer alignement, so
> removing it clean the code. I searched on google, and it does not looks
> to be used. Does anyone want it or thing that it should not be removed?
> 
> Ok for trunk ?


I can't formally approve this patch, but I do hope it will be reviewed and approved soon. 

See http://gcc.gnu.org/ml/gcc-help/2011-09/msg00126.html
and http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00963.html
and http://groups.google.com/group/gcc-melt/browse_thread/thread/292c394fea5089c7

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: [PATCH, libiberty] correct md5_process_bytes with unaligned pointers

[Pierre Vittet]

Hello,

Ping!
I would like to get a return on this patch. I don't know quite well the
status of libiberty in GNU, please if I must this patch on another
mailing list, please say me on which.

Thanks!

Pierre Vittet