By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,257 Members | 928 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,257 IT Pros & Developers. It's quick & easy.

restrict keyword questions

P: n/a
Restrict keyword questions

How far does the guarantee that an object is not accessed through another
pointer go? I mean, all examples I have seen are simple stuff like:

int f (int *restrict x, int *restrict y)
*x = 0;
*y = 1;
return *x;

Ok, the "return *x" can be optimised to "return 0" in this case, but what
happens if we add a function call:

int f (int *restrict x, int *restrict y)
*x = 0;
*y = 1;
return *x;

Does the guarantee that the x object is not modified persist? I mean
my_black_box_of_pain() could easily modify the memory area x points to. Now,
if the guarantee persists, then one should probably never use the restrict
keyword except when optimising very simple self-contained functions (i.e. no
calls to other functions). Because trying to ensure that all functions
called by a function which uses restrict parameters, and the functions
called by those functions etc. do not violate the contract is a recipe for
disaster. It so easy to introduce a bug there it is almost silly.
If the guarantee does NOT persist the restrict keyword is almost useless,
because you rarely see a C function which doesn't call other functions.
One way or the other, the restrict keyword seems to be for special interest
groups only. Right or not?

BTW, does the restrict keyword actually guarantee "mem area not modified
through another pointer" or not.
I wonder because I have heard different claims. I searched this group and
people here seem to think that restrict actually makes guarantees about the
object the restricted pointer points to (i.e. the mem area). However, this

Seems to contradict these claims. Quotes
The restrict keyword does not declare that the object being pointed to is
completely without aliases, only that the addresses that are loaded and
stored from are unaliased.

Memory windows can overlap and still be non-aliased.

Now think of something like

int foo(int * restrict a, int * restrict b) {
a[1] = 20;
*b = 10;
return a[1];

foo(x, &x[1]);

a and b are not aliased here because they point to different addresses i.e.
the restrict requirements are met, at least according to that article. The
memory windows overlap but that is supposed to be ok..

I am definitely confused now..

Mar 29 '08 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.