Patchwork [libiberty's,include] : Fixes PR 39064 and partial PR 54620

login
register
mail settings
Submitter Kai Tietz
Date Jan. 30, 2013, 2:48 p.m.
Message ID <CAEwic4ZAr1krhH3b=MbsM4f1RKqZJUz4UiTmUubk-Vhrtd74nw@mail.gmail.com>
Download mbox | patch
Permalink /patch/216933/
State New
Headers show

Comments

Kai Tietz - Jan. 30, 2013, 2:48 p.m.
2013/1/30 Ian Lance Taylor <iant@google.com>:
> On Wed, Jan 30, 2013 at 2:53 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>
>> this patch fixes for targets with sys/types.h the issue that wrong
>> assumptions about pointer-sizes are used.
>> Instead it uses uintptr_t/intptr_t.
>>
>> ChangeLog /include
>>
>> 2013-01-30  Kai Tietz  <ktietz@redhat.com>
>>
>>         PR other/54620
>>         PR target/39064
>>         * md5.h: Include sys/types.h if HAVE_SYS_TYPES_H
>>         is defined.
>>         * sha1.h: Likewise.
>>
>> Tested for x86_64-unknown-linux-gnu, x86_64-w64-mingw32, and
>> i686-w64-mingw32.  Ok for apply?
>>
>> Regards,
>> Kai
>>
>> Index: md5.h
>> ===================================================================
>> --- md5.h       (Revision 195288)
>> +++ md5.h       (Arbeitskopie)
>> @@ -36,7 +36,7 @@
>>     the resulting executable.  Locally running cross-compiled executables
>>     is usually not possible.  */
>>
>> -#ifdef _LIBC
>> +#if defined (_LIBC) || defined (HAVE_SYS_TYPES_H)
>>  # include <sys/types.h>
>>  typedef u_int32_t md5_uint32;
>>  typedef uintptr_t md5_uintptr;
>> Index: sha1.h
>> ===================================================================
>> --- sha1.h      (Revision 195288)
>> +++ sha1.h      (Arbeitskopie)
>> @@ -35,7 +35,7 @@
>>     the resulting executable.  Locally running cross-compiled executables
>>     is usually not possible.  */
>>
>> -#ifdef _LIBC
>> +#if defined (_LIBC) || defined (HAVE_SYS_TYPES_H)
>>  # include <sys/types.h>
>>  typedef u_int32_t sha1_uint32;
>>  typedef uintptr_t sha1_uintptr;
>
>
>
> This code is intended to be highly portable.  I don't have a problem
> with uintptr_t, but I'm not certain that <sys/types.h> on all systems
> defines u_int32_t.
>
> Ian

Yes, this is a valid point.  The (u)int??_t types aren't necessarily
declared by including sys/types.h.  So what's about the following
patch.  If stdint.h header is present, then we should include it and
then we can assume that the (u)int??_t types are present.
Rainer Orth - Jan. 30, 2013, 2:56 p.m.
Kai Tietz <ktietz70@googlemail.com> writes:

> Yes, this is a valid point.  The (u)int??_t types aren't necessarily
> declared by including sys/types.h.  So what's about the following
> patch.  If stdint.h header is present, then we should include it and
> then we can assume that the (u)int??_t types are present.

This is wrong: <stdint.h> provides e.g. uint32_t, but not u_int32_t.
The latter is a BSDism.

	Rainer

Patch

Index: md5.h
===================================================================
--- md5.h	(Revision 195572)
+++ md5.h	(Arbeitskopie)
@@ -36,7 +36,11 @@ 
    the resulting executable.  Locally running cross-compiled executables
    is usually not possible.  */

-#ifdef _LIBC
+#ifdef HAVE_STDINT_H
+#include <stdint.h>
+#endif
+
+#if defined (_LIBC) || (defined (HAVE_SYS_TYPES_H) && defined (HAVE_STDINT_H))
 # include <sys/types.h>
 typedef u_int32_t md5_uint32;
 typedef uintptr_t md5_uintptr;
Index: sha1.h
===================================================================
--- sha1.h	(Revision 195572)
+++ sha1.h	(Arbeitskopie)
@@ -35,7 +35,11 @@ 
    the resulting executable.  Locally running cross-compiled executables
    is usually not possible.  */

-#ifdef _LIBC
+#ifdef HAVE_STDINT_H
+#include <stdint.h>
+#endif
+
+#if defined (_LIBC) || (defined (HAVE_SYS_TYPES_H) && defined (HAVE_STDINT_H))
 # include <sys/types.h>
 typedef u_int32_t sha1_uint32;
 typedef uintptr_t sha1_uintptr;