Front page | perl.perl5.porters |
Postings from April 2016
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. > 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 > My solution would be to check for the bug on perl proc startup and set a C global. Checking for the bug involves trapping the SEGV and resuming execution. I once did something similar with a Microsoft system DLL, the perl XS module croaks in BOOT if the system DLL is buggy after the runtime test. The bug was 100% reproducible, since the bug was that if the 2nd to last in the queue "event source" fires an event, the last "event source" in the queue is removed from monitoring instead of the 2nd to last event. It was an off by 1 in a memcpy collapsed the array of event sources. Since the C function was undocumented by MS, a later version of the DLL silently fixed the bug. The C function isn't used anymore by me since it was a undocumented backport under a different name of an API added officially to Windows 2000 and newer and the undocumented backport was for Dos Windows and NT4 compat only.Thread Previous | Thread Next