bugs in 3.0.6 (at least on Solaris 8)

[Mike Sullivan <Mike.Sullivan@xxxxxxxxxxx>]

Apologies if this isn't the right place to report bugs, but it's pointed
to by the faq, so hopefully it is :-) And this is not an attack on zsh either,
I just read like that sometimes.

A couple things I found with zsh 3.0.6 in Solaris 8. Most important is
that since the signal names are extracted with an awk script run on
<sys/signal.h>, zsh is broken because the signal macros are not there
anymore. They're in <sys/iso/signal_iso.h>. The arrays in signames.h
become mostly empty and zsh pretty much dies when a child is killed by
a signal. I've made my version look at the new header, but it seems
particularly bad that the build succeeds, but we blindly index outside
the array. It would be nice if the build failed if no signals were
found, or we checked against the array bounds. This seems fixed in
3.1.6, as configure finds iso/signal_iso.h, but I thought it might be
useful to know for when 8 ships (useful for 3.0.7, if needed).

We're also currently worrying if we should undo the macro movement, but
we don't really expect you to be parsing the headers, so I don't know if
that will be undone (we had to do it for other reasons, I think C++-related).

I also had to fix builtin.c to handle rlim_t as an 'unsigned long long'. It
was trying to print rlim_t's (when compiled for large files) as "%qd", which
doesn't work on solaris. I have that hackish fix, which uses RLIM_T_IS_LONG_LONG
along with RLIM_T_IS_UNSIGNED if you want it. This seems to work in 3.1.6,
but it also doesn't seem to expect rlim_t to be 'unsigned long long', just
'long long'.

And one more thing - the #define'ing of HAVE_NIS or HAVE_NIS_PLUS based on
what the machine you're compiling on is running. Is that wise? At least around
here, you may be trying to use the same binary from /usr/local on machines
running different name services, and that breaks if it's trying to do NIS
calls on a NIS+ machine. I turned those off, so we fall back to getpwent. 
Direct nameservice calls are indeed faster, but this seems more portable in
light of the variety of nameservices around, and the various ways you can
order them.

I'm done now.

	Mike

--
Mike Sullivan - Solaris Kernel Group - Mike.Sullivan@xxxxxxx
'And he smiled as he said, with a twinkle in his eye,
"Merry Christmas to all - now you're all gonna die!"'
    - The Night Santa Went Crazy