11

Here is some code I wrote (using GCC's __restrict__ extension to C++):

#include <iostream>

using namespace std;

int main(void) {
    int i = 7;
    int *__restrict__ a = &i;
    *a = 5;
    int *b = &i, *c = &i;
    *b = 8;
    *c = 9;

    cout << **&a << endl; // *a - which prints 9 in this case

    return 0;
}

Or, the C version (in case the C++ version is not clear due to the use of an extension which every popular C++ compiler supports), using GCC:

#include <stdio.h>

int main(void) {
    int i = 7;
    int *restrict a = &i;
    *a = 5;
    int *b = &i, *c = &i;
    *b = 8;
    *c = 9;

    printf("%d \n", **&a); // *a - which prints 9 in this case

    return 0;
}

From what I've read, if I do *a = 5, it changes the value of the memory he, a, is pointing to; after that, the memory to which he is pointing to should not be modified by anyone else except a, which means that these programs are wrong because b and c modify it after that. Or, even if b modifies i first, after that only a should have access to that memory (i). Am I getting it correctly?

P.S: Restrict in this program doesn't change anything. With or without restrict, the compiler will produce the same assembly code. I wrote this program just to clarify things, it is not a good example of restrict usage. A good example of restrict usage you can see here: http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html

Lilian A. Moraru
  • 1,046
  • 1
  • 12
  • 20
  • 5
    There's no `restrict` in C++; anything else is a compiler extension. – Kerrek SB Nov 28 '11 at 01:53
  • 1
    possible duplicate of [What can human beings make out of the restrict qualifier?](http://stackoverflow.com/questions/1506794/what-can-human-beings-make-out-of-the-restrict-qualifier) – Chris Dodd Nov 28 '11 at 02:29
  • @KerrekSB Than consider this program in C, using "restrict", I asked C / C++... One of them. – Lilian A. Moraru Nov 28 '11 at 07:06
  • @MoraruLilian: You've missed the point. You tagged this question only [C++] and [C] with respect to languages, but `restrict` isn't part of the language itself. It must therefore be a compiler extension. In order for us to give you a decent reply, we need to know what platform you are using. Please indicate this by tagging appropriately, and including it int he body of your question. – John Dibling Nov 28 '11 at 14:54

1 Answers1

13

No.

Statements

*b = 8;
*c = 9;

will cause undefined behavior.

From documentation:

A pointer is the address of a location in memory. More than one pointer can access the same chunk of memory and modify it during the course of a program. The restrict type qualifier is an indication to the compiler that, if the memory addressed by the restrict-qualified pointer is modified, no other pointer will access that same memory. The compiler may choose to optimize code involving restrict-qualified pointers in a way that might otherwise result in incorrect behavior. It is the responsibility of the programmer to ensure that restrict-qualified pointers are used as they were intended to be used. Otherwise, undefined behavior may result.

Matthew Slattery
  • 45,290
  • 8
  • 103
  • 119
Roman Byshko
  • 8,591
  • 7
  • 35
  • 57
  • Didn't I write the same thing? I didn't asked if the program is correct, I said myself that it is wrong because of b and c. By wrong I don't mean that it will give an error, not even a warning message because it's a "Contract between the programmer and compiler", the compiler doesn't check it. So, I understand that the answer to my question("Am I getting it correctly/right?") is a simple "No"? – Lilian A. Moraru Nov 28 '11 at 07:15
  • In case the question is not clear: I didn't asked if the program is correct, it was intended to be wrong. I ask if the explanation of my understanding of "restrict" under the code is correct. – Lilian A. Moraru Nov 28 '11 at 08:14
  • 3
    @MoraruLilian "No" is in particularly answer to "Or, even if "b" modifies "i" first, after that only "a" should have access to that memory( "i" ). Am I getting it correctly?" The point is you are not even allowed to try to access this variable by another pointer. – Roman Byshko Nov 28 '11 at 12:45
  • Now that was a lot more clear. This statement made me think like this: "... if the memory addressed by the restrict-qualified pointer is modified, no other pointer will access that same memory." - It made me think that no other pointer should access it just after the value was modified, but before that, anyone can access it. Actually, I've read a little bit more and 1 article in particular made it clear for me: http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html . Thanks. – Lilian A. Moraru Nov 28 '11 at 16:56
  • @Beginner: That documentation is wrong according to the standard, which doesn't require that only one pointer can "access the same chunk of memory and modify it" but rather that all access be "based on" the restrict-qualified pointer (and even this is only necessary if access is performed through the restrict-qualified pointer); see C99 6.7.3.1. The code in question invokes undefined behaviour because it accesses the value using pointers b and c which are not "based on" a. – davmac Aug 07 '13 at 13:43
  • @Beginner _"The point is you are not even allowed to try to access this variable by another pointer."_ So even this will cause undefined behaviour? `int *b = &i, *c = &i;`, right? – Nerva Nov 21 '14 at 16:28