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.3 required=5.0 tests=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 561 invoked from network); 16 Jun 2022 16:45:39 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Jun 2022 16:45:39 -0000 Received: (qmail 9577 invoked by uid 550); 16 Jun 2022 16:45:37 -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 9533 invoked from network); 16 Jun 2022 16:45:36 -0000 Date: Thu, 16 Jun 2022 12:45:23 -0400 From: Rich Felker To: NRK Cc: musl@lists.openwall.com Message-ID: <20220616164523.GL7074@brightrain.aerifal.cx> References: <20220609203426.GE7074@brightrain.aerifal.cx> <20220616161924.vdkujlgyrh4aebq7@gen2.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220616161924.vdkujlgyrh4aebq7@gen2.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] hostname is using a case sensitive search in function name_from_hosts On Thu, Jun 16, 2022 at 10:19:24PM +0600, NRK wrote: > On Thu, Jun 09, 2022 at 04:34:27PM -0400, Rich Felker wrote: > > strcasestr isn't a good match here, because it's quadratic time and > > would be potentially quite slow (depending on file contents). It's > > also not in a usable namespace, and is something of a junk function we > > included for questionable reasons. > > A bit off-topic, but is there any desire to improve the strcasestr > performance? If there is, then I can supply the patch as I was playing > around with it a couple weeks ago. I'm not sure. It's an interesting research problem whether it can be made linear-time in constant space -- I mean, for a dumb single-byte-only version like we do now, I'm pretty sure it can, but I'm doubtful the same can be done for one that respects full multibyte case mapping. But aside from that, I'm not sure if there's much practical value. The function is not really appropriate for much real-world use, especially as long as it doesn't respect non-ASCII case mappings, and was probably a mistake to include to begin with. If there are simple changes that could be made to make it "less awfully slow", that's probably ok, but anything that involves open-coding a more complex implementation without actually making this a high-quality usable function seems like an unwanted increase in code complexity and potential bug-surface/maintenance-burden without a good motivation. Rich