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
