The compiler I am working with is a compiler I am developing designed to dynamically analyze C code (you can read more about it at http://runtimeverification.com/match if you are interested, although it's not 100% relevant to this discussion). We use GLIBC's header files, but we do not define the __GNUC__ macro. This causes <sys/cdefs.h> to include the following line:
# define __restrict /* Ignore */ I am working separately with the glibc people to try to get a patch submitted that allows __restrict to be defined as restrict if __STDC_VERSION__ is at least 199901. This seems like a reasonable solution to me, however, when combined with the behavior of AC_C_RESTRICT, this leads to a circular definition that causes both of these macro replacements to be cancelled. Since our compiler does not actually support the __restrict keyword (it's merely defined as a macro by glibc), this causes a syntax error to occur. Technically speaking, this is a valid C99 implementation and the C program was valid C99 until autoconf came along and tried to make it more portable. You are I suppose correct insofar as we could define __restrict as a keyword equivalent to restrict. In fact that is probably what I am going to have to do if we can't come to some kind of consensus here. But it seems to me like it makes more sense for autoconf not to interfere with programs written in pure C99 in ways that make them not portable anymore. This is also consistent with the fact that the documentation generated in config.h for AC_C_RESTRICT says "Do not define if restrict is supported directly." (although this documentation seems inconsistent with the online documentation, which correctly explains the current behavior). I found an old thread online talking about exactly this issue, but the people discussing it didn't have a concrete example where this behavior fell apart. I just wanted to bring this up again because it fell apart for us.
