On Sep 21, 2009, at 10:42 AM, Samuel Thibault wrote:

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.


That is a decade old, no?  ;-)

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


Ok, fair enough.

(Sorry -- I wasn't trying to be a jerk; just trying to be thorough...)

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.



Also fair enough. Is it possible that our use of restrict in cpuset- bits.h could come to a conclusion that is different than the underlying compiler (e.g., the underlying compiler needs __restrict)? I'm somewhat dubious of that this could happen, though -- don't all modern compilers support "restrict"? (I have not looked into this recently myself; all that data has been swapped out of my brain...)

Alternatively, is the restrict optimization really worth it here? If there are potential incompatibilities, perhaps the easiest answer is just to remove its use...?

--
Jeff Squyres
jsquy...@cisco.com

Reply via email to