0.9.1 compilation failure on Nexenta 3.0.1
mdounin at mdounin.ru
Mon Dec 6 19:30:44 MSK 2010
On Mon, Dec 06, 2010 at 06:30:08PM +0300, Igor Sysoev wrote:
> On Mon, Dec 06, 2010 at 06:00:57PM +0300, Maxim Dounin wrote:
> > On Mon, Dec 06, 2010 at 05:36:13PM +0300, Igor Sysoev wrote:
> > > Yes, I've just checked OpenSolaris, it has no sys_nerr.
> > > I will detect maximum errno using EINVAL error from strerror().
> > What about just not using strerror() while in signal handler (and
> > using normal one in other cases)? I believe we've already seen
> > too many problems while trying to build async-signal-safe version
> > of strerror().
> > Maxim Dounin
> > p.s. If for some reason you'll still prefer to continue attempts
> > to build async-signal-safe strerror() - please note that POSIX
> > doesn't require strerror() to return EINVAL for invalid codes, it
> > only says "may".
> I believe it will be the last iteration.
I wish it will... Unfortunately, I'm almost sure it won't. POSIX
doesn't specify anything about error codes, and it's not really
safe to assume they are somehow ordered.
> Actually the current ngx_strerror_r() in 0.8.x is a set of hacks
> and workarounds, collected during nginx development.
> For example, Linux GNU strerror_r() is very different than POSIX one.
Yes, I understand. My general idea is to use POSIX interface if
available, and use hacks/workarounds only if they are known to be
needed. This way it will be as portable as possible.
The only real problem with POSIX strerror_r() is that it isn't
async-signal-safe. And I think it's fair enough to don't print
error message if an error happens in a signal handler.
More information about the nginx