• Janice Caron (37/37) Sep 11 2007 Content-Disposition: inline
• Jascha Wetzel (4/53) Sep 11 2007 imho, having default functionality that might result in undefined

"Janice Caron" <caron800 googlemail.com> writes:

Content-Disposition: inline

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.

Jascha Wetzel <"[firstname]" mainia.de> writes:

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.