[solved] How to portably use restrict (or __restrict or __restrict__)

cmtptr · 2011-11-03 14:58:22

I've been working on a project that I intend to release as open source once it's mature enough to be usable. So far, I've been happily coding away using the restrict qualifier in the following fashion:

1. In the Makefile I add to CFLAGS, "-DRESTRICT=__restrict__"
2. In my code, when I want to use restrict I use the RESTRICT macro:
int someFunc(MyStruct *RESTRICT a, const char *RESTRICT str);

The rationale behind this was that it would be easy to control the expansion of RESTRICT from the Makefile, and so would make my project more easily portable. Then, I just now realized how stupid this was: being that my project is compiled as a shared object library, some of my headers will get installed on the target system. These headers define functions using my RESTRICT macro... which is not going to be defined when a user #includes them.

So how does one properly use restrict and still be compatible with pre-C99 user code? I was using __restrict__, which is a GCC extension, yet I notice that /usr/include/string.h uses __restrict, which according to this is defined in a header somewhere as a BSD thing (but maybe this isn't true for us?). Should I simply follow this example?

Thanks.

Last edited by cmtptr (2011-11-06 14:45:49)

tavianator · 2011-11-03 16:20:39

Something like this is how I'd do it:

#if __STDC_VERSION__ >= 199901L
  /* C99 or GNU C */
  #define PROJECT_RESTRICT restrict
#else
  #define PROJECT_RESTRICT
#endif

Your link is misleading, gcc knows __restrict as a synonym for __restrict__.

cmtptr · 2011-11-05 14:37:44

Then that's the route I'll go. I suppose it shouldn't matter if the library is compiled with "#define PROJECT_RESTRICT restrict" and the user code is compiled with "#define PROJECT_RESTRICT" since it's really the contents of the function that are dependent on the qualifier.

Thanks.

Arch Linux

#1 2011-11-03 14:58:22