From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by sourceware.org (Postfix) with ESMTPS id AD98F3858C50 for ; Sun, 2 Apr 2023 17:54:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AD98F3858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-io1-xd34.google.com with SMTP id x3so4403108iov.3 for ; Sun, 02 Apr 2023 10:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680458072; x=1683050072; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3NAMMMWo65StZzvLsc0rsjp/hRLDgqIxeY0oi6WYpSU=; b=J6A9FuaBFp7FwFPeL5+YIpO3hDUCDcEXqCAS27tJPYAM/NxfSLL+4IgJ0UbPi1tMni Te1yBgwWxqC9BYlJz6r6d1GLwaM57e4K0JZ5vP9mCb+Nh+6UU+vp+rDOikfrdcEewtkK 8c5HePONa6lkRopl7tYOf+RexeN0K6OVLfnfaSYwHaYo+xQ6uXL2xAfCD+jqsQ0kgrdW 3+9N4ntLSTfYJ24kEiuZmyv+CQbETQ4JDbr+cXghwYim5d+PDN0NaidTjNmkpbO+QiHS edSCa4CQ7+v41NCZrH9YIlcqhXOL1p0OODdQbNXSfHxZnArEG59CDKJYY1WGNxAxFGFo FIcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680458072; x=1683050072; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3NAMMMWo65StZzvLsc0rsjp/hRLDgqIxeY0oi6WYpSU=; b=PT5Q0PaxrPJoxGWO1YTravsZg2jgb2DOl7ZXKTFlJmsv+qnTcCA1p03E7DgNcoEbUZ G1LaqYlaalnTchq3dd/wfx00ZX4tUtjR1KApxCE1YyL/HGBs9LURA+udXr75v7c6bBAr jynWprGBxzDhudViTnj7Efc0U6M8lf58dlLvaneYPI4Ng79FWbkWliP2WWpj8mcWPcwf OKwrXXFIsK7tdTlw5aZrrMozb3Ho/rci7GpLU3cIUdFQoHeenu45n81vAN/1Un24ymDF 6vx0DHMIQ+2Ufk5+EFtT08t4boeg3GQnjtYWuf9G+nTMwAGHJ4RvtGSW5S0uBUoFp8EO mlLA== X-Gm-Message-State: AAQBX9e5iw14M4X2+G3itfrbrWaRnHMlR6SfnO/byToFqlXtnHZiQDYE TrGqN3E9B3na0vQUjc8G3Zw= X-Google-Smtp-Source: AKy350am9qPEMjUEhYe1HeChayQSEAOqDbjGW2Pf5E4PJNt39leuWZN3yOX5JqynVyD5rjQWFcrd9Q== X-Received: by 2002:a5e:d912:0:b0:75c:3b4a:d13f with SMTP id n18-20020a5ed912000000b0075c3b4ad13fmr17537762iop.14.1680458071608; Sun, 02 Apr 2023 10:54:31 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id f3-20020a028483000000b00405a267abf5sm2079898jai.115.2023.04.02.10.54.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Apr 2023 10:54:31 -0700 (PDT) Message-ID: <044acb6b-7564-d03d-218d-7d40e3a6d4ad@gmail.com> Date: Sun, 2 Apr 2023 11:54:30 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] libiberty: Make strstr.c in libiberty ANSI compliant Content-Language: en-US To: Jakub Jelinek , Jeff Law Cc: Seija Kijin , gcc-patches@gcc.gnu.org References: <9e7e3075-5347-ac3a-21a1-dbcd5e7a9d93@redhat.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 3/29/23 09:00, Jakub Jelinek via Gcc-patches wrote: > On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote: >> >> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote: >>> The original code in libiberty says "FIXME" and then says it has not been >>> validated to be ANSI compliant. However, this patch changes the function to >>> match implementations that ARE compliant, and such code is in the public >>> domain. >>> >>> I ran the test results, and there are no test failures. >> >> Thanks.  This seems to be the standard "simple" strstr implementation. >> There's significantly faster implementations available, but I doubt it's >> worth the effort as the version in this file only gets used if there is >> no system strstr.c. > > Except that PR109306 says the new version is non-compliant and > is certainly slower than what we used to have. The only problem I see > on the old version (sure, it is not very fast version) is that for > strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because > strchr in that case changed p to point to the last character and then > strncmp returned 0. > > The question reported in PR109306 is whether memcmp is required not to > access characters beyond the first difference or not. > For all of memcmp/strcmp/strncmp, C17 says: > "The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp > is determined by the sign of the difference between the values of the first pair of characters (both > interpreted as unsigned char) that differ in the objects being compared." > but then in memcmp description says: > "The memcmp function compares the first n characters of the object pointed to by s1 to the first n > characters of the object pointed to by s2." > rather than something similar to strncmp wording: > "The strncmp function compares not more than n characters (characters that follow a null character > are not compared) from the array pointed to by s1 to the array pointed to by > s2." > So, while for strncmp it seems clearly well defined when there is zero > terminator before reaching the n, for memcmp it is unclear if say > int > memcmp (const void *s1, const void *s2, size_t n) > { > int ret = 0; > size_t i; > const unsigned char *p1 = (const unsigned char *) s1; > const unsigned char *p2 = (const unsigned char *) s2; > > for (i = n; i; i--) > if (p1[i - 1] != p2[i - 1]) > ret = p1[i - 1] < p2[i - 1] ? -1 : 1; > return ret; > } > wouldn't be valid implementation (one which always compares all characters > and just returns non-zero from the first one that differs). > > So, shouldn't we just revert and handle the len == 0 case correctly? > > I think almost nothing really uses it, but still, the old version > at least worked nicer with a fast strchr. > Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred > because strchr already compared the first character. > > 2023-03-29 Jakub Jelinek > > PR other/109306 > * strstr.c: Revert the 2020-11-13 changes. > (strstr): Return s1 if len is 0. I really don't think the performance of this code matters. If this fixes the compliance issue, then it's fine with me. Jeff