Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <bf4ef6ce-8fa9-57b8-7d18-2a4cbb41455b@gmail.com>
Date:   Fri, 21 Apr 2023 19:21:36 +0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: strings
Content-Language: en-US
To:     Willy Tarreau <w@1wt.eu>
Cc:     =?UTF-8?Q?Andr=c3=a9_Coelho?= <andrealbergaria@gmail.com>,
        linux-kernel@vger.kernel.org
References: <8de1912e-8009-3c85-ece5-7ca7f03be42a@gmail.com>
 <ZEIPKhKNz7LnhM/q@debian.me> <ZEIuh80SfDms30dc@1wt.eu>
From:   Bagas Sanjaya <bagasdotme@gmail.com>
In-Reply-To: <ZEIuh80SfDms30dc@1wt.eu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 4/21/23 13:34, Willy Tarreau wrote:

>> Looks like above link is about hex arithmetic implemented using strings,
>> right?
> 
> It looks more like a reinvention of the classical multi-byte string
> processing (memcmp, memcpy, memmove etc).
> 
>> Also, on what use cases can your idea fit the kernel context? Or doesn't the
>> kernel already have the implementation yet?
> 
> Sure it does, look at __crypto_memneq() for example, or more generally
> at any memcmp() or memcpy() implementation from the last 30 years, for
> example in glibc.
> 

Thanks for explanation! I don't have any serious C[++] programming
background, so I was confused when I wrote the original reply.

-- 
An old man doll... just what I always wanted! - Clara