From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id 898F93858C27 for ; Thu, 16 Sep 2021 21:27:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 898F93858C27 Received: by mail-lf1-x12d.google.com with SMTP id y28so23994851lfb.0 for ; Thu, 16 Sep 2021 14:27:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Eb9TncYw9ZYh/CVnAGU7/EBGUHef501ltPeHMO8q7NE=; b=L8z9dRI4BaCla7Lbx+0OH0G5C14Oxk9LB53Nb5pM9AP9WPvvjlnB/Qx941jjKOJNWa MMBoLX49H+HaIfrXUL7yG1METZhF7pKQKh9wjBaX/q4gkn3/WfENDfesE4bcii1cuhzy fuSgBIB1O+1qwXSaCy5Q/brXO8Pes8LSe9HAXLVMmF8mcZAK1sL/rNOi7LtFjnISvV+L pB8q0ox/SCkiEQu6ClPwABFxs7td60A6g4ruY9PNUprrDHQCkhHitkXWvrR3PZJCa4mg NDGyLZKdCFzPZZbTLw0XTNjtLVbN5eDGlSkJGYG4i2+1lYpFgdGPUWc5t3KmI3LnEgsN LERA== X-Gm-Message-State: AOAM532K2XNcIXB1yeO6/KSGaPxTt7346h4ojiBssh/qI87wXxP0EWyt zQgR2vpWJ5ZzbtP8ev0PvFhoKR2BGbgjYGWud094TsIH0VA= X-Google-Smtp-Source: ABdhPJz4pqHbQqZhiyYcAttfQ10EWWUW4iNh2xFjxRDN6+ibn8f/ty5+uZ96i0BccG74/a8eFe7LSVlSWk/pWBI0RXo= X-Received: by 2002:ac2:58ef:: with SMTP id v15mr5851673lfo.34.1631827657216; Thu, 16 Sep 2021 14:27:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: James Y Knight Date: Thu, 16 Sep 2021 17:27:10 -0400 Message-ID: Subject: Re: [libc-coord] Add new ABI '__memcmpeq()' to libc To: libc-coord@lists.openwall.com Cc: GNU C Library , gcc@gcc.gnu.org X-Spam-Status: No, score=-17.1 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 21:27:41 -0000 Wouldn't it be far simpler to just un-deprecate bcmp? On Thu, Sep 16, 2021 at 1:04 PM Noah Goldstein wrote: > Hi All, > > This is a proposal for a new interface to be supported by libc. > > The new interface is the same as the old 'bcmp()' routine. Essentially > the goal of this proposal is to add a reserved namespace for a new > function, '__memcmpeq()', which shares the same behavior as the old > 'bcmp()'. > > #### Interface #### > > int __memcmpeq(void const * s1, const void * s2, size_t n) > > > #### Description #### > > The '__memcmpeq()' function would compare the two byte sequences 's1' > and 's2', each of length 'n'. If the two byte sequences are equal, the > return would be zero. Otherwise it would return some non-zero > value. 'memcmp()' is a valid implementation of '__memcmpeq()'. > > > #### Use Case #### > > 1. The goal is that '__memcmpeq()' will be usable as an optimization > by compilers if a program uses the return value of 'memcmp()' as a > boolean. For example: > > > void foo(const void* s1, const void* s2, size_t n) > { > if (!memcmp(s1, s2, n)) { > printf("memcmp can be optimized to __memcmpeq in this use case\n"); > } > } > > > - In the above case '__memcmpeq()' could be used instead. Due to the > simpler constraints on the return value of '__memcmpeq()', it will > be able to be implemented more optimally for this case than > 'memcmp()'. If there is no separately optimized version of > '__memcmpeq()' can alias 'memcmp()' and thus be at least equally as > fast. > > 2. Possibly use cases in security as the runtime of the function will > be *more* oblivious to the byte sequences being compared. > > > #### Argument Specifications #### > > 1. 's1' > - All 'n' bytes in the byte sequence starting at 's1' and ending > at, but not including, 's1 + n' must be accessible memory. There > are no guarantees about the order the sequence will be > traversed. > 2. 's2' > - All 'n' bytes in the byte sequence starting at 's2' and ending > at, but not including, 's2 + n' must be accessible memory. There > are no guarantees about the order the sequence will be > traversed. > 3. 'n' > - 'n' may be any value that does not violate the specifications on > 's1' and 's2'. > > If any of the argument specifications are violated there are no > guarantees about the behavior of the interface. > > > #### Return Value Specification #### > > If the byte sequences starting at 's1' and 's2' are equals the > function will return zero. Otherwise the function will return a > non-zero value. > > Equality between the byte sequences starting at 's1' and 's2' is > defined as follows: > > 1. If 'n' is zero the two sequences are zero. > 2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at > offset 'i' of 's1' equals the byte at offset 'i' in 's2'. > > For a simple C implementation of '__memcmpeq()' could be as follows: > > > int __memcmpeq(const void* s1, const void* s2, size_t n) > { > int ret; > size_t i; > const char *s1c, *s2c; > s1c = (const char*)s1; > s2c = (const char*)s2; > for (i = 0, ret = 0; ret == 0 && i < n; ++i) { > ret = s1c[i] - s2c[i] > } > return ret; > } > > > #### Notes #### > > This interface is essentially old 'bcmp()' and 'memcmp()' will always > be a valid implementation of '__memcmpeq()'. > > > #### ABI vs API #### > > This proposal is for '__memcmpeq()' as a new ABI. As an ABI > '__memcmpeq()' will have value, as using the return value of > 'memcmp()' is quite idiomatic in C code. > > It is, however, possible that this would also be useful as a new API > as well. Especially if there are likely use cases where the compiler > would be unable to prove that '__memcmpeq()' would be a valid > replacement for 'memcmp()'. > > > #### Further Options #### > > If this proposal is received positively, libc could also add > interfaces for '__streq()', '__strneq()', '__wcseq()' and '__wcsneq()' > which similarly would loosen return value restrictions on 'strcmp()', > 'strncmp()', 'wcscmp()' and 'wcsncmp()' respectively. > > Best, > Noah >