From: Eric Blake <eblake@redhat.com>
To: cygwin@cygwin.com, bug-bash <bug-bash@gnu.org>,
Steven Penny <svnpenn@gmail.com>
Subject: Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
Date: Mon, 15 May 2017 18:21:00 -0000 [thread overview]
Message-ID: <d76a140e-5c80-6990-b5df-661bd010e9da@redhat.com> (raw)
In-Reply-To: <58f1a28e.0a2c9d0a.f2ec.8160@mx.google.com>
[-- Attachment #1.1: Type: text/plain, Size: 5542 bytes --]
On 04/14/2017 11:33 PM, Steven Penny wrote:
> On Thu, 13 Apr 2017 13:48:04, Eric Blake wrote:
Sorry for my delay in noticing this.
>> Is it still a problem with pselect, where rebuilding with the same
>> configuration as 7.0.1-2 fixes things? I'm really not sure how to even
>> go about debugging this one, and it's not my highest priority at the
>> moment (I've got coreutils 8.27 to build for cygwin, and autoconf 2.70
>> to release upstream). So any help is welcome.
>
> Ok. I have not gone through the whole commit, as it is huge:
>
> http://cygwin.com/ml/cygwin/2017-01/msg00204.html
>
> but I did find something. Using:
>
> git checkout readline-7.0-alpha~1
>
> for the last good commit and:
>
> git checkout readline-7.0-alpha
>
> for the first bad commit, I found that the change to the "rl_insert"
> function in
> "text.c" breaks pasting and Alt codes with "chcp.com 65001". Can you
> work with
> this?
>
> http://git.savannah.gnu.org/cgit/readline.git/tree/text.c?h=readline-7.0-alpha#n891
It's code I'm not familiar with, so I'm adding upstream bug-bash in the
hopes that Chet might have an answer to why this code was changed, and
if he is aware that the change may have broken things on Cygwin.
>
>
> --- a/text.c
> +++ b/text.c
> @@ -71,6 +71,8 @@ static int _rl_char_search_callback
> PARAMS((_rl_callback_generic_arg *));
> rl_insert_text. Text blocks larger than this are divided. */
> #define TEXT_COUNT_MAX 1024
>
> +int _rl_optimize_typeahead = 1; /* rl_insert tries to read typeahead */
> +
> /* **************************************************************** */
> /* */
> /* Insert and Delete */
> @@ -890,8 +892,42 @@ int
> rl_insert (count, c)
> int count, c;
> {
> - return (rl_insert_mode == RL_IM_INSERT ? _rl_insert_char (count, c)
> - : _rl_overwrite_char (count, c));
> + int r, n, x;
> +
> + r = (rl_insert_mode == RL_IM_INSERT) ? _rl_insert_char (count, c) :
> _rl_overwrite_char (count, c);
> +
> + /* XXX -- attempt to batch-insert pending input that maps to
> self-insert */
> + x = 0;
> + n = (unsigned short)-2;
> + while (_rl_optimize_typeahead &&
> + (RL_ISSTATE (RL_STATE_INPUTPENDING|RL_STATE_MACROINPUT) == 0) &&
> + _rl_pushed_input_available () == 0 &&
> + _rl_input_queued (0) &&
> + (n = rl_read_key ()) > 0 &&
> + _rl_keymap[(unsigned char)n].type == ISFUNC &&
> + _rl_keymap[(unsigned char)n].function == rl_insert)
Looking at JUST this line, I am also reminded that Cygwin dll handling
is weird. For example, when building bash for Cygwin, I have to add the
following (currently-downstream-only, but maybe I should propose it
upstream) patch to bashline.c:
+#if __CYGWIN__
+# ifdef __x86_64__
+# define IMP(x) __imp_##x
+# else
+# define IMP(x) _imp__##x
+# endif
+#else
+# define IMP(x) x
+#endif
@@ -498,11 +513,12 @@ initialize_readline ()
kseq[0] = CTRL('J');
kseq[1] = '\0';
func = rl_function_of_keyseq (kseq, emacs_meta_keymap, (int *)NULL);
- if (func == rl_vi_editing_mode)
+ extern rl_command_func_t *IMP(rl_vi_editing_mode);
+ if (func == rl_vi_editing_mode || func == IMP(rl_vi_editing_mode))
rl_unbind_key_in_map (CTRL('J'), emacs_meta_keymap);
and similar. That is, anywhere that bash refers to an exported readline
function pointer, checking for equality on Cygwin works only if I check
both the original function name AND the __imp_rl_* function name, based
on how importing functions works with dlls (perhaps that's a gcc bug
that gcc doesn't automatically perform BOTH checks under the hood when
looking for C function pointer compatibility, but I'm not enough of a
compiler expert to know WHY it is needed, just that it solved issues
that didn't work otherwise). I wonder if the comparison against
rl_insert is incomplete, and needs to also check against __imp_rl_insert?
> + {
> + r = (rl_insert_mode == RL_IM_INSERT) ? _rl_insert_char (1, n) :
> _rl_overwrite_char (1, n);
> + /* _rl_insert_char keeps its own set of pending characters to
> compose a
> + complete multibyte character, and only returns 1 if it sees a
> character
> + that's part of a multibyte character but too short to complete
> one. We
> + can try to read another character in the hopes that we will get the
> + next one or just punt. Right now we try to read another character.
> + We don't want to call rl_insert_next if _rl_insert_char has already
> + stored the character in the pending_bytes array because that will
> + result in doubled input. */
> + n = (unsigned short)-2;
> + x++; /* count of bytes of typeahead read, currently unused */
> + if (r == 1) /* read partial multibyte character */
> + continue;
> + if (rl_done || r != 0)
> + break;
> + }
> +
> + if (n != (unsigned short)-2) /* -2 = sentinel value for having
> inserted N */
> + r = rl_execute_next (n);
> +
> + return r;
> }
>
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2017-05-15 18:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 19:53 [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3, libreadline-devel-7.0.3-3 Eric Blake (cygwin)
2017-03-25 0:46 ` Steven Penny
2017-04-13 19:07 ` [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3 Steven Penny
2017-04-14 8:27 ` Eric Blake
2017-04-15 10:59 ` Steven Penny
2017-05-15 18:21 ` Eric Blake [this message]
2017-05-15 20:46 ` Chet Ramey
2017-06-18 15:53 ` Steven Penny
2017-07-04 21:53 ` Steven Penny
2017-07-27 21:37 ` Eric Blake
2017-07-27 21:39 ` Eric Blake
2017-07-27 21:46 ` Steven Penny
2017-07-28 8:28 ` Eric Blake
2017-07-28 14:55 ` Steven Penny
2017-07-28 18:31 ` Eric Blake
2017-07-28 18:39 ` Steven Penny
2017-07-28 23:55 ` Eric Blake
2017-07-29 1:55 ` Cygwin.bat (was: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3) Achim Gratz
2017-07-29 2:48 ` [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3 Doug Henderson
2017-07-29 4:23 ` Steven Penny
2017-07-30 18:38 ` Doug Henderson
2017-07-30 19:54 ` Steven Penny
2017-07-29 8:45 ` Steven Penny
2017-07-29 10:08 ` Eric Blake
2017-07-31 18:36 ` Corinna Vinschen
2017-07-31 20:01 ` Steven Penny
2017-07-31 20:05 ` David Macek
2017-07-31 21:13 ` David Macek
[not found] ` <20170731200146.GD18950@calimero.vinschen.de>
[not found] ` <20170731211327.GG18950@calimero.vinschen.de>
2017-08-01 0:56 ` Steven Penny
2017-08-01 8:45 ` Corinna Vinschen
2017-08-01 14:48 ` Corinna Vinschen
2017-08-01 18:20 ` Steven Penny
2017-08-01 18:54 ` Achim Gratz
2017-08-01 19:02 ` Eric Blake
2017-08-01 7:22 ` David Macek
2017-08-01 8:46 ` Corinna Vinschen
[not found] ` <160b3569-d448-1898-3dcd-b7133a772527@SystematicSw.ab.ca>
2017-08-01 8:44 ` Corinna Vinschen
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=d76a140e-5c80-6990-b5df-661bd010e9da@redhat.com \
--to=eblake@redhat.com \
--cc=bug-bash@gnu.org \
--cc=cygwin@cygwin.com \
--cc=svnpenn@gmail.com \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).