From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=6ZiO=43=cristianrodriguez.net=cr@sourceware.org>
Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169])
	by sourceware.org (Postfix) with ESMTPS id 3DB7A3858CDA
	for <libc-alpha@sourceware.org>; Thu, 29 Dec 2022 19:45:44 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3DB7A3858CDA
Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=opensuse.org
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cristianrodriguez.net
Received: by mail-il1-f169.google.com with SMTP id g2so7055482ila.4
        for <libc-alpha@sourceware.org>; Thu, 29 Dec 2022 11:45:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc: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=411yaj+bbZdYwYQ4M00KDSlzU4mRY0/T0rek9e9FQac=;
        b=nfFa0c0fM2I8PwbIiLHymPWH6TqCt0LbOzjGlLpP1WhrAv8aocAgyIFPAMFkjkCga9
         aNxt9pSP+AYTnXoE+BE9zR63aEWvdiWziQOjPcb511vm4jAuNKExOJYDQlzIGft9+wAY
         4JntV6hE9Ag4F1s3NCFmmAtPqVddhiF+cW7TbhpuRhL8vSHfPJeuduIFF3bXxwygPmx4
         aMbaWX85WLMTK8Pmq2WVTuW73wDpi7ar5SjZ+MqcsTD7xXbGc1kRac0Raa9+JgOeGcmv
         5qyoCd9wEoRl8OY29VgsrIOIeaT0YLo8t732tXvnxTZpP0ZEVf1LAk++ShWBo5tTIrcu
         L5zw==
X-Gm-Message-State: AFqh2kqqtaV+vXFt2BsYHzJryzjdHjdRSGggoZw6hQcuNIKOErzD/vw+
	QRB0f3BYmJIk6huw2+SYntKUfs4EvNo/Zjl65s3kpCiHWXmZjw==
X-Google-Smtp-Source: AMrXdXvdfiOrKRjMSUPY+NL5gfKxvJabDI4mjkzS8jLvGDqWtHcMLOCeno37NbgXJUiD+pF+R+vFyCRswNqPVXCfrCk=
X-Received: by 2002:a92:b70e:0:b0:303:7637:ff67 with SMTP id
 k14-20020a92b70e000000b003037637ff67mr3065757ili.298.1672343143429; Thu, 29
 Dec 2022 11:45:43 -0800 (PST)
MIME-Version: 1.0
References: <82db6083-5daa-66f9-2a4e-2823168f1574@gmail.com>
In-Reply-To: <82db6083-5daa-66f9-2a4e-2823168f1574@gmail.com>
From: =?UTF-8?Q?Cristian_Rodr=C3=ADguez?= <crrodriguez@opensuse.org>
Date: Thu, 29 Dec 2022 16:45:32 -0300
Message-ID: <CAPBLoAc94b1XG2mEea3-BS=fqmGvqu_EeRtJLvNDqD3F7fMj=A@mail.gmail.com>
Subject: Re: [manual]: rawmemchr(3) and UB
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>, linux-man <linux-man@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <libc-alpha.sourceware.org>

On Thu, Dec 29, 2022 at 4:20 PM Alejandro Colomar via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Hi,
>
> I was reading rawmemchr(3), and found some funny text:
>
> RETURN VALUE
>         The  memchr()  and memrchr() functions return a pointer to the matching
>         byte or NULL if the character does not occur in the given memory area.
>
>         The rawmemchr() function returns a pointer to the matching byte, if one
>         is found.  If no matching byte is found, the result is unspecified.
>
>
> Of course, if the byte is not found, the result is not unspecified, but rather
> undefined, and a crash is very likely so maybe there's not even a result.  I
> thought this might be a thinko of the manual page, but the glibc manual seems to
> have similar text:
>

The library itself uses this function mostly to find NULL as an
optimization. This is all before GCC handled all of this so it is
mostly obsolete.
gcc replaces null byte searches that use str*chr with s + strlen(s)
and expands memchr c=null  and rawmemchr-like patterns inline.