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]
Other format: [Raw text]

Re: [PATCH 3/3] libsanitizer: add LFS guards

On Thu, Apr 04, 2013 at 09:53:30PM +0200, Bernhard Reutner-Fischer wrote:
> uClibc can be built without Largefile support, add the corresponding
> guards. uClibc does not have __libc_malloc()/__libc_free(), add guard.

Ugh, this is very ugly.  In addition to the stuff mentioned by Konstantin
that this really should go into upstream first:

> --- a/libsanitizer/interception/
> +++ b/libsanitizer/interception/
> @@ -22,7 +22,7 @@ COMPILER_CHECK(sizeof(SSIZE_T) == sizeof(ssize_t));
>  COMPILER_CHECK(sizeof(PTRDIFF_T) == sizeof(ptrdiff_t));
>  COMPILER_CHECK(sizeof(INTMAX_T) == sizeof(intmax_t));
> -#ifndef __APPLE__
> +#if !defined __APPLE__ && (defined __USE_LARGEFILE64 && defined __off64_t_defined)

Using the internal implementation detail of __USE_LARGEFILE64 is very ugly,
but why __off64_t_defined?  That macro is there just to avoid typedefing it
multiple times, if you include more than one of the sys/types.h, stdio.h and
unistd.h headers.  If you include any of those headers, it will be defined
when __USE_LARGEFILE64 is defined.  Or is uClibc not guaranteeing that?

> --- a/libsanitizer/sanitizer_common/
> +++ b/libsanitizer/sanitizer_common/
> @@ -9,11 +9,13 @@
>  // run-time libraries.
>  // This allocator that is used inside run-times.
>  //===----------------------------------------------------------------------===//
> +
> +#include <features.h>

I'm afraid features.h won't exist on many targets, it isn't a standard
header.  I'd say you want to include some standard header instead (stdio.h?)
or guard this.


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