On 02/22/2016 01:46 PM, Dwight Guth wrote:
Currently there is a problem with the way the AC_C_RESTRICT macro behaves if you are using GLIBC with a C99-compliant compiler that does not define the __GNUC__ macro, but does define __restrict.
Which compiler is this, exactly? What does it define __restrict to?
I believe that glibc's behavior is also wrong in this case, but even if glibc were to do the correct thing and define __restrict to the keyword, you would still have a bug in autoconf caused by a circular define. You can't see this in the case with gcc, but if another compiler were to define __restrict as a macro but not a keyword, this would then cause compilation to crash whenever the __restrict keyword is used, because the circular define would prevent macro replacement, __restrict would not be a keyword.
Sorry, I'm not getting the scenario. Another compiler would define a macro for __restrict? Why would it bother? It can implement __restrict directly.
I'm pretty sure that the way you want to handle this is that if __restrict is preprocessed into "foo", then config.h should define "restrict" as "foo" instead of as "__restrict".
We have no portable way to deduce what a macro expands to, for arbitrary compilers.
Perhaps we can do something for your particular case, but we'd need to know more about it.
