Re: free()'ing restrict'ed pointers
- From: Ben Bacarisse <ben.usenet@xxxxxxxxx>
- Date: Thu, 31 Jul 2008 19:37:23 +0100
s0suk3@xxxxxxxxx writes:
On Jul 31, 10:46 am, "christian.bau"
<christian....@xxxxxxxxxxxxxxxxxx> wrote:
On Jul 31, 2:40 pm, s0s...@xxxxxxxxx wrote:
Hi,
A object to which there is a pointer that has been declared 'restrict'
is supposed to be accessed only through that pointer. So is it safe to
call free() with a restricted pointer? Does free() try to access what
in points to in some way?
You are quoting incorrectly what "restrict" means: The data pointed to
may be accessed through the restrict pointer itself, or through a
pointer derived from that pointer. If you have a pointer "int
*restrict p" and call free (p), then the argument to free is derived
from p and is allowed to access the data as much as it likes.
Wow, seems like everybody's got a different idea about the subject.
But Ben Bacarisse said it's legal to *access* the object through
another pointer or a variable that holds the object (or array element,
etc), but not to *modify* it.
It is complicated and I, as a non-expert, am wary of getting into too
much trouble by commenting on things I only partly understand, but it
seems to me that 6.7.3.1 (Formal definition of restrict) is careful to
talk about the exact objects that get accessed and how (to get the
value or to modify them).
For example, I think this is OK:
int A[2], *restrict p = A;
A[1] = 42;
p[0] = 43;
because no access that I can see violates the key para. 4. You can't
modify an object that you also access via a restrict-qualified
pointer:
int A[2], *restrict p = A;
A[1] = 42;
return p[1];
nor can you access the value of an object that has been changed though
one:
int A[2], *restrict p = A;
p[1] = 42;
return A[1];
All blanket statements about restrict pointers will be wrong unless
they paraphrase 6.7.3.1p4 so there is little to do other than read and
re-read it.
Is that what you meant to? Or is it also
illegal to merely access it (through something other than the
restricted pointer or something that's not derived from it)?
What matters is the "it". A restrict-qualified pointer to int that
points to the start of an array does mean the whole array is "off
limits" to all other accesses.
Now what is wrong is the following:
int* p = malloc (100);
int* restrict q = p;
p [0] = 1;
free (q);
(the call free (q) is just as wrong as an assignment q [0] = 2 or just
reading q [0] would be).
Reading q[0] is wrong?
But q is the restricted pointer; why is it
wrong to access it or modify it?
Because in this case the clause "Every other lvalue used to access the
value of X shall also have its address based on P" would be violated.
In particular, we would have an access based on q (q[0]), where the
value is modified (by p[0] = 1) and an lvalue (p[0]) whose address is
not based on q.
I won't post again until there is some more expert input. I fear I
may be in over my head.
--
Ben.
.
- References:
- free()'ing restrict'ed pointers
- From: s0suk3
- Re: free()'ing restrict'ed pointers
- From: christian.bau
- Re: free()'ing restrict'ed pointers
- From: s0suk3
- free()'ing restrict'ed pointers
- Prev by Date: Re: Weird malloc behaviour
- Next by Date: Re: Weird malloc behaviour
- Previous by thread: Re: free()'ing restrict'ed pointers
- Next by thread: diagnostic message
- Index(es):
Relevant Pages
|
