On Sep 21, 2009, at 9:40 AM, Samuel Thibault wrote:
> > So it should be ok to use AC_C_RESTRICT then, right?
> But then we can't expose restrict in installed headers since we don't
> know _whether_ and how it is defined.
Understood, but is that really our problem? "restrict" is part of the
C language, so portable applications should be able to handle it in
headers that they import, right?
Alternatively, this whole block in cpuset-bits.h could be wrapped in
an "#ifndef restrict", right?:
#if (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95))
# define __hwloc_restrict __restrict
# if defined restrict || __STDC_VERSION__ >= 199901L
# define __hwloc_restrict restrict
# define __hwloc_restrict
> > So I'd call it a "feature" if hwloc defines "restrict" to one thing
> > and then some other header file defines it to another. :-)
> That would make applications get a warning just because they are for
> instance using at the same time two libraries which both define
> to different things.
Yes -- and that's a Bad Thing. The differences between those two
libraries should be resolved, lest unexpected things occur because of
a mismatch between what the header exports (and might be redefined)
and what the compiled back-end library expects, no?
> > But then again, Autoconf has a *very strict* policy that generated
> > config.h files are supposed to be private to the application that it
> > is building. OMPI, for example, does *not* have mpi.h include our
> > generated config.h. Instead, our mpi.h has a small number of things
> > set from configure that are required (e.g., size of bool, etc.).
> That's why we have both autoheader-generated
> hwloc/include/private/config.h.in and manually-written
Um; right. I should have known that. :-)