From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-29183-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 22548 invoked by alias); 8 May 2011 00:05:13 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 29183
Received: (qmail 16557 invoked from network); 8 May 2011 00:05:11 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham
	version=3.3.1
Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 74.125.83.171 as permitted sender)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        bh=IyQ8m5RIiahsNdOYh6Cr+bJsVF9rz78BNgTTmXg/GfI=;
        b=Bo9g3tNXkz1gH9MqGbWkuE0M9HxVlMqFub5rsH1tfrbIMgMgCgZramvgESTV1vit4d
         ZlKHa7zg3yYENoMDQD9Y+wfbCPYLG/dNl4DqxH383tXbm5DruqVbOFFee3PXyGddZY8p
         mz2T101ln/JXWhy9lo3jCCvWjBa2dWsYcCda0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=nAe9Dx1zZKXlo9enQ212fF3VvhFjmZNMKcjyl+D4STo5YbIgZcbf6/n0sYHe1J87gO
         QKSC1LyAybp70WzUZ7eAwlL5RQAKXu2qcMnzfNVI20yyPBKXEcCJv+gSfaGg4lFuoDGr
         KPcURtO12tmBgMAOrD9tfAD6znQWe+9xvToIE=
MIME-Version: 1.0
In-Reply-To: <BANLkTikO3QSLA2h-6g9pz=gU_zi3iF6cQA@mail.gmail.com>
References: <BANLkTi=x2Cn3dZFGaEdVUm9+4mAse+dQsQ@mail.gmail.com>
	<BANLkTimCMEy1_EPe00dX7yhi-9EqDzKaMA@mail.gmail.com>
	<BANLkTimtXiG_RNbBxOXKwGMiXoNp_ui1HA@mail.gmail.com>
	<BANLkTikO3QSLA2h-6g9pz=gU_zi3iF6cQA@mail.gmail.com>
Date: Sat, 7 May 2011 17:05:08 -0700
Message-ID: <BANLkTik1h5bVd1cnPPYQrd33bEAc7pr2+Q@mail.gmail.com>
Subject: Re: SIGFPE crash
From: Jon Mayo <jon.mayo@gmail.com>
To: Mikael Magnusson <mikachu@gmail.com>
Cc: zsh workers <zsh-workers@zsh.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, May 7, 2011 at 3:27 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> On 8 May 2011 00:19, Jon Mayo <jon.mayo@gmail.com> wrote:
>> On Sat, May 7, 2011 at 3:17 PM, Mikael Magnusson <mikachu@gmail.com> wro=
te:
>>> On 7 May 2011 23:56, Jon Mayo <jon.mayo@gmail.com> wrote:
>>>> echo $[-9223372036854775808/-1]
>>>>
>>>> this causes zsh to exit immediately with an FPE. Does anyone have a
>>>> patch to fix this?
>>>
>>> diff --git a/Src/math.c b/Src/math.c
>>> index 35b362d..3c08052 100644
>>> --- a/Src/math.c
>>> +++ b/Src/math.c
>>> @@ -1053,8 +1053,12 @@ op(int what)
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0re=
turn;
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (c.type =3D=
=3D MN_FLOAT)
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0c.=
u.d =3D a.u.d / b.u.d;
>>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 else
>>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c.u.l =
=3D a.u.l / b.u.l;
>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 else {
>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
if (a.u.l =3D=3D LONG_MIN && b.u.l =3D=3D -1)
>>
>> should be LLONG_MIN
>>
>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0c.u.l =3D 0;
>>
>> LLONG_MAX would be the closest answer, but 1 off. I would switch it
>> from integer to double type in this case, but that might be difficult.
>
> It should probably be neither, zsh does some weird stuff to find a
> suitably long type for .l, which may or may not be a long long.
>
>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
else
>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 c.u.l =3D a.u.l / b.u.l;
>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break;
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case MOD:
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case MODEQ:
>>>
>>>
>>> Do we want to print a warning and/or use another value than 0 in this c=
ase?
>
> This is assuming we want to do this at all, I am told that only
> division will generate an exception on x86, but presumably other
> arches behave differently, and bash behaves the same way too
> (exception + die). Does some sort of standard have anything to say on
> the matter? I'm guessing someone has thought of it before and clearly
> nobody ever did anything about it.
>

perhaps scripts that care can just use a trap? and all my worrying was
for nothing?
mostly I ran into the issue while I dropped out of vi to do some
calculations, and ended up having zsh crash and had to recover my
editing session. minor annoyance really.