-
Thomas Haller authored
We have various options for strerror(), with ups and downsides: - strerror() - returns pointer that is overwritten on next call. It's convenient to use, but dangerous. - not thread-safe. - not guaranteed to be UTF-8. - strerror_r() - takes input buffer and is less convenient to use. At least, we are in control of when the buffer gets overwritten. - there is a Posix/XSI and a glibc variant, making it sligthly inconvenient to used. This could be solved by a wrapper we implement. - thread-safe. - not guaranteed to be UTF-8. - g_strerror() - convenient and safe to use. Also the buffer is never released for the remainder of the program. - passing untrusted error numbers to g_strerror() can result in a denial of service, as the internal buffer grows until out-of-memory. - thread-safe. - guaranteed to be UTF-8 (depending on locale). Add our own wrapper nm_strerror_native(). It is: - convenient to use (returning a buffer that does not require management). - slightly dangerous as the buffer gets overwritten on the next call (like strerror()). - thread-safe. - guaranteed to be UTF-8 (depending on locale). - doesn't keep an unlimited cache of strings, unlike g_strerror(). You can't have it all. g_strerror() is leaking all generated error messages. I think that is unacceptable, because it would mean we need to keep track where our error numbers come from (and trust libraries we use to only set a restricted set of known error numbers).
e1ca3bf7