Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Why use such misleading names for functions?

Posted Nov 25, 2010 18:42 UTC (Thu) by RobSeace (subscriber, #4435)
In reply to: Why use such misleading names for functions? by rvfh
Parent article: On breaking things

> memcpy_nooverlap() (feel free to find a better name)

We've already got one: memmove()...

(And, no, it's NOT really a "misleading" name... As I said in the old thread,
when the regions overlap, indeed the source region will no longer contain the
data it once did prior to the memmove(), since it's now been overwritten, at
least in part... So, the data truly was MOVED from source to destination, not
merely COPIED...)

(Log in to post comments)

Why use such misleading names for functions?

Posted Nov 25, 2010 18:45 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

D'oh! Of course, I misread, and of course memmove() is the name for memcpy_overlap(),
and your hypothetical memcpy_nooverlap() is just memcpy()... But, it has
literally ALWAYS been this way, and any C programmer worth half a damn knows
this is how memcpy() and memmove() works... It's widely documented in various
standards, and misusing memcpy() in place of memmove() will cause you lots of
trouble on various other libcs... Just because glibc has been forgiving of the
blatent misuse prior to now is no reason to continue to tolerate it...

Why use such misleading names for functions?

Posted Nov 25, 2010 21:36 UTC (Thu) by rvfh (subscriber, #31018) [Link]

> And, no, it's NOT really a "misleading" name...
> (...)
> the data truly was MOVED from source to destination (...)

You're correct, now that you say that, I understand why the name!