develooper Front page | perl.perl5.porters | Postings from April 2016

Re: RFC: refuse to change into an unsupported locale

Thread Previous | Thread Next
Karl Williamson
April 27, 2016 16:17
Re: RFC: refuse to change into an unsupported locale
Message ID:
On 04/27/2016 08:21 AM, Sawyer X wrote:
> On 04/27/2016 02:27 PM, Zefram wrote:
>> Sawyer X wrote:
>>> If we can detect it will crash
>> That's generally impossible.  We can potentially detect at configure
>> time that libc has a particular bug, and that's a useful strategy for
>> things that we can work around by substituting our own implementation.
>> But locale stuff isn't at all feasible to reimplement: our only strategy
>> for it is to call libc, and the most we could do based on a configure test
>> is to decline to call libc on arguments that we think it'll mishandle.
> I meant, how you phrased it, to "decline to call libc on arguments that
> we think it'll mishandle". That will probably require checking libc.
>> We should only thus limit the functionality when we're sure that libc
>> would in fact crash.  Crucially, the configure test can't tell us when
>> libc's bug gets fixed post-installation, nor can we test for the bug at
>> runtime when the result of the test may be a crash.  So any such crash
>> avoidance would inevitably cause us to refuse to process locales in some
>> situations where it would actually have worked.
> Zefram and I continued this on IRC and he added the following, which I
> wanted to add here:
> <Zefram> if libc advertises its version number at runtime, then
> comparing that against a blacklist of known-buggy versions to avoid
> calling a crashing setlocale would be sane.  not as nice as an empirical
> test, but OK when we can't do that
> <Zefram> though also watch out for symbol versioning, which might mean
> you have to incorporate some knowledge of which version of the setlocale
> symbol you linked against at build time
> Karl might have a different idea in mind though.

I think you guys are missing my main point.

There are some cultures in which people don't like to say "no" to a 
stranger.  So, if you ask "Is this the road to X?", they'll typically 
answer yes, even if you're going the wrong way.  Hours/days later you 
discover that it wasn't the road to X.  These people did not do you a 
favor by saying "yes".  Quite the opposite.

A programming language that says yes to something it could know will not 
deliver a correct result is like those people.  It is not doing anyone 
any favors. Quite the opposite.

On platforms that support at least POSIX 2001, we can know that some 
locales are not going to yield correct results in many cases.  I assert 
that we should not allow you to change into such a locale, and I am 
adding now, that we probably should raise a warning when you try, 
besides returning failure.

This seems obvious to me.

The reason this came up now, is I'm finding segfaults in a locale that 
is not byte-oriented.  The failing function is not one which should even 
be called on such a locale; instead the wide-char version should be the 
one used.  I don't believe Perl should be enhanced to accept non-byte 
locales, but I think we have a responsibility to not say "yes" when 
someone tries to use such a locale (and then giving bad results, even if 
a segfault doesn't happen)

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About