From: Wayne Davison <wayned@users.sourceforge.net>
To: Peter Stephenson <pws@csr.com>
Cc: Zsh hackers list <zsh-workers@sunsite.dk>
Subject: Re: unpatch: rationalise multibyte output
Date: Fri, 28 Oct 2005 15:09:27 -0700 [thread overview]
Message-ID: <20051028220927.GB27510@blorf.net> (raw)
In-Reply-To: <200510281729.j9SHTSGm025792@news01.csr.com>
On Fri, Oct 28, 2005 at 06:29:28PM +0100, Peter Stephenson wrote:
> I was too lazy to patch this into my non-multibyte build, but when I
> commit this and can get CVS to do it for me I'll do that and fix up
> any fallout.
I also compiled a non-multibyte build, and I finally got around to
looking into some of the compiler warnings that crop up. Here's one
that's been around for a while, which seems to be an easy fix:
--- Src/Zle/zle_refresh.c 28 Oct 2005 17:34:33 -0000 1.36
+++ Src/Zle/zle_refresh.c 28 Oct 2005 21:57:49 -0000
@@ -1138,8 +1138,10 @@ refreshline(int ln)
/* inserting & deleting chars: we can if there's no right-prompt */
if ((ln || !put_rpmpt || !oput_rpmpt)
- && (nl[1] && ol[1] && nl[1] != ol[1])
- && *ol != WEOF && *nl != WEOF) {
+#ifdef MULTIBYTE_SUPPORT
+ && *ol != WEOF && *nl != WEOF
+#endif
+ && nl[1] && ol[1] && nl[1] != ol[1]) {
/* deleting characters - see if we can find a match series that
makes it cheaper to delete intermediate characters
Those WEOF comparisons were being done w/o MULTIBYTE_SUPPORT being
defined, which I assume is never needed (if it were, REFRESH_STRING
would need to be something larger than an unsigned char, and WEOF
would need to be ZLEEOF).
Another signed/unsigned error concerns the return value of the
WC_REDIR_TYPE() macro (which is unsigned) and the redir_type variables
which are used in the code, which are "int"s. One simple fix is to just
make the WC_REDIR_* macros return an int, which is what this patch does:
--- Src/zsh.h 28 Oct 2005 17:34:33 -0000 1.80
+++ Src/zsh.h 28 Oct 2005 22:04:25 -0000
@@ -656,8 +656,8 @@ struct eccstr {
#define WC_PIPE_LINENO(C) (wc_data(C) >> 1)
#define WCB_PIPE(T,L) wc_bld(WC_PIPE, ((T) | ((L) << 1)))
-#define WC_REDIR_TYPE(C) (wc_data(C) & REDIR_TYPE_MASK)
-#define WC_REDIR_VARID(C) (wc_data(C) & REDIR_VARID_MASK)
+#define WC_REDIR_TYPE(C) ((int)(wc_data(C) & REDIR_TYPE_MASK))
+#define WC_REDIR_VARID(C) ((int)(wc_data(C) & REDIR_VARID_MASK))
#define WCB_REDIR(T) wc_bld(WC_REDIR, (T))
/* Size of redir is 4 words if REDIR_VARID_MASK is set, else 3 */
#define WC_REDIR_WORDS(C) (WC_REDIR_VARID(C) ? 4 : 3)
That looked better than changing various ints into unsigned ints.
I have another set of potential changes, but those I'll reserve for
another message.
If anyone has any concerns/comments about the above changes, let me
know.
..wayne..
prev parent reply other threads:[~2005-10-28 22:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-28 17:29 Peter Stephenson
2005-10-28 22:09 ` Wayne Davison [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051028220927.GB27510@blorf.net \
--to=wayned@users.sourceforge.net \
--cc=pws@csr.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).