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.5 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24143 invoked from network); 7 Oct 2020 13:44:31 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Oct 2020 13:44:31 -0000 Received: (qmail 14149 invoked by uid 550); 7 Oct 2020 13:44:23 -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 14126 invoked from network); 7 Oct 2020 13:44:22 -0000 To: Rich Felker Cc: musl@lists.openwall.com 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> <20201001154702.GQ17637@brightrain.aerifal.cx> From: ell1e Message-ID: Date: Wed, 7 Oct 2020 15:44:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20201001154702.GQ17637@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [musl] Would it to be possible to get strtoll_l? Hi Rich, I admit I have a very biased view. Let me first preface this with saying that for my program, this issue is now solved. However, I think there might be some use if I explain further where I am coming from, and what I think about adding more *_l() functions: This is how I came to here, asking about strtoll_l(): 1. I wouldn't necessarily know that strtoll doesn't really PRACTICALLY do locale dependent changes, and same might apply to other people. I did however realize that in general, process-wide setlocale() doesn't seem to have died out yet, and for some programs written to work with 3rd party plugins (that may basically do whatever) this is a big problem. As a result, picking strtoll_l was a best effort decision with limited knowledge, based on a default careful approach (which has proven useful writing C over the years) to rather pick non-locale dependent stuff out of principle, just to be safe. It wasn't because I identified strtoll_l() in particular to be necessary, or even useful. 2. All platforms including even Windows 10, and macOS, seem to have realized that locale-dependent basic string formatting is occasionally a giant annoying headache and a mess, and therefore offer *_l functions for pretty much everything. And so does glibc. So again it seemed only natural to me to pick strtoll_l(), as a spontaneous decision. That this might cause a problem with musl wasn't something that occurred to me at first. 3. I only then HAPPENED to even check with musl libc. (Since I run it on my linux phone.) Then I only happened to go as far as to ask here on the mailing list, instead of not bothering for now and just writing off musl libc compatibility. Of course the most "proper" way to deal with this would be feature detection, but for some smaller projects that otherwise don't rely on much otherwise "arcane" functionality that may seem like overkill. 4. I then also just happened to have an overmotivated friend who was bored enough to write a custom str-to-int and contributed it, so that I no longer depend on either of strtoll/strtoll_l, which is why this is solved for me now. However, I think this chain of events still shows that *_l() coverage would be useful, in general, for a majority of string functions, even in cases where it might seem technically useless. This is of course from the angle of app developers and maintainers, who do their best effort but ultimately not always best-informed decisions picking string formatting functions, and then possibly run into this *_l() issue on musl when porting. But then again, most of these things can be worked around when porting to musl. But how many people will bother, and how many programs be left behind as a result and not work on Alpine etc.? Is that some quantity that will bother anyone? (My plan before I got the helpful contribution for example was to just skip musl compatibility for a while before I had some more time to either add feature detection, or revisit this issue in other ways. But would anyone have cared not being able to run my program in particular? I honestly can't tell you.) I don't think I can give you further insight than this. Nevertheless, I hope that wall of text had something of use for you. Regards, ell1e On 10/1/20 5:47 PM, Rich Felker wrote: > 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 >