restrict sucks

[Jascha Wetzel]

Janice Caron wrote:
> In the world of C99, a new monster has started to rear its ugly head - 
> the keyword "restrict".
> 
> The idea is that in a conventional function, declared
> 
>  void f(int *p, int *q);
> 
> the data pointed to by p /might/ overlap the data pointed to by q, 
> wheras, if the function were declared as one of:
> 
>  void f(int * restrict p, int *q);
>  void f(int *p, int * restrict q);
>  void f(int * restrict p, int * restrict q);
> 
> 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!
> 
> The thing is, the /intent/ is well-meaning. It's the implementation 
> that's attrocious.
> 
> 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.
> 
> Here's what I suggest. First, restrict shall be assumed by default!
> 
>  void f(int p[], int q[])
>  {
>      /* compiler may assume that no pointers passed as function 
> parameters overlap */
>  }
> 
> If you want overlapping pointers, you must instead do this:
> 
>  void overlap f(int p[], int q[])
>  {
>      /* compiler must assume that all pointers passed as function 
> parameters may overlap */
>  }
> 
> 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.
> 

imho, having default functionality that might result in undefined 
behaviour, is a no-go. this produces a lot more headaches than benefit. 
i agree that the fine granularity is probably not needed, though.