Hello Yann, * Yann Droneaud wrote on Tue, Dec 01, 2009 at 03:19:00PM CET: > With any C99 compliant compiler (gcc -std=c99 or clang), restrict > keyword test always found "__restrict" instead of plain "restrict", > eg. config.h contains: #define restrict __restrict > > But according to manual: > > "If the C compiler recognizes a variant spelling for the restrict > keyword (__restrict, __restrict__, or _Restrict), then define restrict > to that; this is more likely to do the right thing with compilers that > support language variants where plain restrict is not a keyword. > Otherwise, if the C compiler recognizes the restrict keyword, don't do > anything. Otherwise, define restrict to be empty." > > and header config.h: > > "Define to the equivalent of the C99 'restrict' keyword, or to nothing > if this is not supported. Do not define if restrict is supported > directly." > > So, If i don't misunderstand, there should be no #define for restrict > keyword in this case.
Yes, the documentation is wrong. The macro sources also has these: # Determine whether the C/C++ compiler supports the "restrict" keyword # introduced in ANSI C99, or an equivalent. Define "restrict" to the alternate # spelling, if any; these are more likely to work in both C and C++ compilers of # the same family, and in the presence of varying compiler options. If only # plain "restrict" works, do nothing. Here are some variants: [...] # The order here caters to the fact that C++ does not require # restrict. for ac_kw in __restrict __restrict__ _Restrict restrict; do which, I think, from a portability standpoint, should be the sensible thing to do. Do you have a good use case that would be harmed by it? Thanks, Ralf