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 10:42:04


Jeff Squyres, le Mon 21 Sep 2009 10:04:21 -0400, a écrit :
> 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?

It's part of the language starting from C99 only. An application could
enable non-C99 mode where it becomes undefined, you can never know.

> Alternatively, this whole block in cpuset-bits.h could be wrapped in
> an "#ifndef restrict", right?:

That will work only if libraries possibly defining restrict and included
after hwloc do the same. You may argue that then it's their matter.
The only library I see defining restrict in my /usr/include does it
without #ifndef restrict, I'm not sure we want to fight this.

Anyway, #defining restrict in an installed header means that we'd have
to copy the autoconf stuff into it anyway as to my knowledge autoconf is
not flexible enough to only output that to some config.h.in header. That
hence doesn't buy ourself much compared to the current situation, except
that we'd have restrict instead of __hwloc_restrict. Risking conflicts
on the definition of restrict just for that seems too much to me.

> >> 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?

You may not be able to resolve the difference: depending on the kind of
detection of the compiler etc. etc. you may end up with restrict defined
to __restrict or to something else. And as soon as one improves its
detection of the compiler, the other(s!) will have to harmonize, etc.
Not really sustainable.

Samuel