Kang-Che Sung (宋岡哲)

@natoscott I assume you have read #1784 and #1785 for the discussion I had with @BenBE before. Basically I would vote for using qsort() (#1784) if there isn't a stability...

> The main (only?) data we need to sort is the process section (lower part) of the htop display, of course, where we always have a unique identifier (PID) for...

> If a different algorithm significantly outperforms qsort for sorting processes in htop, we should use it. @natoscott @BenBE Just a minor note. Sorting algorithms' performance can be compared with...

> There are differences in the calling conventions between platforms, but they are trivially resolved via wrapper. The catch is how to detect the calling conventions. ```c // Older BSD...

> If we did need qsort_r for some unusual / new platform, there are plenty of existing, tested, robust implementations to pick from that are license-compatible with htop - choose...

> Can you note, which commits for the first vs. second part? I assume the first commit ("Rename *" for the first and the remaining 4 later? Yes, the first...

> Do we have alternative backends for backtracing/demangling besides unwind-ptrace and iberty? Given there's both an unwind implementation in LLVM and GCC, what else are sensible alternatives that warrent implementation...

I would like to hand this branch over to @MrCirdo. I think I have done with this. After this is handed over, I have some comments on @MrCirdo 's code,...

> > My primary concern about supporting the BSD platform (FreeBSD, NetBSD, macOS, etc) is that I don't know if `ptrace(2)` has the same behavior everywhere. (I suppose yes, but...

> > My primary concern about supporting the BSD platform (FreeBSD, NetBSD, macOS, etc) is that I don't know if `ptrace(2)` has the same behavior everywhere. (I suppose yes, but...