Front page | perl.perl5.porters |
Postings from April 2016
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