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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30021 invoked from network); 1 Oct 2020 15:47:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2020 15:47:17 -0000 Received: (qmail 11867 invoked by uid 550); 1 Oct 2020 15:47:15 -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 11849 invoked from network); 1 Oct 2020 15:47:15 -0000 Date: Thu, 1 Oct 2020 11:47:03 -0400 From: Rich Felker To: Ellie Cc: musl@lists.openwall.com Message-ID: <20201001154702.GQ17637@brightrain.aerifal.cx> References: <47f2d2dc-0f18-5d86-8206-1196502b60e0@wobble.ninja> <20201001023528.GM17637@brightrain.aerifal.cx> <03e1484f-0f66-b86a-d717-45ee1eb32790@wobble.ninja> <805b0ccb-5f71-afdf-8898-6d5a9435d10b@wobble.ninja> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Would it to be possible to get strtoll_l? On Thu, Oct 01, 2020 at 10:08:17AM +0200, Ellie wrote: > Hah, sorry for the e-mail spam, I'm only now just realizing I read over > your latest remark that strtoll doesn't really change in behavior. > > Yeah, I have actually be wondering how strtoll even could be > locale-specific, but assumed surely there'd be some corner case I don't > know about. > > But if that makes it just an alias of strtoll effectively, would it be > possible to add strtoll_l to musl just for the sake of completion? Since > it exists for most platforms (glibc, bsd, windows) who knows how this > will be changed to behave in the future, I'd rather use the "proper" > function and be on the safe side. > > In any case, thanks for the insightful response! A *complete* set of *_l functions (for all operations that are locale-dependent) would be rather large, and would include a lot that don't really admit such thin implementations e.g. because they'd have variadic signatures. It looks like the set chosen for standardization mostly covered just the ones where the function itself was expected to be so small/fast that setting the thread-local locale around the call would be relatively expensive, but some don't fit that pattern, like strftime_l. And then on top of that, we seem to have a somewhat inconsistent coverage set for non-standardized BSD/GNU extensions -- wcsftime_l, strtod_l, etc. A big part of maintainership, especially for libc, is saying no. In this case, it might make sense to add a few more nonstandard ones, especially if we already have most but not all of them and there's a clear bounded set of what would be supported and they're all things that admit ultra-thin wrappers. Would you be interested in investigating that and following up? Rich