Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] last API possible changes
From: Samuel Thibault (samuel.thibault_at_[hidden])
Date: 2009-09-21 09:15:06


Jeff Squyres, le Mon 21 Sep 2009 08:51:35 -0400, a écrit :
> On Sep 21, 2009, at 8:44 AM, Samuel Thibault wrote:
>
> >> FWIW, is there a reason we're not using AC_C_RESTRICT in
> >> configure.ac? This allows you to use "restrict" in C code
> >everywhere;
> >> it'll be #defined to something acceptable by the compiler if
> >> "restrict" itself is not.
> >
> >Our __hwloc_restrict macro is actually a copy/paste of AC_C_RESTRICT's
> >tinkering.

Ah, wait, no, I'm mistaking with something else in another project.
Looking closer, this definition is mine.

Note btw that the autoconf license makes an exception for code output
from autoconf scripts, the GPL doesn't apply to them, there is
“unlimited permission to copy, distribute, and modify” it.

> >The problem is precisely that AC_C_RESTRICT provides "restrict",
> >and not another keyword, so that using it in installed headers
> >may conflict with other headers' tinkering about restrict. Yes,
> >configure is meant to detect such kind of things, but it can not
> >know which variety of headers the user will want to include from
> >its application, and any of them could want to define restrict to
> >something else.
>
> Would it ever be sane to use one value of restrict in hwloc and a
> different value in an upper-level application?

That's not a problem since it's just an optimization & validity checking
qualifier.

Samuel