[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140727072855.GA16795@example.net>
Date: Sun, 27 Jul 2014 09:28:55 +0200
From: u-igbb@...ey.se
To: musl@...ts.openwall.com
Subject: Re: Locale bikeshed time
On Sat, Jul 26, 2014 at 03:30:15PM -0400, Rich Felker wrote:
> The original locale plan was based on the principle that the whole
> locale system in C/POSIX is poorly designed, but that it's still the
Sure.
> basis for supporting native-language interfaces in software, and thus
> that musl should eventually have the minimal locale support necessary
> for enabling such usage. Using the locale system as a means for
> arbitrary non-essential customization, support for legacy character
> encodings, etc. is outside the scope of that.
Sounds pretty reasonable.
> > If anybody else feels for using "," than so be it in the corresponding
> > locale, as the default or as a variant - how much would it cost?
This (the cost) is as I see it the main consideration.
> > Actually I very much dislike software which expects that it knows my
> > situation better than myself and prevents me from doing what I need.
>
> And what about character encoding? Should we also support Latin-1? Or
This is a different matter, not exactly about cost against perceived
benefit.
You _do_ offer a means to represent the user's data by unicode/utf-8,
so the desired function (e.g. to represent åäöü) is available.
It is different with the radix point as there is hardly another means for
helping the user to handle her grandmother's favourite radix character.
There is a difference between computing-related preferences like
"I like Latin-1 and refuse to recode my data to utf-8" and the
real life ones like "I grew up in Germany and despite 20 years in USA
still confuse 24 and 42 in English".
What you call "a single pixel" makes for some people the difference
between apparent legibility and gibberish. Note, one e.g. can be very
much used to interpreting '.' as a thousand delimiter and will be utterly
confused by 3.142 .
> ISO-2022? One thing I don't like about how the whole locale discussion
> has gone is that, once one one thing is added, demands for more and
> more things that have much higher implementation and maintenance
I do not demand for more things, I just want to go after cost vs benefit.
If the cost is high we may have to drop even very useful features.
Without analysing the code I can not say how dangerous / bothersome /
complex it would be to support one alternative character as radix dot and
weight this against making about half the human population 1% happier. :)
(A third character for radix dot would certainly affect much less
than half the population).
It is you who have a say about the balance, I just call for objective
reasoning. Being generally upset about "feature proliferation" does
not help, features is what any software is about. Do not doubt, in my
eyes compactness and simplicity => robustness and safety are extremely
important features, as they are for you.
> practical benefit, keep popping up. Radix points is definitely such an
> item where the cost (in terms of bug/security risks, code size, making
> state-free code stateful, maintenance, and just plain being ugly, ...)
> is relatively high
It is your competence area.
> and the benefits are near-zero.
But this one is possibly to some degree outside of your personal
experience and you may _possibly_ have a biased impression.
That's why I dare to spend the precious time of yours and of mine
for this discussion. Thanks for listening and of course for musl as it
is - clean and useful.
Yours,
Rune
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.
