After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660849 - Remove cruft from g_strerror and g_strsignal
Remove cruft from g_strerror and g_strsignal
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-10-04 05:28 UTC by Matthias Clasen
Modified: 2011-10-05 05:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove cruft from g_strerror and g_strsignal (19.17 KB, patch)
2011-10-04 05:28 UTC, Matthias Clasen
none Details | Review
Remove cruft from g_strerror and g_strsignal (18.94 KB, patch)
2011-10-05 05:13 UTC, Matthias Clasen
committed Details | Review
Misc test coverage improvements (2.65 KB, patch)
2011-10-05 05:13 UTC, Matthias Clasen
committed Details | Review
Need to check for prlimit (810 bytes, patch)
2011-10-05 05:13 UTC, Matthias Clasen
committed Details | Review

Description Matthias Clasen 2011-10-04 05:28:09 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.
Comment 1 Matthias Clasen 2011-10-04 05:28:12 UTC
Created attachment 198183 [details] [review]
Remove cruft from g_strerror and g_strsignal
Comment 2 Dan Winship 2011-10-04 12:16:55 UTC
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?
Comment 3 Dan Winship 2011-10-04 12:18:59 UTC
also, there's still a reference to NO_SYS_SIGLIST_DECL
Comment 4 Matthias Clasen 2011-10-04 14:36:17 UTC
we could bring back a strerror() code-path, at the cost of not being threadsafe.
Comment 5 Matthias Clasen 2011-10-05 05:13:19 UTC
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
Comment 6 Matthias Clasen 2011-10-05 05:13:22 UTC
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.
Comment 7 Matthias Clasen 2011-10-05 05:13:24 UTC
Created attachment 198288 [details] [review]
Misc test coverage improvements
Comment 8 Matthias Clasen 2011-10-05 05:13:27 UTC
Created attachment 198289 [details] [review]
Need to check for prlimit