Using C99 "restrict" with newly allocated and initialized arrays/structures

[rainy6144]

Does the following code have defined behavior?

double *new_array(unsi gned n)
{
double *p = malloc(n * sizeof(double)) ;
unsigned i;
for (i = 0; i < n; i++) p[i] = 0.0;
return p;
}

int main(void)
{
double *restrict x = new_array(10), *restrict y = new_array(10);
x[0] = 1.0;
y[0] = 2.0;
return (int) x[0];
}

The use of "restrict" here is intended to inform the compiler that x
and y do not alias, so that the return value of main() is surely 1.
Without it, and if the compiler does not see the definition of
new_array() when compiling main() (e.g. because they are in different
translation units), it must assume that the two calls to new_array()
might return the same pointer.

However, according to 6.7.3.1p4 of the standard, the code seems to
have undefined behavior, because the lvalue "x[0]", whose address is
based on restricted pointer x, is used to access the object x[0] (and
it is modified), yet the initialization of that object to 0.0 in
new_array() uses the lvalue p[0], whose address p is not based on x
(indeed, x has not been initialized or used by that time). The
problem is that the no-non-based-alias restriction seems to apply to
the whole block containing the declaration of the restricted pointer
(in this case, the main() function), even before the pointer is
initialized.

Is my understanding correct? I suppose it is okay to do this:

int main(void)
{
double *x0 = new_array(10), *y0 = new_array(10);
{
double *restrict x = x0, *restrict y = y0;
x[0] = 1.0; y[0] = 2.0; return (int) x[0];
}
}

But it is clearly a bit too verbose.

[borophyll]

On Sep 23, 9:45 pm, rainy6...@gmail .com wrote:

Does the following code have defined behavior?

double *new_array(unsi gned n)
{
double *p = malloc(n * sizeof(double)) ;
unsigned i;
for (i = 0; i < n; i++) p[i] = 0.0;
return p;

}

int main(void)
{
double *restrict x = new_array(10), *restrict y = new_array(10);
x[0] = 1.0;
y[0] = 2.0;
return (int) x[0];

}

The use of "restrict" here is intended to inform the compiler that x
and y do not alias, so that the return value of main() is surely 1.
Without it, and if the compiler does not see the definition of
new_array() when compiling main() (e.g. because they are in different
translation units), it must assume that the two calls to new_array()
might return the same pointer.

However, according to 6.7.3.1p4 of the standard, the code seems to
have undefined behavior, because the lvalue "x[0]", whose address is
based on restricted pointer x, is used to access the object x[0] (and
it is modified), yet the initialization of that object to 0.0 in
new_array() uses the lvalue p[0], whose address p is not based on x
(indeed, x has not been initialized or used by that time). The
problem is that the no-non-based-alias restriction seems to apply to
the whole block containing the declaration of the restricted pointer
(in this case, the main() function), even before the pointer is
initialized.

Is my understanding correct? I suppose it is okay to do this:

int main(void)
{
double *x0 = new_array(10), *y0 = new_array(10);
{
double *restrict x = x0, *restrict y = y0;
x[0] = 1.0; y[0] = 2.0; return (int) x[0];
}

}

But it is clearly a bit too verbose.

IIRC, the restrict keyword is just a hint to the compiler for
optimization purposes. In other words, if a data element is read via
a restricted pointer, the compiler can assume that the read value
(possibly cached in a register) will not change unless modified via
the restricted pointer. In other words, if we need to use the value
again, we can use the cached value and not have to reread the element
from memory again, because we know (declared via the restrict pointer)
that it cannot change any other way.

So, I believe your original code is fine, since the function call is
part of the initialization, and the initialization is part of the
declaration. You do not access the data via any other means following
the declaration.

Regards,
B.

[Chris Torek]

In article <11************ **********@y42g 2000hsy.googleg roups.com>
<ra*******@gmai l.comwrote:

>Does the following code have defined behavior?

I think it does:

>double *new_array(unsi gned n)
{
double *p = malloc(n * sizeof(double)) ;
unsigned i;
for (i = 0; i < n; i++) p[i] = 0.0;
return p;
}

int main(void)
{
double *restrict x = new_array(10), *restrict y = new_array(10);
x[0] = 1.0;
y[0] = 2.0;
return (int) x[0];
}

