From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42739 invoked by alias); 15 May 2017 18:19:44 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 42157 invoked by uid 89); 15 May 2017 18:19:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Penny, penny, 65001, 201701 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 May 2017 18:19:41 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 10937770F; Mon, 15 May 2017 18:19:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 10937770F Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=eblake@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 10937770F Received: from [10.10.123.244] (ovpn-123-244.rdu2.redhat.com [10.10.123.244]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4156887E3C; Mon, 15 May 2017 18:19:37 +0000 (UTC) Subject: Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3 To: cygwin@cygwin.com, bug-bash , Steven Penny References: <58f1a28e.0a2c9d0a.f2ec.8160@mx.google.com> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Message-ID: Date: Mon, 15 May 2017 18:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <58f1a28e.0a2c9d0a.f2ec.8160@mx.google.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cD8uem0xADnieH07NNfWC79D7c1O9AUpA" X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00237.txt.bz2 --cD8uem0xADnieH07NNfWC79D7c1O9AUpA Content-Type: multipart/mixed; boundary="Oj0Iv3IUSnpJJvJL8dLVk4toubG5bQWKc"; protected-headers="v1" From: Eric Blake To: cygwin@cygwin.com, bug-bash , Steven Penny Message-ID: Subject: Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3 References: <58f1a28e.0a2c9d0a.f2ec.8160@mx.google.com> In-Reply-To: <58f1a28e.0a2c9d0a.f2ec.8160@mx.google.com> --Oj0Iv3IUSnpJJvJL8dLVk4toubG5bQWKc Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 5512 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. >=20 > Ok. I have not gone through the whole commit, as it is huge: >=20 > http://cygwin.com/ml/cygwin/2017-01/msg00204.html >=20 > but I did find something. Using: >=20 > git checkout readline-7.0-alpha~1 >=20 > for the last good commit and: >=20 > git checkout readline-7.0-alpha >=20 > 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? >=20 > http://git.savannah.gnu.org/cgit/readline.git/tree/text.c?h=3Dreadline-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. >=20 >=20 > --- 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 >=20 > +int _rl_optimize_typeahead =3D 1; /* rl_insert tries to read typeahea= d */ > + > /* **************************************************************** */ > /* */ > /* Insert and Delete */ > @@ -890,8 +892,42 @@ int > rl_insert (count, c) > int count, c; > { > - return (rl_insert_mode =3D=3D RL_IM_INSERT ? _rl_insert_char (count, c) > - : _rl_overwrite_char (count, c)); > + int r, n, x; > + > + r =3D (rl_insert_mode =3D=3D 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 =3D 0; > + n =3D (unsigned short)-2; > + while (_rl_optimize_typeahead && > + (RL_ISSTATE (RL_STATE_INPUTPENDING|RL_STATE_MACROINPUT) =3D=3D 0) && > + _rl_pushed_input_available () =3D=3D 0 && > + _rl_input_queued (0) && > + (n =3D rl_read_key ()) > 0 && > + _rl_keymap[(unsigned char)n].type =3D=3D ISFUNC && > + _rl_keymap[(unsigned char)n].function =3D=3D 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] =3D CTRL('J'); kseq[1] =3D '\0'; func =3D rl_function_of_keyseq (kseq, emacs_meta_keymap, (int *)NULL); - if (func =3D=3D rl_vi_editing_mode) + extern rl_command_func_t *IMP(rl_vi_editing_mode); + if (func =3D=3D rl_vi_editing_mode || func =3D=3D 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 =3D (rl_insert_mode =3D=3D 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 =3D (unsigned short)-2; > + x++; /* count of bytes of typeahead read, currently unused = */ > + if (r =3D=3D 1) /* read partial multibyte character */ > + continue; > + if (rl_done || r !=3D 0) > + break; > + } > + > + if (n !=3D (unsigned short)-2) /* -2 =3D sentinel value for hav= ing > inserted N */ > + r =3D rl_execute_next (n); > + > + return r; > } >=20 >=20 > --=20 > 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 >=20 >=20 --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org --Oj0Iv3IUSnpJJvJL8dLVk4toubG5bQWKc-- --cD8uem0xADnieH07NNfWC79D7c1O9AUpA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 604 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJZGfE4AAoJEKeha0olJ0Nq000H/ArU2yqJyKc4AylaWTWX8i/t bU1niI6DEH4yGY5N6KOmwOSvKeHHn1yXM7gl3cjfGdNu/0xWD3iBYlLIlRC+qBvH 6kUEdT1FFenIMHC/PZXpgL+OdqoLkQPpNV2g9Tu4CKvIJU2AI1mmpJJSJ1/k1px4 45NpPvZjITEXyW09sr5PRAZvah0UQqpru05IctxFBcA3C2umel74kt9ty48A0dz8 AiwLhwOKOS6+mNuccAhU5+Vu7iHhVfOaVRC7K3Q7ipo8RLpqkLgVKNkT38ddkpuH ntx3wWpg5yoFyqPWW1j6tLYbcVhc7vyYNYkWtYXmCq+cjCdD0H1SPJNQ9y+em3g= =Hj5n -----END PGP SIGNATURE----- --cD8uem0xADnieH07NNfWC79D7c1O9AUpA--