Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: SIGFPE crash
- X-seq: zsh-workers 29183
- From: Jon Mayo <jon.mayo@xxxxxxxxx>
- To: Mikael Magnusson <mikachu@xxxxxxxxx>
- Subject: Re: SIGFPE crash
- Date: Sat, 7 May 2011 17:05:08 -0700
- Cc: zsh workers <zsh-workers@xxxxxxx>
- 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=
- In-reply-to: <BANLkTikO3QSLA2h-6g9pz=gU_zi3iF6cQA@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- 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>
On Sat, May 7, 2011 at 3:27 PM, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
> On 8 May 2011 00:19, Jon Mayo <jon.mayo@xxxxxxxxx> wrote:
>> On Sat, May 7, 2011 at 3:17 PM, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>>> On 7 May 2011 23:56, Jon Mayo <jon.mayo@xxxxxxxxx> 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)
>>> return;
>>> if (c.type == MN_FLOAT)
>>> c.u.d = a.u.d / b.u.d;
>>> - else
>>> - c.u.l = a.u.l / b.u.l;
>>> + else {
>>> + if (a.u.l == LONG_MIN && b.u.l == -1)
>>
>> should be LLONG_MIN
>>
>>> + c.u.l = 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.
>
>>> + else
>>> + c.u.l = a.u.l / b.u.l;
>>> + }
>>> break;
>>> case MOD:
>>> case MODEQ:
>>>
>>>
>>> Do we want to print a warning and/or use another value than 0 in this case?
>
> 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.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author