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.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 13228 invoked from network); 16 Jul 2023 19:25:00 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Jul 2023 19:25:00 -0000 Received: (qmail 32450 invoked by uid 550); 16 Jul 2023 19:24:57 -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 32412 invoked from network); 16 Jul 2023 19:24:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689535484; x=1692127484; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=17Viozk4IuK3OIiNeUiz3PWRNS7AGo37MkXqy7NpRMI=; b=egY9wKFfzBUCP5OaAlzGqQskwaGJbjmQID2cAGef4l6Wn6TPyI29If3i4Gc8hPlBCq Oozd6W7G56GyCMAVHAhJ+sgp/4XEeVPFFmLgboLe00ZVD0kOwc2DwozTp+XXR0+oJk8F cZy43UK3gnOVBVwUVVj+XZSiWujkAykoYXLFd2V5r6HOo6MZ2gBzWRJAVUIJ/sk29zDy w+JchbwQuojz+qN8/8HkTrBs12BIzO3zLLRDB6WqEYP4laP+MZjoS6G1i7/X0/j0J3rQ skvviUoDxKyxx7zX4szilH/Z43G+BBVmdHfZS5aKkNFTSjhrrkKf9VOPuA461etPoGPa pwog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689535484; x=1692127484; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=17Viozk4IuK3OIiNeUiz3PWRNS7AGo37MkXqy7NpRMI=; b=OjtHu4eUl4NZjdDtm1yDQM8eE5QZb3/Bo7HlcO4pOrCQ04LkCK5DWV5D6ZS5fzPSWU MhT4COUE6H4MpQ5MItuKs+I5fARbbDT3xRe/bWphiPM1jqh9IYs8zlKkt3knq8dW95Wh XogvNcq05I6SlY4CPAEHp/MG/KBZQVu5wy+OLRqfT2/9NaE1brlMz0R4OJSNcVBOQ79y XKPiJBR/5AWtT4L4DoSkSfYfGQ3QVp5QADqRX+IgpAEEx2YOH4HpS45hiYW/ky8QjuXT XIEujgJJWKlflJUSQK+z2jiVDbR2lidzuNQEYBKhZzPtiRXV0gy5U/N8wE1/nXq0JYps /r4Q== X-Gm-Message-State: ABy/qLYqYncMd8th1jaXI/qJMCvLnFv3UgKsfps42LusQ9acmpDJxnj/ m+nC+TyfsanR3zHp6NB400iD3kpQqi7l7f/OoqqGqcLn X-Google-Smtp-Source: APBJJlHc2lxn2gHc0Cwq36yQx5k0EIBN6d79mP1Tt2H+VIqzRmLtrFa3hkCsnLlsjSu3wj55ri0X31TXvZFKLSPNZOw= X-Received: by 2002:a1f:3d84:0:b0:483:fce5:b085 with SMTP id k126-20020a1f3d84000000b00483fce5b085mr13280vka.5.1689535484338; Sun, 16 Jul 2023 12:24:44 -0700 (PDT) MIME-Version: 1.0 References: <20230716174945.qc6234b654k5eebx@gen2.localdomain> In-Reply-To: From: Pedro Falcato Date: Sun, 16 Jul 2023 20:24:33 +0100 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] strcmp() guarantees and assumptions On Sun, Jul 16, 2023 at 7:00=E2=80=AFPM Robert Clausecker wrot= e: > > Hi NRK, > > Thank you for your response. > > Am Sun, Jul 16, 2023 at 11:49:45PM +0600 schrieb NRK: > > Hi Robert, > > > > > Or to phrase it differently, is the following a legal implementation = of > > > strcmp()? > > > > > > int strcmp(char *a, char *b) { > > > size_t la =3D strlen(a), lb =3D strlen(b); > > > > > > if (la !=3D lb) > > > return ((la > lb) - (lb > la)); > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > I don't see how this can ever be a valid strcmp implementation. The > > return value of the comparison functions must be about the first > > mismatching byte, not about the string lengths. > > > > | The sign of a nonzero value returned by the comparison functions is > > | determined by the sign of the difference between the values of the > > | first pair of characters that differ in the objects being compared. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Yes, sorry. The code would have to be extended to call memcmp() on the > common prefix in case there is a mismatch in length. E.g. > > if (la !=3D lb) > return (memcmp(la, lb, la > lb ? lb + 1 : la + 1)); > > > ref: https://port70.net/~nsz/c/c11/n1570.html#7.24.4p1 > > > > > Or is it generally agreed upon that libc implementations support > > > strcmp() calls on unterminated strings? > > > > memchr (since C11) has the following requirement: > > > > | The implementation shall behave as if it reads the characters > > | sequentially and stops as soon as a matching character is found. > > > > I don't believe any such requirement exists for strcmp, so unless > > someone proves otherwise, I'd say it's fair game for libc to assume tha= t > > the strings are nul-terminated. > > That's good to hear. Any idea on the =E2=80=9Cwhat do existing libc > implementations permit=E2=80=9D bit? Looks like it's permissive. At the moment, musl does (non-SIMD, obviously) unsigned long loads *as long as they're aligned* (you don't want to page fault! and reads don't have side effects unless it's MMIO or something, and that's non-standard) and does standard(tm) bit tricks to find null bytes in that same word. --=20 Pedro