Chuck, On 5/31/13 4:42 PM, Caldarale, Charles R wrote: >> From: Rainer Jung [mailto:rainer.j...@kippdata.de] >> Subject: Re: APR/native errors with non-blocking I/O > >> Compile and have fun. > > Or we could talk about Mark's familiarity with C :-) > >> IMHO we don't have that in the code to output text instead of cryptic >> numbers because it isn't really available on all needed platforms. I >> could be wrong though. > > The strerror() API is part of the POSIX and C standards, so it should > be there unless you're running on some cut-down embedded platform. > However, it is not thread-safe, so it might not be appropriate to > include it in JNI code.
I'm pretty sure that sterror is thread safe: it should just return a static char*. The GNU man page for strerror() says that strerror_r is just like strerror(), "but is thread safe". It doesn't specifically say that strerror() is *not* thread-safe, but does imply it. On my Mac, there is no mention of thread safety at all on that man page (except this: "For unknown error numbers, the strerror() function will return its result in a static buffer which may be overwritten by subsequent calls." Hopefully, that means static and private to the thread, but I don't know.) Back to the GNU man page, it says: "strerror() is specified by POSIX.1-2001, C89, C99. strerror_r() is specified by POSIX.1-2001.", so we may be able to rely upon it. -chris
signature.asc
Description: OpenPGP digital signature
