This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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
> 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
> detection of the compiler etc. etc. you may end up with restrict
> 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...?