bug-autoconf
[Top][All Lists]
Advanced

[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




reply via email to

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