GNOME Bugzilla – Bug 660849
Remove cruft from g_strerror and g_strsignal
Last modified: 2011-10-05 05:13:27 UTC
We can just assume that strerror/strsignal are available nowadays. At the same time, make g_strerror threadsafe by using strerror_r instead of strerror, and remove somewhat crazy use of thread-private storage. Instead, always return interned strings.
Created attachment 198183 [details] [review] Remove cruft from g_strerror and g_strsignal
Comment on attachment 198183 [details] [review] Remove cruft from g_strerror and g_strsignal The Windows headers (or at least, the mingw headers) don't define strerror_r, so this will make all errors be "unknown error" on Windows. (In general, Windows doesn't do _r functions, they just use thread-local storage inside the "non-thread-safe" versions.) Also: >+ gchar msg[64]; That may not be enough on Windows. See bug 615494. Also, the docs are wrong now: they still say "not all platforms support the strerror() function." and "The string can only be used until the next call to g_strerror()". Also, should "unknown error (%d)" be translated?
also, there's still a reference to NO_SYS_SIGLIST_DECL
we could bring back a strerror() code-path, at the cost of not being threadsafe.
The following fixes have been pushed: 0e3f530 Remove cruft from g_strerror and g_strsignal 5fef796 Misc test coverage improvements ddbd4ac Need to check for prlimit
Created attachment 198287 [details] [review] Remove cruft from g_strerror and g_strsignal We can just assume that strerror/strsignal are available nowadays. At the same time, drop use of thread-private storage. Instead, always return interned strings.
Created attachment 198288 [details] [review] Misc test coverage improvements
Created attachment 198289 [details] [review] Need to check for prlimit