Re: General remarks on restrict

Bart van Ingen Schenau wrote:
On Sep 19, 2:45 pm, "Wojtek Lerch" <Wojte...@xxxxxxxx> wrote:
"Bart van Ingen Schenau" <Bart.van.Ingen.Sche...@xxxxxx> wrote in messagenews:e30bf715-5244-4f18-ac48-6b4ed998e0d7@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sep 18, 3:06 pm, "Wojtek Lerch" <Wojte...@xxxxxxxx> wrote:
No, the use of restrict to qualify parameters in a function declaration
(that is not a definition) is meaningless.
>>>
It might not carry a meaning that the compiler can enforce, but the
qualification *does* carry a meaning for the human programmer who uses
memcpy.

And where does the standard explain what that meaning should be? The
synopses of library functions look exactly like declarations written in C;
if they're supposed to carry more meaning than function declarations do in
C, I'd expect that to be mentioned somewhere in the standard. Is it?

The meaning of the restrict qualifier is specified in detail in clause
6.7.3.1.

Yes, but there also is this bit in 6.7.5.3#15:

"In the determination of type compatibility and of a composite type, [...] each parameter declared with qualified type is taken as having the unqualified version of its declared type."

This means that a function type with restrict-qualified parameters is compatible with a similar function type that declares the parameters without the restrict qualifier. In a C program, the names and qualifiers of parameters in a function declaration (that is not a definition) are meaningless, in the sense that a compatible definition is free to declare the parameters with different names and qualifiers, and any semantics associated with qualifiers depend on the qualifiers used in the definition, not the ones used in the declaration.

Does the standard say anywhere that the qualifiers in the synopsis of a standard library function carry more meaning than they do in an identically looking declaration in a C program? Notice that this is not a question about "restrict" -- it's a question about how the meaning of a synopsis in the standard differs from the meaning the standard specifies for function declarations in programs.

The restrict qualification conveys the information that the function
can not be safely used with pointers that refer to (partially)
overlapping memory areas.

I can't find anything in the standard that supports such an interpretation.
Can you?

On rereading the standard, I found that my claim will only hold if one
of the pointers is used to modify the object it refers to.

One of what pointers? A synopsis in the standard looks like a function declaration; the parameters declared in it have function prototype scope and are not used in any expression (even if you copied the complete declaration into a program). Only parameters declared in a function *definition* can possibly be used to access objects. Do you believe that the standard requires memcpy() to be *defined* with restrict-qualified parameters named "s1" and "s2"? Or do you agree that memcpy() does not even need to be defined in standard C?

Or do you believe that just because a function is declared with restrict-qualified parameters, calling it with arguments that point to overlapping objects is automatically undefined, regardless of whether the function *definition* also declares the parameters as restrict-qualified, or whether their values are actually used to access any objects?

....
Adding "restrict" to the prototype is *not*
a substitute for saying that the two objects must not overlap. If the prose
describing memcpy() did not mention that it mustn't be used with overlapping
objects, it would be required to work with overlapping objects, despite of
the "restrict" in the prototype; and if the "restrict" meant that the
function must be *defined* with restrict-qualified parameters, *that* would
make it difficult to implement the (hypothetical) required semantics for
overlapping objects in standard C.

Apparently we have a completely different understanding of restrict.
I admit that clause 6.7.3.1 takes some effort to understand, but it is
quite unambiguous to me that if an object (or memory area) gets
modified trough a restrict-qualified pointer, then the same memory
area can not be accessed through another, unrelated, pointer without
violating a requirement (wich results in UB).

How do you interpret the meaning of restrict?

It's not about the meaning of restrict. It's about the meaning of a function synopsis in the standard. It's about whether the synopsis of memcpy() (or any other standard function that uses "restrict") should be interpreted as an indirect indication that regardless of what the prose of the function's description promises, passing pointers to overlapping objects causes undefined behaviour, as if the function were *defined* with restrict-qualified parameters and used them to access what they point to. It's about whether the paragraph about non-overlapping object in the description of memcpy() is indeed redundant because it's implied in the use of "restrict" in the synopsis, or whether the paragraph is important, because the "restrict" in the synopsis is as meaningless as it would be in an ordinary declaration in a program.

.

Relevant Pages

  • Re: General remarks on restrict
    ... the use of restrict to qualify parameters in a function declaration ... It might not carry a meaning that the compiler can enforce, ... The restrict qualification conveys the information that the function ... The restrict keyword in the declaration does not convey anything at all. ...
    (comp.std.c)
  • Re: General remarks on restrict
    ... The meaning of the restrict qualifier is specified in detail in clause ... is free to declare the parameters with different names and qualifiers, ... not the ones used in the declaration. ...
    (comp.std.c)
  • Re: A DECLARATION OF MEANING
    ... > is just a declaration of meaning and not a thesis. ... If we define fitness as being that which is maximised by the action of ... Note that John Edser wrote: ...
    (sci.bio.evolution)
  • Re: A DECLARATION OF MEANING
    ... >> of meaning for all ongoing discussion. ... >> within this declaration I will explicitly acknowledge ... >> A) What is the purpose ... This form is not a debate. ...
    (sci.bio.evolution)
  • Re: "static" question
    ... > I would like to know what is the meaning of: ... That depends on the context of the declaration. ... lifetime; for a class it is a single variable instead of a member variable in ...
    (comp.lang.cpp)