[haiku-commits] Re: r40701 - haiku/trunk/src/system/kernel

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sat, 26 Feb 2011 19:04:08 +0100

On 26.02.2011 18:09, John Scipione wrote:
On Sat, Feb 26, 2011 at 10:26 AM, <korli@xxxxxxxxxxxxxxxx
<mailto:korli@xxxxxxxxxxxxxxxx>> wrote:

    Author: korli
    Date: 2011-02-26 16:26:47 +0100 (Sat, 26 Feb 2011)
    New Revision: 40701
    Changeset: http://dev.haiku-os.org/changeset/40701
    Ticket: http://dev.haiku-os.org/ticket/7235

    copy sig_action structure from the current thread if we're the same
    team. Helps with #7235

    Modified: haiku/trunk/src/system/kernel/thread.cpp
    --- haiku/trunk/src/system/kernel/thread.cpp    2011-02-26 12:45:45
    UTC (rev 40700)
    +++ haiku/trunk/src/system/kernel/thread.cpp    2011-02-26 15:26:47
    UTC (rev 40701)
    @@ -463,6 +463,10 @@

                    // stop the new thread, if desired
                    debugNewThread = debugFlags &
    +               // copy signal handlers
    +               memcpy(thread->sig_action, currentThread->sig_action,

In The Practice of Programming by Kernighan and Pike the authors write:

"The ANSI C Standard defines two functions: memcpy, which is fast but
might overwrite memory if source and destination overlap, and memmove,
which might be slower but will always be correct. The burden of choosing
correctness over speed should not be placed upon the programmer, there
should be only one function. Pretend there is, and always use memmove."

I don't pretend to know the differences well enough to make an informed
decision, but, if Kernighan and Pike say that you should use memmove and
not memcpy I have to imagine that they know what they are talking about.

I don't know who these gentlemen are, but this is a pretty silly advice (the fact that it's given in such a general way). You need memmove() only when the source and target buffer may overlap. For example when moving stuff around in a single string. Or when copying pixels in the same bitmap from one location to another. If memory would potentially overlap in the situation at hand, we would be totally screwed.

Best regards,

Other related posts: