Jeff Squyres, le Mon 21 Sep 2009 12:31:41 -0400, a écrit : > 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? ;-)
Yes, but existing software tends to still not evolve. I'm still seeing software using the old termio interface while it dates at least back 1988. > (Sorry -- I wasn't trying to be a jerk; just trying to be thorough...) No problem. Actually, I had followed your reasoning at the time I wrote that part of the code, I'm just repeating what I've thought in my head at the time :) > 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 not sure to understand what you mean. What could happen is that gcc stops understanding __restrict while it has been understanding it since 2.95; I doubt that will ever happen. Another very low-probability possibility to get something wrong is if a compiler defines __STDC_VERSION__ to a value greater than 199901L but doesn't accept restrict; that would really be a compiler bug. The last possibility is restrict being #defined to something not being the standard restrict qualifier. I've just dropped the #if defined restrict part to avoid it, that's not a big loss. > Alternatively, is the restrict optimization really worth it here? Re-reading what we use it for at the moment, there is not many optimizations to be done, but now that I've removed the only case that could be problematic, it shouldn't be a problem. Samuel
