When to use restrict and when not to

Don McCaughey picture Don McCaughey · May 7, 2009 · Viewed 7.9k times · Source

I have a general understanding of restrict but I'm hoping to clarify some fine points. I have a function that reads a null-terminated string from one buffer and writes out a URL encoded version in another buffer. The function has this signature (currently without restrict):

char const *StringUrlEncode(char const *unencoded, 
                            char *encoded,
                            char *encodedEnd);

unencoded is my null-terminated source string. The destination buffer is represented by encoded and encodedEnd, where encoded points to the first char in the buffer and encodedEnd points to the first char after the buffer, i.e. the function will write chars up to but not including the location pointed to by encodedEnd -- this is your basic begin/end iterator pair if you're familiar with C++ STL conventions.

If I add restrict to this function, should it only be applied to the first two parameters:

char const *StringUrlEncode(char const *restrict unencoded, 
                            char *restrict encoded,
                            char *encodedEnd);

or is there some benefit I'm not understanding by adding it to all three parameters?

I can see that making the input and output buffers restrict helps the compiler know that they don't overlap. But since the last parameter, encodedEnd, is only used to mark the end of the output buffer, I'm thinking that restrict wouldn't really be any help to the compiler here (though I assume it wouldn't hurt, other than adding unnecessary noise to the function declaration).

Answer

Dan Olson picture Dan Olson · May 7, 2009

Try Mike Acton's article here (old link). Restrict is frightening because of both the performance implications of not using it and the consequences of using it incorrectly.

In your case, it sounds like you could safely apply restrict to all three pointers as none alias the same memory area. However there is going to be little to no performance benefit from using it on the third pointer.