21 ms·
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-X3J1
by 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 :-)