From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1245 invoked from network); 27 Feb 2008 11:32:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 27 Feb 2008 11:32:21 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 37897 invoked from network); 27 Feb 2008 11:32:16 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 27 Feb 2008 11:32:16 -0000 Received: (qmail 28840 invoked by alias); 27 Feb 2008 11:32:12 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24609 Received: (qmail 28826 invoked from network); 27 Feb 2008 11:32:11 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 27 Feb 2008 11:32:11 -0000 Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [85.115.41.190]) by bifrost.dotsrc.org (Postfix) with ESMTP id 5683D8026E0B for ; Wed, 27 Feb 2008 12:32:01 +0100 (CET) Received: from rly17g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly17g.srv.mailcontrol.com (MailControl) with ESMTP id m1RBVkUr013060 for ; Wed, 27 Feb 2008 11:31:56 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly17g.srv.mailcontrol.com (MailControl) id m1RBUwAp011158 for zsh-workers@sunsite.dk; Wed, 27 Feb 2008 11:30:58 GMT Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly17g-eth0.srv.mailcontrol.com (envelope-sender Peter.Stephenson@csr.com) (MIMEDefang) with ESMTP id m1RBP4Qs018565; Wed, 27 Feb 2008 11:30:57 +0000 (GMT) Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Feb 2008 11:29:32 +0000 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id m1RBTV1Y003642; Wed, 27 Feb 2008 11:29:32 GMT Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id m1RBTVIC003639; Wed, 27 Feb 2008 11:29:31 GMT Message-Id: <200802271129.m1RBTVIC003639@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: Dagobert Michelsen , zsh-workers@sunsite.dk Subject: Re: * Re: Failed tests of zsh 4.3.5 in Solaris 10 w/Sun Studio 12 CC In-reply-to: <18951.1204047420@thecus> References: <8AABEECB-A9A6-43EA-BED2-4BE376CBE349@blastwave.org> <20080226141459.76dc362c@news01> <20080226145741.6e74fc22@news01> <656429B3-438B-4ECF-85C4-04E38D837D1A@blastwave.org> <200802261610.m1QGAwJ3008939@news01.csr.com> <18951.1204047420@thecus> Comments: In-reply-to Oliver Kiddle message dated "Tue, 26 Feb 2008 18:37:00 +0100." Date: Wed, 27 Feb 2008 11:29:30 +0000 From: Peter Stephenson X-OriginalArrivalTime: 27 Feb 2008 11:29:32.0356 (UTC) FILETIME=[05DB0840:01C87934] X-Scanned-By: MailControl A-08-00-04 (www.mailcontrol.com) on 10.71.1.127 X-Virus-Scanned: ClamAV 0.91.2/6008/Wed Feb 27 10:53:17 2008 on bifrost X-Virus-Status: Clean Oliver Kiddle wrote: > Peter wrote: > > > Is this an error from zsh or is this a bug in libiconv? > > It's actually better to avoid using libiconv and stick to the builtin > iconv on Solaris. It handles 646 correctly. I always make a point of > making sure it doesn't find GNU libiconv when compiling. I've tried to take account of that below... > > + if (!codessetstr || !*codsetstr || > > + !strcmp(codesetstr, "646")) > > + codesetstr == "US-ASCII"; > > Is the last line of this correct? Isn't it meant to be an assignment? Yes, that was fixed by Dagobert. > I would be inclined to wrap the whole thing inside #ifdef > _libiconv_version because the problem only occurs when using GNU iconv > instead of the Solaris builtin one. And there's the reciprocal problem: some native Solaris iconv's (such as the one I just tried in Solaris 8) don't support US-ASCII and other obvious forms, they only support 646 etc, so we definitely need more work. The following is the best I've got: it tests for _libiconv_version (which should be an external variable and hence tell us whether we're actually linking against libiconv, whatever the header is) in configure and if that's set compiles in some fairly defensive code. I tried this under Cygwin which uses libiconv. Note this doesn't trigger if iconv is part of glibc, as under (most?) Linux distributions. Index: MACHINES =================================================================== RCS file: /cvsroot/zsh/zsh/MACHINES,v retrieving revision 1.5 diff -u -r1.5 MACHINES --- MACHINES 21 May 2007 09:52:30 -0000 1.5 +++ MACHINES 27 Feb 2008 10:20:16 -0000 @@ -212,7 +212,11 @@ This may work, but the first username completion will be _very_ slow (as slow as in tcsh). -Sun: Solaris 2.x, 8, 9 +Sun: Solaris 2.x, 8, 9, ... + It is recommended that the system library version of iconv() + be used rather than libiconv since there are incompatibilities + in the way codesets are named. + The UCB versions of the routines for reading directories are not usable (the struct definitions are incompatible with the ones assumed by zsh). The symptom of this is that globbed filenames in Index: configure.ac =================================================================== RCS file: /cvsroot/zsh/zsh/configure.ac,v retrieving revision 1.92 diff -u -r1.92 configure.ac --- configure.ac 3 Feb 2008 18:17:13 -0000 1.92 +++ configure.ac 27 Feb 2008 10:20:17 -0000 @@ -824,8 +824,13 @@ [ #include ]) fi fi +AH_TEMPLATE([ICONV_FROM_LIBICONV], +[Define to 1 if iconv() is linked from libiconv]) if test "x$ac_found_iconv" = xyes; then AC_DEFINE(HAVE_ICONV, 1, [Define if you have the iconv() function.]) + AC_TRY_LINK([#include ], + [int myversion = _libiconv_version], + AC_DEFINE(ICONV_FROM_LIBICONV), ) fi dnl Check if iconv uses const in prototype declaration Index: Src/utils.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/utils.c,v retrieving revision 1.181 diff -u -r1.181 utils.c --- Src/utils.c 26 Feb 2008 20:50:12 -0000 1.181 +++ Src/utils.c 27 Feb 2008 10:20:20 -0000 @@ -4880,15 +4880,32 @@ * If the code set isn't handled, we'd better * assume it's US-ASCII rather than just failing * hopelessly. Solaris has a weird habit of - * returning 646. + * returning 646. This is handled by the + * native iconv(), but not by GNU iconv; what's + * more, some versions of the native iconv don't + * handle standard names like ASCII. + * + * This should only be a problem if there's a + * mismatch between the NLS and the iconv in use, + * which probably only means if libiconv is in use. + * We checked at configure time if our libraries + * pulled in _libiconv_version, which should be + * a good test. * * It shouldn't ever be NULL, but while we're * being paranoid... */ - if (!codesetstr || !*codesetstr || - !strcmp(codesetstr, "646")) +#ifdef ICONV_FROM_LIBICONV + if (!codesetstr || !*codesetstr) codesetstr = "US-ASCII"; +#endif cd = iconv_open(codesetstr, "UCS-4BE"); +#ifdef ICONV_FROM_LIBICONV + if (cd == (iconv_t)-1 && !strcmp(codesetstr, "646")) { + codesetstr = "US-ASCII"; + cd = iconv_open(codesetstr, "UCS-4BE"); + } +#endif if (cd == (iconv_t)-1) { zerr("cannot do charset conversion (iconv failed)"); CHARSET_FAILED(); -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070