[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: restrict keyword defined as __restrict
From: |
Ralf Wildenhues |
Subject: |
Re: restrict keyword defined as __restrict |
Date: |
Tue, 1 Dec 2009 19:18:47 +0100 |
User-agent: |
Mutt/1.5.20 (2009-08-09) |
Hello Yann,
* Yann Droneaud wrote on Tue, Dec 01, 2009 at 03:19:00PM CET:
> With any C99 compliant compiler (gcc -std=c99 or clang), restrict
> keyword test always found "__restrict" instead of plain "restrict",
> eg. config.h contains: #define restrict __restrict
>
> But according to manual:
>
> "If the C compiler recognizes a variant spelling for the restrict
> keyword (__restrict, __restrict__, or _Restrict), then define restrict
> to that; this is more likely to do the right thing with compilers that
> support language variants where plain restrict is not a keyword.
> Otherwise, if the C compiler recognizes the restrict keyword, don't do
> anything. Otherwise, define restrict to be empty."
>
> and header config.h:
>
> "Define to the equivalent of the C99 'restrict' keyword, or to nothing
> if this is not supported. Do not define if restrict is supported
> directly."
>
> So, If i don't misunderstand, there should be no #define for restrict
> keyword in this case.
Yes, the documentation is wrong. The macro sources also has these:
# Determine whether the C/C++ compiler supports the "restrict" keyword
# introduced in ANSI C99, or an equivalent. Define "restrict" to the
alternate
# spelling, if any; these are more likely to work in both C and C++ compilers
of
# the same family, and in the presence of varying compiler options. If only
# plain "restrict" works, do nothing. Here are some variants:
[...]
# The order here caters to the fact that C++ does not require
# restrict.
for ac_kw in __restrict __restrict__ _Restrict restrict; do
which, I think, from a portability standpoint, should be the sensible
thing to do. Do you have a good use case that would be harmed by it?
Thanks,
Ralf