From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13499 invoked from network); 16 Jul 2023 19:33:31 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Jul 2023 19:33:31 -0000 Received: (qmail 7373 invoked by uid 550); 16 Jul 2023 19:33:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 7341 invoked from network); 16 Jul 2023 19:33:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1689535996; x=1690140796; i=nullplan@gmx.net; bh=ozPi2qiEGpNGDHok4m8Z/CEUEzvlF7BVE52bW6WT9/0=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=To4BzkccS91S3fRC6xPHcg6CncB1s1YJDcL3ZHxFnWJpkKKzSYBVTMZsi68w70bYnxtFliW BZK1lfUEY48fixOXmEFzMhD9Ayc8RDhJoLQYcITZr7te9ShdlhONh1VuwxiIFdB8A/V9wdHNv cRzjqKhvD18h8CXVO/hbMW80x5DZ6LQJLXPFyjgqRK3FMF5m6o9JR4MCJZ4tVcFwUf6E7dO4a wVNOSxMmSbIOx5EzzQ+rPmIlT5X9Fg7xJyCR+kQ+3omwMWNsSf7l1uvQQyHsWhoCgJLElUJVL I+TXp3xrejZZ/8tjnv54nIHsTs3r66/pBynQgMWzrsvl17w4WxFQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Sun, 16 Jul 2023 21:33:16 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <20230716174945.qc6234b654k5eebx@gen2.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Provags-ID: V03:K1:v4/3Hha1NqFKDggQdPKNbqGEny7YCIBLo20IFPXqzPNJjOzVvPn QkKjOHU+M0O6r6231Y/NKqDv6nfV4qDeVFznrUkIAio0koZBE2ynOgliSTS9fAHcdF+n0vk 6gynEyJcY5x1Vr8oOLjRR3bOBfsaYTcfbPwOswJ99msw+D6RVOhsOguYVlcA0LUgGRrEdlc C5l13qNtnKuU4/RX4FDbA== UI-OutboundReport: notjunk:1;M01:P0:T2SpsVbTk7M=;WglLFd6xy5PzCf63lKq3J2aw0Pe PPs4DydZMF8OOD1ct7+GYr5/WyScrIOGkUPLirQPHMdcCFl4vObUJMq1BBKKJrK7Gwits8uWk QYbTlAvFDuHPZYiGqb11rGdn68tb1tu43t/61qKqS59fMK00CcHs99IyLFvoCadKvR67+VTuS mBq61GBcp/L7NlQDiIpo4tuJzK7zqXTcaTAZwB03dYfeGU7Ptd4GfHhmbjEbIL9dxxj03CsUv G4r2iJM2GnrYcDDrUJiZuFpjYlQa6UhqZ6HzvuIFhXKqEXXTNCfflOAeTky1QL6BJN+GRvGOu VUGATOXHz27xit6pRoAzyx2kRPNijrTpKc/jZdMd0xeMvp7+1jeWHFpXJ0HD0yocCJK07dRfQ TGn/rudtjL2aeTIXxbqDOIYZKufelNlk1eA0JVmzdPYE8OVxwUQ0dVru73dYgVdz2oY9r8432 /R6t/hkN2iVUkFmgAxMbqH8/CICO+/A35U5TodBEh1IUKRFeCJcpt2SqPkcThQ7RFlBeOy8H3 3Sl8+Mht8z2rkQh73AnSLQM521csItCV6ozmpqKOa/4ThVIt7fXDPRy274RdTC73Hkh9oU9ve l1QSsJnmG5gIczJLTgjmYhSv2oibdCqi8uTYLSrW9NjV8w0BMjAQ6sPUZiDotYYYqtVFnbYk8 /OrBosTZItVlTR74NQCm6PWlav8qkz8CRQX/YHlCmgzvMbaJke/fSJ9mHOUGKaM5wpGb7pAcm k64KCMpmk2d3qPyXCmyJIZyisy0PtIS/WpW1zOS43OGDpWrCVAWOnTqyGAiG5J5EDA37zItyl ZL2tmZMo4dmmzQtNjciD3IRPKZqIFFCu4VxzRVTX3F9kwhveCNnY3hWGEm5/YU5p+KTGRJzK1 QSO8VqPUpQ8GClDZ08UTAabG8W/p+GqK97M8YdVmFvVXKxIHRAt78B4Kof4iEWBaXnuIq/nC9 U3kJeQ== Subject: Re: [musl] strcmp() guarantees and assumptions Am Sun, Jul 16, 2023 at 07:59:57PM +0200 schrieb Robert Clausecker: > That's good to hear. Any idea on the =E2=80=9Cwhat do existing libc > implementations permit=E2=80=9D bit? > So I quickly checked musl, dietlibc, bionic, and glibc, and unsurprisingly, all of the implementations I looked at allow the strings to be unterminated if they mismatch before access becomes restricted. This is, of course, an implementation detail that applications must not rely on, but it nevertheless is the case. The problem in your implementation is that the calls to strlen() will iterate over both input strings to the end, causing basically a cache flush for large inputs, only to then iterate over both inputs a second time. Iterating only once is a major benefit, since it avoids half of the cache misses. Also, glibc already has an SSE strcmp implementation you may want to look at. Ciao, Markus