From: "nobu (Nobuyoshi Nakada)" Date: 2021-09-08T10:20:00+00:00 Subject: [ruby-core:105177] [Ruby master Bug#18152] Fix theoretical bug with signals + qsort Issue #18152 has been updated by nobu (Nobuyoshi Nakada). Since `qsort_r` isn't a standard, POSIX would not include it. Now we use it on some limited platforms, glibc, some BSDs, and Windows (no signals), I searched info if it's async-signal-safe or not on such platforms but vain. As for `else` part, I've missed the comment and you are correct. How do you think about another "hopefully" comment for `bsearch`? ---------------------------------------- Bug #18152: Fix theoretical bug with signals + qsort https://bugs.ruby-lang.org/issues/18152#change-93581 * Author: eggert (Paul Eggert) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-09-06T18:23:33Z z102 b4d9126e43) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Ruby assumes that qsort is async-signal-safe, but POSIX does not guarantee this and it's not true of some qsort implementations, notably glibc. This is not a practical problem with glibc, since glibc qsort is async-signal-safe with small sorts and in practice Ruby's use of qsort is invariably small enough. However, it's better to be absolutely async-signal-safe, if only to pacify static checkers and the like. I am attaching two alternative patches for the problem. Either will suffice. The first is simple and easier to audit, but does not scale well (though that is not important here). The second patch should scale, but is harder to audit. It would be difficult to write test cases illustrating the bug that these patches fix, as they'd be timing dependent. ---Files-------------------------------- 0001-Fix-theoretical-bug-with-signals-qsort-b.patch (3.56 KB) 0001-Fix-theoretical-bug-with-signals-qsort-a.patch (2.08 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: