what is restrict keyword used for


Ad

Advertisements

B

Bartc

Pilcrow said:
Pardon my ignorance, but to what document does that string of numbers
refer?

Usually to one of the two C standards documents, C90 and C99. I think the
numbering is identical, at least for common sections.

Someone (I think cr88192) once refered to the clc lot as 'standards heads'
(or some such), and I think he has a point.
 
J

James Kuyper

See 6.7.3.1 Formal definition of restrict.

He asked what it was used for, not what it means (though he could easily
be in need of both pieces of information).

The restrict keyword is a method for the programmer to make a promise to
the compiler about how a given pointer will be used. The compiler can
completely ignore that promise - using restrict does not change the
meaning of the code. However, the compiler is also permitted accept the
programmer's promise, and on the basis of that promise make some
optimizations that it would ordinarily not be able to make. The reason
why these optimizations are not ordinarily permitted is because, if you
write code which breaks that promise, those optimizations will produce
incorrect results.

What is the promise that you are making? Well, that's why vippstar gave
you a section reference. It's a long, complicated section, and no simple
summary will cover all of the details perfectly. Nonetheless, I'll try
to give you a simple summary. What the 'restrict' keywork promises is
that, within the scope of 'p', any object accessed through 'p', directly
or indirectly, will ONLY be accessed through 'p', directly or
indirectly, and not by any other means. Thus, the following code has
undefined behavior:

int i;
restrict int *p = &i;
i++;
*p--;

The "i++" occurs within the scope of the declaration of p, and it
changes the value of 'i'. p is also used to change the value of 'i'.
Without the 'restrict' keyword, a compiler is required to coordinate the
code generated by those two so that 'i' ends up with the right value.
With the 'restrict' keyword, because the behavior of such code is
undefined, it's allowed to perform code rearrangements, such as the
equivalent of:

int temp1 = i;
int temp2 = *p;
*p = temp2 -1;
i = temp1 + 1;

There's no obvious advantage to making such a rearrangement, but in the
general case 'restrict' allows optimizations that can significantly
speed up the generated code, while still producing the correct result -
but only if your code keeps the promise that it makes by using the
'restrict' keyword.

The classic example is memcpy(). It has always been undefined behavior
to use memcpy() if the source for your copy overlaps the target. If your
source and destination do overlap, you should use memmove() instead; it
uses a more complicated logic that checks for overlap, and performs the
copy in a way that avoids the problems that memcpy() would have if given
the same arguments. The addition of 'restrict' keyword in C99 allows
this distinction to be documented by the function prototype itself:

void *memcpy(void * restrict s1,
const void * restrict s2,
size_t n);

The effect of the restrict keyword is to promise that, at no point in
the execution of memcpy(), will s1 be used, directly or indirectly, to
access any memory location that is also accessed, directly or
indirectly, by s1.
 
N

Nick Keighley

google "c restrict" gives many hits. This is the first I got
http://developers.sun.com/solaris/articles/cc_restrict.html

basically "restrict" qualified parameters specify that
there is no aliasing going on

int f (restict int *a, restrict int *b)

a and b cannot point to the same object (memory),
hence the compiler can be morer aggressive in its
optimisation. I believe the numerical people asked
for it. It potentially allows C to to compete with
Fortran in high speed numerical stuff.
Pardon my ignorance, but to what document does that string of numbers
refer?

the (or a) C standard. In this case it will be the ISO
1999 C Standard (aka C99). Earlier versions of the standard
did not include restict. Here's a draft of the standard,
the paragraph numbers don't tie up tho :-(

http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/n2794.txt
 
Ad

Advertisements

K

Keith Thompson

Bartc said:
Usually to one of the two C standards documents, C90 and C99. I think
the numbering is identical, at least for common sections.
[...]

Such numbers usually refer to the C99 standard. In this case it
definitely does, since C90 didn't have "restrict".

The major section numbers are the same (section 6 is Language, 7 is
Library), but the minor numbers are different due to the new material
in C99.

The latest (and probably last) C99 draft is freely available at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.
 
C

CBFalconer

Pilcrow said:
Pardon my ignorance, but to what document does that string of
numbers refer?

The C standard. See below for references for PDF and compressed
text varieties.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2> (C99, txt)
<http://www.dinkumware.com/c99.aspx> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
 
K

Keith Thompson

Nick Keighley said:
the (or a) C standard. In this case it will be the ISO
1999 C Standard (aka C99). Earlier versions of the standard
did not include restict. Here's a draft of the standard,
the paragraph numbers don't tie up tho :-(

http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/n2794.txt

That's a plain-text version of a pre-C99 draft, dated August 3, 1998.
(It's actually N843; I wonder why the file is called n2794.txt.)

CBFalconer often recommends a plain-text version of n869, a later
pre-standard draft.

There are no plain-text versions of the actual standard or of the
later drafts. Plain text loses some semantically significant
formatting information. I recommend n1256.pdf unless you have serious
difficulties dealing with PDF files.
 
Ad

Advertisements

L

lawrence.jones

Keith Thompson said:
That's a plain-text version of a pre-C99 draft, dated August 3, 1998.
(It's actually N843; I wonder why the file is called n2794.txt.)

Because the complete numbers are WG14/N843 and SC22/N2794: the working
group's document was redistributed by the parent subcommittee and thus
given one of their document numbers.
 
K

Keith Thompson

Because the complete numbers are WG14/N843 and SC22/N2794: the working
group's document was redistributed by the parent subcommittee and thus
given one of their document numbers.

Well, I'm glad it's not confusing or anything.
 
V

vippstar

Was that really necessary? It was a reasonable question.

No it wasn't, it was a silly post.
However, I'm suspicious of this Pilcrow person. He talks to kenny and
twink a bit too much. Maybe he's just a usenet/clc newbie...
I was referring to ISO/IEC 9899:1999.
 
J

jaysome

No it wasn't, it was a silly post.
However, I'm suspicious of this Pilcrow person. He talks to kenny and
twink a bit too much. Maybe he's just a usenet/clc newbie...
I was referring to ISO/IEC 9899:1999.

It's Kenny, not kenny.

This is the newsgroup comp.lang.c, which discusses the C programming
language, which is a case sensitive language.

In this newsgroup, kenny != Kenny, at least in terms of identifier
equivalence.

i hope u understand, bcus it is important 2 do so.

Whoops! You're wearing off on me.

I meant to say:

I hope you understand, because it is important to do so.
 
V

vippstar

... and the value of ("kenny" == "kenny") is unspecified.

He was talking in terms of identifiers, not string literals.
External identifiers can be case insensitive.
jaysome is either a troll or too stupid, but either way, I'm not
bothering with him anymore.
 
Ad

Advertisements

V

vippstar

(e-mail address removed) said:


He is neither. Nor is he particularly fond of jumping to conclusions on the
basis of insufficient data.


That's up to you.

How do you know he is not a troll?
If he is not a troll, what is this post about?
Message-ID: <[email protected]>
 
Ad

Advertisements


Top