const * restrict

[Thad Smith]

C99 Example 3 in 6.7.3.1 (formal definition of restrict) is as follows:

void h(int n, int * restrict p, int * restrict q, int * restrict r)
{
int i;
for (i = 0; i < n; i++)
p[i] = q[i] + r[i];
}

It further states that "In particular, if a and b are disjoint arrays, a
call of the form h(100, a, b, b) has defined behavior, because array b
is not modified within function h."

Given only the prototype of h(), the allowance of q and r overlapping is
not apparent. If h had been defined and prototyped as

void h(int n, int * restrict p, const int * restrict q, const int *
restrict r);

the programmer could see from the prototype that the function does not
modify via q or r. Is it a general rule, then, that the caller can
allow restrict pointer parameters to designate overlapping areas if all
the types pointed to are const-qualified?

Thad

[Nick Maclaren]

In article <3BD72511...@acm.org>, Thad Smith <Thad...@acm.org> wrote:
>
>the programmer could see from the prototype that the function does not
>modify via q or r. Is it a general rule, then, that the caller can
>allow restrict pointer parameters to designate overlapping areas if all
>the types pointed to are const-qualified?

A general rule, yes. But there are dirty tricks by which C allows
the const qualification to be legally 'lost' and, in the absence of
the restrict qualifier, it is then permitted to update an object
pointed to by the de-consted pointer. If you do THAT, then the
parameters may not overlap.

Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679

[Francis Glassborow]

In article <3BD72511...@acm.org>, Thad Smith <Thad...@acm.org>

writes

>the programmer could see from the prototype that the function does not
>modify via q or r. Is it a general rule, then, that the caller can
>allow restrict pointer parameters to designate overlapping areas if all
>the types pointed to are const-qualified?

Well that might help. However the important requirement is that if you
write through a restrict pointer, no other pointer in scope may point
into that memory. If you read through a restrict pointer nothing else in
scope should write to that memory.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----

[Christian Bau]

"restrict" itself has nothing to do with overlapping arrays, they only
come into play as a consequence of the definition of restrict.

If p is a restrict pointer then:
It is illegal to access an object through p and modify it through other
means.
It is illegal to modify an object through p and access it through other
means.

If i is a const restrict pointer then:
It is illegal to access an object through p and modify it by any means.

If an argument is a const restrict pointer then the function cannot
modify anything through this pointer, because that would always be
undefined behaviour, no matter what arguments the caller passes. As a
reasonable programmer, you expect that another programmer could write a
function that has defined behaviour if called correctly and undefined
behaviour if called incorrectly, but a function modifying objects
through a const restrict pointer cannot be correctly. If a function has
two or more const restrict pointer arguments, then it cannot modify any
object through any of those pointers, so it cannot ever make a
difference if two or more of your arguments are overlapping.

That means your idea is correct: If a function has two or more const
restrict pointer arguments, then it is always legal to pass overlapping
arrays to the function (except if the function has been written in such
a way that it invokes undefined behaviour anyway, no matter what
arguments you pass).

Now your original example: If I change this to

> void h2(int n, int * restrict p, int * restrict q, int * restrict r)

> {
> int i;
> for (i = 0; i < n; i++)

> p[i] = q[i] = r[i] = 0;
> }

then obviously these arrays must not be overlapping. h can be called as
h (100, a, b, b) but h2 cannot be called as h2 (100, a, b, b). The
prototype doesn't give you this information, you can only get it by
reading the code that actually implements this function.

Now I would suspect that the person who wrote h didn't have the
intention that h (99, a+1, a, b) should work. But possibly h (100, a, a,
b) is intended to work (it would be equivalent to a [i] += b [i]).
Unfortunately this would be illegal if you make q and r const restrict
pointers. Making only one a const restrict pointer would help a bit
except that you cannot call h (a, a, a) to double the values of all
elements of a anymore, but that still doesn't give you the information
that the second and third argument may be overlapping.

So there is a limit to how much you restrict pointer arguments can do
for documenting legal uses of a function.