473,326 Members | 2,113 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

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

Does the following code have defined behavior?

double *new_array(unsigned 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.

Sep 23 '07 #1
6 2348
On Sep 23, 9:45 pm, rainy6...@gmail.com wrote:
Does the following code have defined behavior?

double *new_array(unsigned 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.

Sep 23 '07 #2
In article <11**********************@y42g2000hsy.googlegroups .com>
<ra*******@gmail.comwrote:
>Does the following code have defined behavior?
I think it does:
>double *new_array(unsigned 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) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Sep 23 '07 #3
On Sep 23, 11:45 pm, rainy6...@gmail.com wrote:
Does the following code have defined behavior?

double *new_array(unsigned 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).

Sep 23 '07 #4
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.netwrote:
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) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Sep 24 '07 #5
ra*******@gmail.com wrote:
double *new_array(unsigned 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
Sep 24 '07 #6
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.

Sep 24 '07 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Gerry | last post by:
I have a developer here with a website running with only "Windows Integrated Authentication" set on a Windows 2000 member server that uses GetObject to get a user's group membership in the domain....
0
by: Perttu Pulkkinen | last post by:
Is there some way to restrict in mysql that certan field has only ONE ROW with CERTAIN VALUE X while other rows can have any values but not this one(so "unique" is not the answer..)? This can be...
1
by: Robert Fitzpatrick | last post by:
I am running PostgreSQL 7.4.5 and have a trigger on a table called tblriskassessors which inserts, updates or delete a corresponding record in tblinspectors by lookup of a contact id and license...
2
by: Navneet Kumar | last post by:
Hi, My program is non-leaky, I've checked on that. More virtual memory is allocated to it by the system then is required by it. I'm filling a linked list which grows in size to around 1GB (at this...
2
by: Frederick Gotham | last post by:
I'm going to be using an acronym a lot in this post: IINM = If I'm not mistaken Let's say we've got translation units which are going to be compiled to object files, and that these object...
5
by: Francois Grieu | last post by:
Hello, I'm tring to implement a function that behaves like sprintf, but returns what it produce into newly mallocated memory block. I opened ISO/IEC 9899:1999, found int vsnprintf(char *...
7
by: jayakrishnanav | last post by:
Hi , Is it possible to restrict "pasting" any data in a text box,through keyboard(Ctrl-p) and through mouse??Can anybody help in dis WarmRegards jk
4
by: Spiros Bousbouras | last post by:
Is there a way to mimick restricted pointers using array syntax ? So I'm looking for something to add to a statement such as "int arr" which will tell the compiler that I will only access the...
13
by: =?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?= | last post by:
When I'm writing my own code, compiling it and testing it out as I go along, I usually compile as follows: gcc *.c -ansi -pedantic -Wall -o executable If I'm using 3rd-party libraries, I'll...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.