[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]