0.9.1 compilation failure on Nexenta 3.0.1

[Maxim Dounin]

Hello!

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.

Maxim Dounin