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
jsquy...@cisco.com
