fix issue in 'h2o_perror' about 'strerror_r' #2022
Conversation
|
@kazuho Would you please review this PR? |
|
Oh nice catch! It's unfortunate that glibc behaves differently than what is defined in POSIX. How about moving I think that this is not a hot path, and I prefer having one code that gets executed on all platforms. |
|
@kazuho Fixed, Moved to no inline functions. Guess Also |
| (*list)[cnt++] = element; | ||
| (*list)[cnt] = NULL; | ||
| } | ||
|
|
There was a problem hiding this comment.
Thank you for the changes. To clarify, my suggestion is to do
#define _POSIX_C_SOURCE 200112L
#undef _GNU_SOURCE
here, so that the POSIX variant would be used below.
We can retain h2o_strerror_r returning void as-is.
There was a problem hiding this comment.
So the choice is using POSIX version instead of gnu version.
Should this be defined at the beginning of file before any #include (or at lease before #include <string.h>)?
If #define _POSIX_C_SOURCE 200112L and #undef _GNU_SOURCE
at the top of the file, there are some compiler warnings for getpagesize, alloca and mkstemp.
Seems not a very good solution.
There was a problem hiding this comment.
@chenbd I think you are correct. Using macros is not a good way to resolve the issue.
So it would either be calling __xpg_strerror_r (it's part of the linux ABI, see http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/baselib-xpg-strerror_r-3.html), or creating a wrapper for strerror_r.
I think that your approach of creating a wrapper is better, and I think the wrapper API we should provide is the one that returns char *; it's theoretically faster and it's easier to mimic. WDYT?
There was a problem hiding this comment.
yes, I prefer char *h2o_strerror_r(int errnum, char *buf, size_t buflen);
lib/common/memory.c
Outdated
There was a problem hiding this comment.
Thank you for the changes. I believe you need to use the result of the function call here?
There was a problem hiding this comment.
Yes, sorry for my miss.
Fixed in 82b0800
There was a problem hiding this comment.
IMO, Recently most systems implements strerror using thread local data.
so indeed, strerror and strerror_r should be both thread safe on these systems. but man page do not assure this.
all these strerror_r related seems historical reasons.
|
Thank you for all the work! |
The GNU-specific strerror_r() returns a pointer to a string containing the error message. This may be either a pointer to a string that the function stores in buf, or a pointer to some(immutable) static string (in which case buf is unused).
h2o_perrorshould handle this case.