Re: new macro: AC_C_RESTRICT

[Jim Meyering]

"Akim Demaille" <address@hidden> wrote:

> Paul Eggert said:
>
>> Jim Meyering <address@hidden> writes:
>>
>>> Comments/suggestions?
>>
>> Looks good, thanks.  However, could you please check for "__restrict"
>> before "__restrict__"?  GCC supports either spelling, but "__restrict"
>> is shorter and older DEC Alpha C compilers support only "__restrict".
>> The handwritten "configure" script for MPlayer
>> <http://www.mplayerhq.hu> checks for "__restrict" first, so this
>> should be reliable.
>>
>> Also, please check for "_Restrict" as well.  That is the only spelling
>> supported by Sun WorkShop 6 update 2 C.
>
> Wow...  There is already that many different names...
>
>> Jim Meyering <address@hidden> writes:
>>
>>> I don't like the name very much, since it implies C-only support,
>>> while the macro is useful/necessary also with C++ compilers.
>>
>> Aren't the other AC_C_ macros in that camp too?
>
> Yes, indeed.  That's why I would like to suggest another framework,
> which I think Autoconf should have followed anyway: config.h should
> encode the result of the system audit only, and not the actions.
> In the present case, I would much prefer if the macro could AC_DEFINE
> HAVE_C_RESTRICT or HAVE_C___RESTRICT, or maybe AC_DEFINE
> C_RESTRICT as undefined, "restrict", "__restrict" etc. and then, let
> system.h make the #define.  Similarly, I don't think it was wise
> to have config.h #define the missing types.

Hi Akim!

I see your point and like the idea of separating them.  However,
a big advantage with the current, all-in-config.h, approach is that
it works even from lib/*.[ch] files.  In coreutils, all src/*.c
files include system.h, but many of those in lib/ come from glibc,
and having them include "system.h" would not be appropriate.

> Of course this is introducing a brand new interface in Autoconf.
> But I think it is a good one as:
> - it is cleaner for other languages
>   (remember the complaints of Fortran people who see such results
>   in their config.h)
> - it is cleaner for C vs. C++ etc.
>   (C_RESTRICT and CXX_RESTRICT are different, it is up to the user
>    to use them correctly).