|
From: | Paul Eggert |
Subject: | Re: Bug with AC_C_RESTRICT on non-GNU-C compiler when using GLIBC |
Date: | Mon, 22 Feb 2016 15:17:58 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |