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

[Bernhard Reutner-Fischer <rep dot dot dot nop at gmail dot com>]

On 5 April 2013 08:42, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
>
> On Fri, Apr 5, 2013 at 10:37 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > 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/interception_type_test.cc
> >> +++ b/libsanitizer/interception/interception_type_test.cc
> >> @@ -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?


It does guarantee that, let me see if i can drop that  && defined
__off64_t_defined.
>
> >
> >> --- a/libsanitizer/sanitizer_common/sanitizer_allocator.cc
> >> +++ b/libsanitizer/sanitizer_common/sanitizer_allocator.cc
> >> @@ -9,11 +9,13 @@
> >>  // run-time libraries.
> >>  // This allocator that is used inside run-times.
> >>  //===----------------------------------------------------------------------===//
> >> +
> >> +#include <features.h>
>
> I overlooked this.
> The sanitizer files (other than *_linux.cc and such) may not include
> *any* system header files.
> We've been there, it cost us lots of pain and lots of work to get rid of.


So how do you suggest i should deal with it then?
I do not have a CPP token inside of the compiler to denote the libc
type, AFAICS.

thanks,
>
>
> --kcc
>
>
> >
> > 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.
> >
> >         Jakub