[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c127ba0d-ced6-a248-7484-6a5e378b102b@wobble.ninja>
Date: Wed, 7 Oct 2020 15:44:11 +0200
From: ell1e <kittens@...ble.ninja>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: 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
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
