From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32225 invoked by alias); 4 Mar 2011 23:54:04 -0000 Received: (qmail 32217 invoked by uid 22791); 4 Mar 2011 23:54:03 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_CP X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Mar 2011 23:54:01 +0000 From: "torvalds@linux-foundation.org" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12518] memcpy acts randomly (and differently) with overlapping areas X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: torvalds@linux-foundation.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 04 Mar 2011 23:54:00 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00026.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12518 --- Comment #10 from Linus Torvalds 2011-03-04 23:53:36 UTC --- (In reply to comment #9) > > It solves everything. If you just relink without retesting you're an idiot and > acting irresponsible. It does solve a lot, and at least fixes the "you broke stuff that used to work" issue. However, I still don't understand why you guys can't just admit that you might as well just do memmove() and be done with it. It's not slower. And the excuse that "you'll have more implementations in the future" is just an even stronger reason to do that. To make this very clear: your new "and improved" memcpy() ACTS DIFFERENTLY ON DIFFERENT MACHINES. That means that all that testing that was done by the developer at link-time is ALMOST TOTALLY WORTHLESS, because what was tested wasn't necessarily at all what the user sees. I really don't understand why you can't admit that random behavior like that by a very fundamental core library routine is actually a real problem. And there really isn't any upside. The optimized routines up to 80 bytes are the same (in fact, my patch should speed them up by a few cycles), and anything bigger than that will not notice the extra couple of cycles to check for overlap. So while I agree that it's a fix to the immediate problem to just say "don't screw up for existing binaries", I do NOT understand why the glibc people then apparently think it's fine to be stupid for new binaries. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.