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 733821 - g_strerror() uses strerror(3) instead of strerror_r(3)
g_strerror() uses strerror(3) instead of strerror_r(3)
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-07-27 14:17 UTC by Saggi Mizrahi
Modified: 2017-07-29 21:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to enable strerror_r(3) where available (1.51 KB, patch)
2014-07-28 15:26 UTC, Saggi Mizrahi
rejected Details | Review
gio: Use g_strerror() instead of strerror() (7.09 KB, patch)
2017-06-20 13:58 UTC, Philip Withnall
committed Details | Review

Description Saggi Mizrahi 2014-07-27 14:17:57 UTC
g_strerror() uses strerror(3) instead of strerror_r(3) making it not thread-safe.
This might cause unexpected consequences as it is assumed to be thread safe.

This also goes against the advice in the threading docs suggesting people to use said function.

"C library functions that return data in statically allocated buffers, such as strtok() or strerror(). For many of these, there are thread-safe variants with a _r suffix, or you can look at corresponding GLib APIs (like g_strsplit() or g_strerror())." [1]

[1] https://developer.gnome.org/glib/stable/glib-Threads.html
Comment 1 Dan Winship 2014-07-28 14:35:27 UTC
g_strerror() is probably older than strerror_r()...

Anyway, patches welcome. You'd have to include a test for strerror_r in configure.ac as well.
Comment 2 Saggi Mizrahi 2014-07-28 15:26:08 UTC
Created attachment 281875 [details] [review]
Patch to enable strerror_r(3) where available
Comment 3 Saggi Mizrahi 2014-08-26 15:16:49 UTC
Any updates about this?
Comment 4 Igor Pashev 2017-06-20 13:29:49 UTC
See #754788
Comment 5 Philip Withnall 2017-06-20 13:47:46 UTC
Review of attachment 281875 [details] [review]:

strerror_r() was introduced to g_strerror() in 2015 in 36fac0849ceabafb9e2a15045230833e7dbc9e9d.
Comment 6 Philip Withnall 2017-06-20 13:48:16 UTC
There are various places in GLib which still use strerror() directly, though, which should be ported to g_strerror(). Patch coming.
Comment 7 Philip Withnall 2017-06-20 13:58:57 UTC
Created attachment 354103 [details] [review]
gio: Use g_strerror() instead of strerror()

This marginally improves thread safety, and marginally improves
consistency.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Comment 8 Colin Walters 2017-06-20 21:00:26 UTC
Review of attachment 354103 [details] [review]:

LGTM.
Comment 9 Philip Withnall 2017-06-21 10:20:55 UTC
Attachment 354103 [details] pushed as 18f8b77 - gio: Use g_strerror() instead of strerror()
Comment 10 Christian Persch 2017-06-21 18:13:26 UTC
Noticed the commit in git, and saw that in many places this code uses errno directly, like

g_set_error(...., _("foo..."), ..., g_strerror(errno))

where it really needs to do the 

int errsv = errno;
g_set_error(...., g_strerror(errsv))

dance instead, to preserve the actual error, not any errno that the _() call may set.
Comment 11 Philip Withnall 2017-06-22 07:53:04 UTC
(In reply to Christian Persch from comment #10)
> Noticed the commit in git, and saw that in many places this code uses errno
> directly, like
> 
> g_set_error(...., _("foo..."), ..., g_strerror(errno))
> 
> where it really needs to do the 
> 
> int errsv = errno;
> g_set_error(...., g_strerror(errsv))
> 
> dance instead, to preserve the actual error, not any errno that the _() call
> may set.

True. Do you want to put together a patch?
Comment 13 Christian Persch 2017-07-29 21:39:30 UTC
(In reply to Philip Withnall from comment #11)
> True. Do you want to put together a patch?

I don't, but I've now filed this as bug 785577 so it doesn't get lost.