4 ms·
> Seeing this purely as a spec v pragmatism issue isn't going to get us anywhere. That's because it's not. The spec ( http://pubs.opengroup.org/onlinepubs/009
by jjs 16y ago
> Seeing this purely as a spec v pragmatism issue isn't going to get us anywhere.
That's because it's not.
The spec ( http://pubs.opengroup.org/onlinepubs/009695399/functions/memcpy.html http://pubs.opengroup.org/onlinepubs/009695399/functions/mem... ) explicitly states, "If copying takes place between objects that overlap, the behavior is undefined."
Which means the real debate is between two technically valid interpretations of the spec: one that arbitrarily breaks existing software for no discernible benefit✻, and one that does not.
(✻ Unless, for ideological reasons, one believes that breaking said software is the benefit, in which case this is still a sneaky and passive-aggressive way to go about it.)
It's even fair to cast this particular debate as nonsense vs. pragmatism, because that's what it is.
- andrewf 16y ago"Passive aggressive" hits the nail on the head. If someone truly believes you should break software that made bad assumptions about memcpy, as a matter of engineering principle, then just stick this at the top of memcpy and be done with it: if((src <= dest && src+len >= dest) || (dest <= src && dest+len >= src)) abort(); /* valid - spec says behaviour is undefined */
- s3graham 16y agoDAMN LIBC DEVS BROKE MY ABUTTING memcpyS! ;)