Re: Bug with AC_C_RESTRICT on non-GNU-C compiler when using GLIBC

[Dwight Guth]

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.