Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: crash/memory corruption when completing dynamic named directory
- X-seq: zsh-workers 28940
- From: Mikael Magnusson <mikachu@xxxxxxxxx>
- To: zsh workers <zsh-workers@xxxxxxx>
- Subject: Re: crash/memory corruption when completing dynamic named directory
- Date: Sun, 27 Mar 2011 13:32:32 +0200
- 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:content-type:content-transfer-encoding; bh=VrUIs8KIvAQk6yDLS2kXh0jstKEBdu9+h77u+lNZjEY=; b=n0WM7jIlCZ3I90hBAxdGWChe6D26AkCrmhxkL6LR4WKU438tlvXF1ejm9p0qIljGaY hBEM0EjsPl8+alSp/NbtjvexVFEdd/lTYfZSHPBZJtc+5h3UWQ3wdAcHBldBFMPb54Ud kPLWe70EZEXXIpAuVOG2N7G29rsORG69aFC2U=
- 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 :content-type:content-transfer-encoding; b=RvVQEaGor1MqYbVqKSdNZCBkx21MdSlozUDPDxeYYIU7Ol8/g5UQYmpEQW3cuCPvco G04OKE6hFnbIl04hQhSg25uRNN8OLMgLW85fTGFx33N9+4HhnxqwfLsXHfSLsRVUXM2W PIXH4c8SDGbFfpSKTiQwddrho2gmW6BH8eVpQ=
- In-reply-to: <alpine.LNX.2.01.1103261818320.22141@hp>
- 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: <AANLkTi=qwPYqiwCGVw=vkN75JUFntDDrLgiO-CjYQQH9@mail.gmail.com> <AANLkTi=DsVZv5J2m26e86XgaD3qJtRtWMfDdWEoh3baD@mail.gmail.com> <alpine.LNX.2.01.1103261818320.22141@hp>
2011/3/26 Benjamin R. Haskell <zsh@xxxxxxxxxx>:
> On Sat, 26 Mar 2011, Johan Sundström wrote:
>
>> On Sat, Mar 26, 2011 at 05:54, Mikael Magnusson wrote:
>>
>>> I can't reproduce this in zsh -f yet, all that happens is that the
>>> completion just fails quietly without doing anything.
>>> % echo ネネネネネ ~[<tab>
>>> results in
>>> % echo <e3><ad><e3><ad><e3><ad><e3><ad><e3><ad> ~[
>>>
>>> any idea what could be wrong or what I can try to narrow it down?
>>
>>
>> Not an answer per se, but maybe bits of data giving someone else a lead: ネ
>> is Unicode code point 12493, or "\u30CD", which normalizes to itself in all
>> four Unicode normalization forms NFC, NFD, NFKC and NFKD, and which UTF-8
>> encodes to 0xE3, 0x83, 0x8D. I have no ideas about what the pretty-printing
>> or <ad>:s could be related to.
>>
>
> The problem is that the string of 'ne's is being unmetafy'ed when it
> shouldn't be. I don't know where. But that's what's happening.
>
> Not sure if there's programmatic access to the metafy and unmetafy functions
> from within zsh. I verified with the attached program. To compile it,
> first compile zsh. Then compile the test program via:
>
> $ gcc -o zsh-metafy zsh-metafy.c -lm -lcurses
> /path/to/zsh/compilation/*.o~*/main.o
> $ print -l ネネネネネ | ./zsh-metafy -u | myod
> 00000000 e3 ad e3 ad e3 ad e3 ad e3 ad 0a -- -- -- -- -- »..........¬«
>
> (myod is, as the name implies, just 'my' version of 'od')
Would you believe that accessing $CURSOR from within a completer will
actually unmetafy zlemetaline in place? :)
static zlong
get_cursor(UNUSED(Param pm))
{
if (zlemetaline != NULL) {
/* A lot of work for one number, but still... */
ZLE_STRING_T tmpline;
int tmpcs, tmpll, tmpsz;
tmpline = stringaszleline(zlemetaline, zlemetacs,
&tmpll, &tmpsz, &tmpcs);
free(tmpline);
return tmpcs;
}
return zlecs;
}
calling stringaszleline with zlemetaline only occurs in one other
place: unmetafy_line :).
pws, afaict, only the first little bit of zlemetaline is needed for
this, ie the outcs calculation. Would it be okay to split this out to
a separate function and call that from get_cursor and stringaszleline?
Otherwise we have to copy zlemetaline first and then run
stringaszleline, and discard all that work, which seems silly. Or does
outcs actually depend on the conversion too? There's a comment that
suggests it doesn't, but there are some assignments to it further
down.
--
Mikael Magnusson
Messages sorted by:
Reverse Date,
Date,
Thread,
Author