3 ms·

I had a hard time following Ritchie’s argument. I guess I’m missing a lot from the proposals he’s critiquing. One part stood out that was not clear: > memcpy(n

I had a hard time following Ritchie’s argument. I guess I’m missing a lot from the proposals he’s critiquing. One part stood out that was not clear: > memcpy(noalias void *s1, const noalias void *s2, size_t n); > what information can one glean from it? Some committee members apparently believe that it conveys either to the reader or to the compiler that the routine is safe, provided that the strings do not overlap. They are mistaken. I don’t follow. It seems that noalias exactly means that the two arrays can never point to the same memory, thus they do not overlap. So why would it be wrong to assume that memcpy() with noalias arguments is safe if called with non-overlapping memory? ———— Separately I agree with him that “noalias” unlike “const” is not a property of the object being pointed to but rather a property of the access being done. It creates an inconsistency where “char * noalias” makes sense but “char noalias” doesn’t. Perhaps he would have supported a “noalias dereference” operator or compiler built-in instead.

Denvercoder9 6y ago
> It seems that noalias exactly means that the two arrays can never point to the same memory, thus they do not overlap. I think that `noalias` would enforce that `s1` and `s2` aren't equal, but that doesn't mean that `s2` doesn't partially overlap with `s1` (i.e. it starts at an offset of `s1`).
- CyberRabbi 6y ago
  I see now. The signature itself would only require that the values passed in are not equal, not that the range doesn’t overlap. If that indeed was his criticism, that’s easily fixable. The standard could simply add language that says “noalias” must be true for the whole range of the array. Maybe that would prevent other practical use cases. I think his consistency argument is more powerful, if maybe less practical.
  - deleted 6y ago
    [deleted]
pm215 6y ago
I think this is the ANSI draft Ritchie was commenting on: http://www.3kranger.com/LabNotes/ANSI-C-X3J1188-Draft.pdf http://www.3kranger.com/LabNotes/ANSI-C-X3J1188-Draft.pdf -- section 3.35.3 talks about 'noalias'. It does not define 'noalias' in terms of whether arguments do or do not overlap -- it defines concepts of 'actual objects' which lvalues are handles to, and 'virtual objects' which lvalues with the noalias attribute are handles to, and rules about the contents of the virtual object being synchronized with the actual object at various points. Presumably the intention was to define abstract semantics corresponding to "OK if you don't overlap arguments" but it's definitely not clear to me that this hard-to-understand virtual-and-actual-objects business is in fact doing that. I think Ritchie may be saying that the expectation is that if you have an array x[1024], then memcpy(x, x + 512, 10) should be OK, as it's copying between two non-overlapping slices of the array; but the noalias annotation is overbroad and acts on the entirety of the x[] array, making the call undefined behaviour. But I'm not sure :-)

Denvercoder9 6y ago

> It seems that noalias exactly means that the two arrays can never point to the same memory, thus they do not overlap. I think that `noalias` would enforce that `s1` and `s2` aren't equal, but that doesn't mean that `s2` doesn't partially overlap with `s1` (i.e. it starts at an offset of `s1`).

CyberRabbi 6y ago
I see now. The signature itself would only require that the values passed in are not equal, not that the range doesn’t overlap. If that indeed was his criticism, that’s easily fixable. The standard could simply add language that says “noalias” must be true for the whole range of the array. Maybe that would prevent other practical use cases. I think his consistency argument is more powerful, if maybe less practical.
- deleted 6y ago
  [deleted]

pm215 6y ago

I think this is the ANSI draft Ritchie was commenting on: http://www.3kranger.com/LabNotes/ANSI-C-X3J1188-Draft.pdf http://www.3kranger.com/LabNotes/ANSI-C-X3J1188-Draft.pdf -- section 3.35.3 talks about 'noalias'. It does not define 'noalias' in terms of whether arguments do or do not overlap -- it defines concepts of 'actual objects' which lvalues are handles to, and 'virtual objects' which lvalues with the noalias attribute are handles to, and rules about the contents of the virtual object being synchronized with the actual object at various points. Presumably the intention was to define abstract semantics corresponding to "OK if you don't overlap arguments" but it's definitely not clear to me that this hard-to-understand virtual-and-actual-objects business is in fact doing that. I think Ritchie may be saying that the expectation is that if you have an array x[1024], then memcpy(x, x + 512, 10) should be OK, as it's copying between two non-overlapping slices of the array; but the noalias annotation is overbroad and acts on the entirety of the x[] array, making the call undefined behaviour. But I'm not sure :-)