From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@math.gatech.edu>
Received: (qmail 2378 invoked from network); 18 May 1998 06:59:41 -0000
Received: from math.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 18 May 1998 06:59:41 -0000
Received: (from list@localhost)
	by math.gatech.edu (8.8.5/8.8.5) id CAA16459;
	Mon, 18 May 1998 02:53:12 -0400 (EDT)
Resent-Date: Mon, 18 May 1998 02:53:12 -0400 (EDT)
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
Message-Id: <199805180653.BAA15526@hzoli.home>
Subject: Re: Another zsh 3.1 bug -- localization?
In-Reply-To: <m2yaw3x555.fsf@altair.xemacs.org> from SL Baur at "May 15, 98 02:19:50 am"
To: steve@xemacs.org (SL Baur)
Date: Mon, 18 May 1998 01:53:33 -0500 (CDT)
Cc: zsh-workers@math.gatech.edu
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"hL-sl.0.614.NhzNr"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3983
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

SL Baur wrote:
> I've tested this now on zsh 3.1.2 and zsh 3.1.3 Linux libc5 and GNU
> libc.  It does not occur in zsh 3.0.4 or zsh 3.0.5.  It reproduces
> reliably for me in a new zsh-3.1.3 (without the `unset CDPATH'
> bugfix).  The machine I'm running on is localizable to the extent that
> `LANG=ja' is able to programs that need Japanese input and display
> Japanese output.
> 
> $ Src/zsh
> $ LC_ALL=C; export LC_ALL; LANC=C; export LANG; date
> zsh: 30841 segmentation fault (core dumped)  Src/zsh

A simple export LANG is enough for the coredump.  Any unset special
parameter will do, but LANG is unset by default.  The patch below fixes
this, but it introduces a slightly inconsistent behavior.  export LANG
will not set LANG, but if it is set later, it will be exported.  This is
similar to ksh, but inconsistent with zsh, which creates the parameter
with empty value when export used on a previously unset parameter.

An alternative fix would change the big if statement near line 1557,
which is now

if ((pm = (Param)paramtab->getnode(paramtab, asg->name)) &&
    (((pm->flags & PM_SPECIAL) && pm->level == locallevel) ||
     (!(pm->flags & PM_UNSET) &&
      ((locallevel == pm->level) || func == BIN_EXPORT) &&
      !(bit = ((off & pm->flags) | (on & ~pm->flags)) & PM_INTEGER))))

If the condition is changed to always be false when pm->flags & PM_UNSET
and createparam is changed to reset the unset flag and return the
parameter, it would probably work, and that's how it works in 3.0.5.
This has been changed since 3.0.5 by patch 3048 from Zefram which allowd
local parameters to hide special parameters.  I do not completely
understand this, but someone hopefully knows better.

Note that in the patch below addenv is not called when asg->value is
non-null (i.e. when a value is given in the typeset/export statement),
because in this case the later setsparm call does the addenv.

Zoltan


*** Src/builtin.c.orig	Fri May  8 01:24:52 1998
--- Src/builtin.c	Mon May 18 01:37:59 1998
*************** bin_typeset(char *name, char **argv, cha
*** 1585,1592 ****
  		pm->ct = auxlen;
  	    if (PM_TYPE(pm->flags) != PM_ARRAY) {
  		if (pm->flags & PM_EXPORTED) {
! 		    if (!pm->env)
! 			pm->env = addenv(asg->name, (asg->value) ? asg->value : getsparam(asg->name));
  		} else if (pm->env) {
  		    delenv(pm->env);
  		    zsfree(pm->env);
--- 1585,1592 ----
  		pm->ct = auxlen;
  	    if (PM_TYPE(pm->flags) != PM_ARRAY) {
  		if (pm->flags & PM_EXPORTED) {
! 		    if (!(pm->flags & PM_UNSET) && !pm->env && !asg->value)
! 			pm->env = addenv(asg->name, getsparam(asg->name));
  		} else if (pm->env) {
  		    delenv(pm->env);
  		    zsfree(pm->env);