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
#else
# if defined restrict || __STDC_VERSION__ >= 199901L
# define __hwloc_restrict restrict
# else
# define __hwloc_restrict
# endif
#endif
> > 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
> restrict
> 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
> hwloc/include/hwloc/config.h.in
>
Um; right. I should have known that. :-)
--
Jeff Squyres
jsquyres_at_[hidden]
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}