The use of "restrict" here is intended to inform the compiler that x
and y do not alias, so that the return value of main() is surely 1.
Without it, and if the compiler does not see the definition of
new_array() when compiling main() (e.g. because they are in different
translation units), it must assume that the two calls to new_array()
might return the same pointer.

Right.

>However, according to 6.7.3.1p4 of the standard, the code seems to
have undefined behavior, because the lvalue "x[0]", whose address is
based on restricted pointer x, is used to access the object x[0] (and
it is modified), yet the initialization of that object to 0.0 in
new_array() uses the lvalue p[0], whose address p is not based on x
(indeed, x has not been initialized or used by that time).

I think this is OK despite the wording you have quoted. I must,
however, admit that I do not fully understand some of the new bits
in C99, including the precise details of "restrict".

The *goal* of "restrict" is to allow the compiler to track aliases,
and the alias named p[i] in new_array() is completely gone before
the compiler can even begin to consider aliases named x[i]. Even
if the compiler chooses to expand new_array() in line and re-label
p as x, the restriction is "clearly visible" at that point, so this
*should* be allowed.

(This newsgroup -- comp.lang.c -- is probably not the best place
for a definitive answer as to whether the exact C99 wording means
what I think it does, or whether there are any corrections to it
since the version you are looking at, etc. The comp.std.c group
deals with picky wording details, corrections to the C standards,
future C standards, and so on. But here in comp.lang.c I will say
that I *think* your example code is OK as-is.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Old Wolf]

On Sep 23, 11:45 pm, rainy6...@gmail .com wrote:

Does the following code have defined behavior?

double *new_array(unsi gned n)
{
double *p = malloc(n * sizeof(double)) ;

No; you call malloc without a prototype visible.

x[0] = 1.0;
return (int) x[0];

The use of "restrict" here is intended to inform the compiler that x
and y do not alias, so that the return value of main() is surely 1.

It could be 0 due to floating point inaccuracies
(although not with IEEE754, if I understand that format correctly).

[r6144]

I thank you all for your helpful replies. I'll go to comp.std.c to
look for a more definitive answer.

On 9 24 , 4 09 , Chris Torek <nos...@torek.n etwrote:

The *goal* of "restrict" is to allow the compiler to track aliases,
and the alias named p[i] in new_array() is completely gone before
the compiler can even begin to consider aliases named x[i]. Even
if the compiler chooses to expand new_array() in line and re-label
p as x, the restriction is "clearly visible" at that point, so this
*should* be allowed.

(This newsgroup -- comp.lang.c -- is probably not the best place
for a definitive answer as to whether the exact C99 wording means
what I think it does, or whether there are any corrections to it
since the version you are looking at, etc. The comp.std.c group
deals with picky wording details, corrections to the C standards,
future C standards, and so on. But here in comp.lang.c I will say
that I *think* your example code is OK as-is.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Pierre Asselin]

ra*******@gmail .com wrote:

double *new_array(unsi gned n)
{
double *p = malloc(n * sizeof(double)) ;
unsigned i;
for (i = 0; i < n; i++) p[i] = 0.0;
return p;
}

int main(void)
{
double *restrict x = new_array(10), *restrict y = new_array(10);
x[0] = 1.0;
y[0] = 2.0;
return (int) x[0];
}

[ ... ] The
problem is that the no-non-based-alias restriction seems to apply to
the whole block containing the declaration of the restricted pointer
(in this case, the main() function), even before the pointer is
initialized.

I think you're right ! The aliasing restrictions begin a bit
too early. This could be a defect in the standard, or it could
be exactly what they meant.

I'll go look in comp.std.c too since you were redirected there,
but beware: there is already a threadlet pair on the subject,
but with trivial examples compared to yours. Make a good case.

BTW, this simpler example works too, doesn't it ?

static int a;
int *init(void) {a= 42; return &a;}
int main(void)
{
int * restrict p= init();
*p= 0;
return *p;
}
--
pa at panix dot com

[Army1987]

On Sun, 23 Sep 2007 16:44:56 -0700, Old Wolf wrote:

> x[0] = 1.0;
return (int) x[0];

It could be 0 due to floating point inaccuracies

I don't think so. x[0] was assigned a constant, so it can be <1.0
only if double cannot contain 1 exactly. In the generic model in
the standard, this is possible: s is positive, e is 1, and all the
f_k's are zero except the first which is one.
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.