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