This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] parallel build fix in libiberty

On Fri, 27 Jul 2001, J. Johnston wrote:
> Can you post the lines containing HAVE_WCHAR_H, HAVE_WCTYPE_H, and
> HAVE_BTOWC from the config.h file in your libiberty build directory?

Of course:

  /* Define if you have the <wchar.h> header file.  */
  #define HAVE_WCHAR_H 1

  /* Define if you have the <wctype.h> header file.  */
  #define HAVE_WCTYPE_H 1

  /* Define if you have the btowc function.  */
  /* #undef HAVE_BTOWC */

I believe the problem is

  # if !defined _LIBC
  typedef unsigned long int uintptr_t;
  # endif

in libiberty/regex.c which comes after our #inclusion of
<usr/include/sys/int_types.h> via <usr/include/sys/types.h>.
And int_types.h contains:

   * intptr_t and uintptr_t are signed and unsigned integer types large enough
   * to hold any data pointer; that is, data pointers can be assigned into or
   * from these integer types without losing precision.
  #if defined(_LP64) || defined(_I32LPx)
  typedef long                    intptr_t;
  typedef unsigned long           uintptr_t;
  typedef int                     intptr_t;
  typedef unsigned int            uintptr_t;

Unconditionally typedef-ing uintptr_t in application code seems rather
problematic to me.

Gerald "Jerry"

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]