This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: memcmp-sse4.S EqualHappy bug
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Dr. David Alan Gilbert" <dgilbert at redhat dot com>, Torvald Riegel <triegel at redhat dot com>
- Cc: Andrea Arcangeli <aarcange at redhat dot com>, Szabolcs Nagy <nsz at port70 dot net>, libc-alpha at sourceware dot org, "H.J. Lu" <hongjiu dot lu at intel dot com>
- Date: Fri, 19 Jun 2015 09:38:51 -0400
- Subject: Re: memcmp-sse4.S EqualHappy bug
- Authentication-results: sourceware.org; auth=none
- References: <20150617185952 dot GE22285 at port70 dot net> <20150617210612 dot GB14955 at redhat dot com> <1434621040 dot 5250 dot 212 dot camel at localhost dot localdomain> <20150618124900 dot GD14955 at redhat dot com> <1434637415 dot 5250 dot 271 dot camel at localhost dot localdomain> <20150618145202 dot GG14955 at redhat dot com> <1434642635 dot 5250 dot 292 dot camel at localhost dot localdomain> <20150618161943 dot GN14955 at redhat dot com> <20150618172231 dot GS14955 at redhat dot com> <1434649785 dot 30819 dot 37 dot camel at localhost dot localdomain> <20150618181219 dot GL2248 at work-vm>
On 06/18/2015 02:12 PM, Dr. David Alan Gilbert wrote:
> c) I worry if there's anything where a strcmp could get optimised
> into a memcmp and then hit this case, but I agree it's difficult to
> find a situation where it would have been safe anyway.
Exactly. It would not have been safe.
> IMHO it would be safer to abort than to return 0, but that's probably
> an equally controvercial result.
Not really.
It's undefined behaviour, we can do anything.
I agree with aborting, but only as long as the hot path's performance
is not impacted and I haven't thought about how to do that.
Per "Bugs in the user program" convention:
https://sourceware.org/glibc/wiki/Style_and_Conventions#Bugs_in_the_user_program
---
9.2. Bugs in the user program
If it's user code invoking undefined behavior, then it should fail early and catastrophically so that developers don't get the false impression that their code is OK when it happens not to break the use cases they test adequately. (Said another way, so that we avoid giving developers an excuse to complain when a future implementation change "breaks" their programs that were always broken, but theretofore ignorably so.) That too trades off against any runtime cost of detecting the case. I'd say the allowance for cost of detection is marginally higher than in the case of library bugs, because we expect user bugs to be more common that library bugs. But it's still not much, since correct programs performing better is more important to us than buggy programs being easier to debug.
---
Cheers,
Carlos.