From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28636 invoked from network); 27 Oct 1999 20:08:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 27 Oct 1999 20:08:53 -0000 Received: (qmail 19806 invoked by alias); 27 Oct 1999 20:08:49 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8458 Received: (qmail 19799 invoked from network); 27 Oct 1999 20:08:48 -0000 Date: Wed, 27 Oct 1999 13:08:14 -0700 (PDT) From: Mike Sullivan Message-Id: <199910272008.NAA527581@yavin.Eng.Sun.COM> To: zsh-workers@sunsite.auc.dk Subject: bugs in 3.0.6 (at least on Solaris 8) X-Sun-Charset: US-ASCII 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 , zsh is broken because the signal macros are not there anymore. They're in . 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@Sun.COM '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