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