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

Discussion in 'C Programming' started by rainy6144@gmail.com, Sep 23, 2007.

  1. Guest

    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 = 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, 2007
    #1
    1. Advertising

  2. Guest

    On Sep 23, 9:45 pm, 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 = 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, 2007
    #2
    1. Advertising

  3. Chris Torek Guest

    In article <>
    <> wrote:
    >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 = 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 in new_array() is completely gone before
    the compiler can even begin to consider aliases named x. 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.
    Chris Torek, Sep 23, 2007
    #3
  4. Old Wolf Guest

    On Sep 23, 11:45 pm, 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).
    Old Wolf, Sep 24, 2007
    #4
  5. r6144 Guest

    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 <> wrote:
    > The *goal* of "restrict" is to allow the compiler to track aliases,
    > and the alias named p in new_array() is completely gone before
    > the compiler can even begin to consider aliases named x. 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.
    r6144, Sep 24, 2007
    #5
  6. wrote:

    > double *new_array(unsigned n)
    > {
    > double *p = malloc(n * sizeof(double));
    > unsigned i;
    > for (i = 0; i < n; i++) p = 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
    Pierre Asselin, Sep 24, 2007
    #6
  7. Army1987 Guest

    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.
    Army1987, Sep 24, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    601
    Matt Wharton
    Dec 9, 2004
  2. Alfonso Morra
    Replies:
    11
    Views:
    696
    Emmanuel Delahaye
    Sep 24, 2005
  3. A. Farber
    Replies:
    15
    Views:
    462
    goose
    Dec 1, 2006
  4. Replies:
    3
    Views:
    575
    Keith Thompson
    Mar 31, 2007
  5. Sune

    C99 restrict and function parameters?

    Sune, Feb 15, 2008, in forum: C Programming
    Replies:
    2
    Views:
    268
Loading...

Share This Page