Kang-Che Sung (宋岡哲)

I added a change in the README to mention the use of `pkg-config`. Please review whether the wording is good enough.

The problem in my opinion is that it doesn't make sense to let user specify how to _check_ ncurses. The user should only specify whether ncurses exists, and optionally how...

@BenBE I did read [the linked patch](https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/htop/files/0001-Use-pkg-config.patch?id=110667ac3798b5b64552cb4b8dc706aad8fbcdfe), and thus I get the conclusion we are doing the wrong way. The `--with-check-ncurses` variable should be internal to `configure`. These is no...

> The problem in my opinion is that it doesn't make sense to let user specify how to _check_ ncurses. The user should only specify whether ncurses exists, and optionally...

> Please just use write(). The 25 lines of formatting magic are a bit over-the-top imo. I wish an atomic write() for the "caught signal X" line. Formatting that string...

I am thinking there could be another way to solve the CWE-479 problem, as that warning wasn't present in htop's fatal error reporting code, and yet the fatal error code...

@fasterit What I said is that maybe we don't need another implementation of snprintf(3) at all. As mentioned, GCC 14 doesn't warn about CWE-479 for `CRT_handleSIGSEGV` (maybe this is a...

@BenBE I was thinking deeper that, when another signal arrives during a handler, what kind of message htop's output should look like. To prevent the situation where we implemented our...

@BenBE Oops. I was confused with the CWE-479 issue here because there was actually two sub-issues: * The use of `snprintf` in signal handlers was unsafe - It's nothing to...

> > So why not write a minimal good `safe_snprintf` for our use case? I believe there should be an existing `safe_snprintf` solution for us already, that can be embedded...