Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: 3.1.5: bad handling of 8 bit character
- X-seq: zsh-workers 4616
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: PATCH: 3.1.5: bad handling of 8 bit character
- Date: Thu, 12 Nov 1998 08:55:14 -0800
- In-reply-to: <9811121312.AA39762@xxxxxxxxxxxxxxxxx>
- References: <9811121312.AA39762@xxxxxxxxxxxxxxxxx>
On Nov 12, 2:12pm, Peter Stephenson wrote:
} Subject: PATCH: 3.1.5: bad handling of 8 bit character
}
} I suspect this was my fault last time I fiddled with input.c. It only
} shows up on machines where char is signed, so I didn't notice it. At
} least, this seems to do the trick for SUNOS, where I was seeing the
} problem.
}
} int
} ingetc(void)
} {
} ! int lastc;
}
} if (lexstop)
} return ' ';
I'm confused. I have this patch applied to 3.0.5:
PWS's patch from zsh-workers 4172 to eliminate the `lastc' global
and thereby clean up some goofy history management and a couple of
unexpected exits.
That means that my 3.0.5-extended has `char lastc;' in ingetc() as well.
Yet 3.0.5-extended still manages to get the 8-bit characters right, even
though 3.1.5 built on the same machine gets it wrong.
What *else* changed in 3.1.5 to make it sensitive to this?
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author