In the world of C99, a new monster has started to rear its ugly head - the keyword "restrict".<br><br>The idea is that in a conventional function, declared<br><br> void f(int *p, int *q);<br><br>the data pointed to by p /might/ overlap the data pointed to by q, wheras, if the function were declared as one of:
<br><br> void f(int * restrict p, int *q);<br> void f(int *p, int * restrict q);<br> void f(int * restrict p, int * restrict q);<br><br>then the data pointed to by p and q may /not/ overlap. The idea behind this is that the compiler can make better optimizations if it knows that. The problem is that now, in addition to const-correctness and volatile-correctness, you've now also got restrict-correctness to worry about. All your library function prototypes now need to change - strcpy(), strcat(), memcpy() (but not memmove()) just for starters!
<br><br>The thing is, the /intent/ is well-meaning. It's the implementation that's attrocious.<br><br>One day, someone's going to suggest this for D. So, now that we've got the const debate going in another thread, let's get this over with now, while the const debate is still fermenting.
<br><br>Here's what I suggest. First, restrict shall be assumed by default!<br><br> void f(int p[], int q[])<br> {<br> /* compiler may assume that no pointers passed as function parameters overlap */<br> }<br><br>
If you want overlapping pointers, you must instead do this:<br><br> void overlap f(int p[], int q[])<br> {<br> /* compiler must assume that all pointers passed as function parameters may overlap */<br> }<br><br>Yes, you lose some granularity. And yes, some existing code will develop undefined behavior until their prototypes are fixed. But /most/ functions won't need "norestrict", and so fixing those that do is likely to be the least-work option.
<br><br>