screen on 64-bit mangles mintty/buffer

screen on 64-bit mangles mintty/buffer

[Shaddy Baddah]

Hi,

This is a problem that I noticed some time last year, so I apologise for
sitting on it for so long. I actually started drafting a number of
emails to report but never committed.

The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears
to work correctly. The problem is that when screen is run in mintty, it
seems to exclude the bottom line, reducing the actual size of the
buffer. Further, something goes awry at the top. So that if you run
emacs -nw or less from within, scrolling via the keys acts very
strangely.

If you detach or simply exit the screen session, the problem carries on
on the mintty you are left with.

You can resolve this by resizing the window (and back). Everything then
returns to normal.

It is interesting to me that the problem also occurs if I ssh into the
64-bit Cygwin install via Putty. However, the problem only occurs from
within the screen session. When you detach or exit, the original Putty
session/buffer is uncorrupted.

My foolishness in not reporting this as soon as I detected it is that
my attempts to bisect/rollback to a period where my recollection
suggests the problem did not exist, have not succeeded. In other words,
my tests indicate this has been around since screen was built and
released for 64-bit Cygwin.

I was hoping to understand the terminal handling and suggest a fix, but
it is a little bit beyond my capability at the moment. Any help would
be appreciated (I usually quarantine one mintty which I use for managing
a handful of screen sessions to work around the problem).

-- 
Regards,
Shaddy

--
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

Re: screen on 64-bit mangles mintty/buffer

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On May 13 00:57, Shaddy Baddah wrote:
> Hi,
> 
> This is a problem that I noticed some time last year, so I apologise for
> sitting on it for so long. I actually started drafting a number of
> emails to report but never committed.
> 
> The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears
> to work correctly. The problem is that when screen is run in mintty, it
> seems to exclude the bottom line, reducing the actual size of the
> buffer. Further, something goes awry at the top. So that if you run
> emacs -nw or less from within, scrolling via the keys acts very
> strangely.
> 
> If you detach or simply exit the screen session, the problem carries on
> on the mintty you are left with.

This sounds like a mintty issue, not a Cygwin DLL issue.  The Cygwin DLL
only provides the pseudo tty communication channel.  The interpretation
of the escape sequences is done in the terminal emulator.

Unfortunately I have not read anything from the mintty maintainer, Andy
Koppe, since mid-2013, neither here nor on the mintty mailing list.
There was also no upstream mintty release since April 2013.  I have
tried to contact Andy a couple of days ago but didn't get a reply yet.
I hope he's well.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: screen on 64-bit mangles mintty/buffer

[Andrew Schulman]

Hi Shaddy.

> Hi,
> 
> This is a problem that I noticed some time last year, so I apologise for
> sitting on it for so long. I actually started drafting a number of
> emails to report but never committed.
> 
> The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears
> to work correctly. The problem is that when screen is run in mintty, it
> seems to exclude the bottom line, reducing the actual size of the
> buffer. Further, something goes awry at the top. So that if you run
> emacs -nw or less from within, scrolling via the keys acts very
> strangely.
> 
> If you detach or simply exit the screen session, the problem carries on
> on the mintty you are left with.
> 
> You can resolve this by resizing the window (and back). Everything then
> returns to normal.
> 
> It is interesting to me that the problem also occurs if I ssh into the
> 64-bit Cygwin install via Putty. However, the problem only occurs from
> within the screen session. When you detach or exit, the original Putty
> session/buffer is uncorrupted.

OK.  This sounds like the same problem as:  

http://cygwin.com/ml/cygwin/2014-01/msg00223.html

Actually that report is sort of the opposite problem:  all of the
scrolling is down in the bottom line.  But it sure sounds like the same
thing.

The details of what people report vary.  For me, scrolling ends up all
down in the bottom line, and resizing the window doesn't fix it.

I also see the problem only in 64-bit.  It works fine in 32-bit.

I have found one reliable workaround, at least for me:  The problem only
happens if I start screen from my .bash_profile.  If I start it from the
command line, it works fine.  I don't know yet why that is, but it's a
clue.  Probably an environment difference.

Are you using the latest screen release, 4.2.1?  Please send output of
cygcheck -svr.

> My foolishness in not reporting this as soon as I detected it is that
> my attempts to bisect/rollback to a period where my recollection
> suggests the problem did not exist, have not succeeded. In other words,
> my tests indicate this has been around since screen was built and
> released for 64-bit Cygwin.
> 
> I was hoping to understand the terminal handling and suggest a fix, but
> it is a little bit beyond my capability at the moment. Any help would
> be appreciated (I usually quarantine one mintty which I use for managing
> a handful of screen sessions to work around the problem).

No problem, thanks for reporting.  Corinna suggests that it's a mintty
problem.  Is that more likely than a screen problem?  I don't know.  If
it is a screen problem, I don't have the skills to offer a fix - all I
can do is report it to the screen-users list.

Andrew


--
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

Re: screen on 64-bit mangles mintty/buffer

[Shaddy Baddah]

H,

On 2014-05-15 02:46+0100, Andrew Schulman wrote:
<snip/>

>> The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears
>> to work correctly. The problem is that when screen is run in mintty, it
>> seems to exclude the bottom line, reducing the actual size of the
>> buffer. Further, something goes awry at the top. So that if you run
>> emacs -nw or less from within, scrolling via the keys acts very
>> strangely.
>>
>> If you detach or simply exit the screen session, the problem carries on
>> on the mintty you are left with.
>>
<snip/>
> OK.  This sounds like the same problem as:
>
> http://cygwin.com/ml/cygwin/2014-01/msg00223.html
>
> Actually that report is sort of the opposite problem:  all of the
> scrolling is down in the bottom line.  But it sure sounds like the same
> thing.
>
> The details of what people report vary.  For me, scrolling ends up all
> down in the bottom line, and resizing the window doesn't fix it.
>
> I also see the problem only in 64-bit.  It works fine in 32-bit.
>
> I have found one reliable workaround, at least for me:  The problem only
> happens if I start screen from my .bash_profile.  If I start it from the
> command line, it works fine.  I don't know yet why that is, but it's a
> clue.  Probably an environment difference.
>
> Are you using the latest screen release, 4.2.1?  Please send output of
> cygcheck -svr.
>
>> My foolishness in not reporting this as soon as I detected it is that
>> my attempts to bisect/rollback to a period where my recollection
>> suggests the problem did not exist, have not succeeded. In other words,
>> my tests indicate this has been around since screen was built and
>> released for 64-bit Cygwin.
>>
>> I was hoping to understand the terminal handling and suggest a fix, but
>> it is a little bit beyond my capability at the moment. Any help would
>> be appreciated (I usually quarantine one mintty which I use for managing
>> a handful of screen sessions to work around the problem).
>
> No problem, thanks for reporting.  Corinna suggests that it's a mintty
> problem.  Is that more likely than a screen problem?  I don't know.  If
> it is a screen problem, I don't have the skills to offer a fix - all I
> can do is report it to the screen-users list.

OK, after much debugging, I have got somewhere. Although my
understanding is not 100% complete at this point, but I need to stop for
a bit.

There seems to me to be a number of small problems that have chained
themselves into a larger complex problem.

Comparing the control sequence output of the 64-bit against the 32-bit
build of screen, I quickly noticed that the problem was that 64-bit
screen was incorrectly parameterizing the output for the CS (clear
screen) capability (on a 40 line sized mintty):

64-bit: "\e[0;39r"
32-bit: "\e[1;40r"

This means that the screen session itself if incorrectly ignoring the
last visible line (equivalent of a viewport shifted up a line), on both
putty and mintty.

Unfortunately, the incorrect parameters reek havoc on mintty, but not on
putty. Once the original buffer is returned (as opposed to screens
alternate buffer), putty is ok. mintty could handle this better, but it
is not the root cause of the issue.

Seeing that on 64-bit, the control sequence was being generated by tgoto
(/tparm) as per:

screen-4.2.1/display.c:2869:  debug2("ChangeScrollRegion: (%d - %d)\n", 
newtop, newbot);
screen-4.2.1/display.c:2870:  AddCStr(tgoto(D_CS, newbot, newtop));

I found the termcap/info def for cs to be "\e[%i%d;%dr". The %i
indicates that both parameters (%d) should be incremented by 1.

This was not occurring. So I went about debugging libncursesw10 to
understand why. I worked out that tgoto() was calling tparam(). And
tparam() was set to be tparam_internal(), within lib_tparm.c.

I quickly worked out that the code has a bug for "%i". At some point
the code was changed to push and pop the parameters being passed (0 and
39 in my eg.). However, the "%i" select/case block was incrementing the
arguments in a no longer used array for parameters:


	    case 'i':
		if (p_is_s[0] == 0)
		    param[0]++;
		if (p_is_s[1] == 0)
		    param[1]++;
		break;

only the stack was being used to substitute the "%d"'s.

Not understanding why it was OK on the 32-bit build, I started debugging
it. Amongst the first problems I noticed is... the screen-4.2.1-1
package is linked against libncurses10-5.7-18, whereas my build was
linking against libncursesw10-5.7-18. Not a major deal, everything seems
to be interchanging (ie. screen 32-bit is working regardless of either).

Looking into the code for this slight older version (that 64-bits
libncursesw10-5.9-4), I noticed that the questionable code exists there
too.

Looking elsewhere for a difference, I noted that the 32-bit screen was
parameterizing a different definition for cs, "\e[%i%p1%d;%p2%dr".
Notice the "%p." notation. I've come to understand now that the two
notations differ in that the 64-bit is using the termcap style, and the
32-bit is using terminfo style definition (at least that's what I think
I understand). The latter style bypasses what is in my view the broken
code.

Trying to understand why screen ends up choosing one definition over
the other, I have come to realise it all stems from the config.h
generated by configure across the two platforms.

The 32-bit defines TERMINFO:

config.h:

/*
  * Define TERMINFO if your machine emulates the termcap routines
  * with the terminfo database.
  * Thus the .screenrc file is parsed for
  * the command 'terminfo' and not 'termcap'.
  */
#define TERMINFO 1

configure.log:

configure:5025: $? = 0
configure:5025: ./conftest.exe
configure:5025: $? = 1
configure: program exited with status 1

configure:

if ac_fn_c_try_run "$LINENO"; then :
   echo "- you use the termcap database" 1>&6

else
   echo "- you use the terminfo database" 1>&6
  $as_echo "#define TERMINFO 1" >>confdefs.h

fi


the 64-bit does not:

/* #undef TERMINFO */

configure:5025: $? = 0
configure:5025: ./conftest.exe
configure:5025: $? = 0

I can't understand why the ./conftest.exe differ. Trying to emulate by
hand, I cannot reproduce it. But it is now very late here, and I can't
debug anymore.

I'm hoping that I've provided enough of a lead for someone of authority
to decide where things are right, and where things are wrong.

-- 
Thanks,
Shaddy


--
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

Re: screen on 64-bit mangles mintty/buffer

[Andrew Schulman]

<snip>

> The 32-bit defines TERMINFO:
> 
> config.h:
> 
> /*
>   * Define TERMINFO if your machine emulates the termcap routines
>   * with the terminfo database.
>   * Thus the .screenrc file is parsed for
>   * the command 'terminfo' and not 'termcap'.
>   */
> #define TERMINFO 1
> 
> configure.log:
> 
> configure:5025: $? = 0
> configure:5025: ./conftest.exe
> configure:5025: $? = 1
> configure: program exited with status 1
> 
> configure:
> 
> if ac_fn_c_try_run "$LINENO"; then :
>    echo "- you use the termcap database" 1>&6
> 
> else
>    echo "- you use the terminfo database" 1>&6
>   $as_echo "#define TERMINFO 1" >>confdefs.h
> 
> fi
> 
> 
> the 64-bit does not:
> 
> /* #undef TERMINFO */
> 
> configure:5025: $? = 0
> configure:5025: ./conftest.exe
> configure:5025: $? = 0
> 
> I can't understand why the ./conftest.exe differ. Trying to emulate by
> hand, I cannot reproduce it. But it is now very late here, and I can't
> debug anymore.
> 
> I'm hoping that I've provided enough of a lead for someone of authority
> to decide where things are right, and where things are wrong.

Yes, I think so!

Thanks a lot, Shaddy.  That takes us a long way to a solution.  I'll look
at it from there as soon as I can.


--
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

Re: screen on 64-bit mangles mintty/buffer

[Christopher Faylor]

On Wed, May 14, 2014 at 02:15:38PM -0400, Andrew Schulman wrote:
><snip>
>
>> The 32-bit defines TERMINFO:
>> 
>> config.h:
>> 
>> /*
>>   * Define TERMINFO if your machine emulates the termcap routines
>>   * with the terminfo database.
>>   * Thus the .screenrc file is parsed for
>>   * the command 'terminfo' and not 'termcap'.
>>   */
>> #define TERMINFO 1
>> 
>> configure.log:
>> 
>> configure:5025: $? = 0
>> configure:5025: ./conftest.exe
>> configure:5025: $? = 1
>> configure: program exited with status 1
>> 
>> configure:
>> 
>> if ac_fn_c_try_run "$LINENO"; then :
>>    echo "- you use the termcap database" 1>&6
>> 
>> else
>>    echo "- you use the terminfo database" 1>&6
>>   $as_echo "#define TERMINFO 1" >>confdefs.h
>> 
>> fi
>> 
>> 
>> the 64-bit does not:
>> 
>> /* #undef TERMINFO */
>> 
>> configure:5025: $? = 0
>> configure:5025: ./conftest.exe
>> configure:5025: $? = 0
>> 
>> I can't understand why the ./conftest.exe differ. Trying to emulate by
>> hand, I cannot reproduce it. But it is now very late here, and I can't
>> debug anymore.
>> 
>> I'm hoping that I've provided enough of a lead for someone of authority
>> to decide where things are right, and where things are wrong.
>
>Yes, I think so!
>
>Thanks a lot, Shaddy.  That takes us a long way to a solution.  I'll look
>at it from there as soon as I can.

Andrew suggested that Shaddy should get a gold star for his excellent work in
tracking this down.  Andrew, please make it so?

cgf

--
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

Re: screen on 64-bit mangles mintty/buffer

[Andrew Schulman]

> >> I'm hoping that I've provided enough of a lead for someone of authority
> >> to decide where things are right, and where things are wrong.
> >
> >Yes, I think so!
> >
> >Thanks a lot, Shaddy.  That takes us a long way to a solution.  I'll look
> >at it from there as soon as I can.
> 
> Andrew suggested that Shaddy should get a gold star for his excellent work in
> tracking this down.  Andrew, please make it so?
> 
> cgf

Awarded!  http://cygwin.com/goldstars/#SB


--
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

Re: screen on 64-bit mangles mintty/buffer

[Shaddy Baddah]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

Hi,

On 2014-05-15 04:15+1000, Andrew Schulman wrote:
> <snip>
<snip>
>>
>> I can't understand why the ./conftest.exe differ. Trying to emulate by
>> hand, I cannot reproduce it. But it is now very late here, and I can't
>> debug anymore.
>>
>> I'm hoping that I've provided enough of a lead for someone of authority
>> to decide where things are right, and where things are wrong.
>
> Yes, I think so!
>
> Thanks a lot, Shaddy.  That takes us a long way to a solution.  I'll look
> at it from there as soon as I can.

No problem. I am always happy when I can contribute to my favourite Open
Source project and community.

With regards to the conftest difference on 32-bit vs. 64-bit, I believe
I understand it now.

It seems the code configure generates for that little test fails to
#include definitions for tgoto() (amongst others).

In trying to emulate it, I had actually put them in my code. My method
wasn't exact.

If I understand correctly (and a subsequent gdb run seems to confirm it;
Value returned is $1 = 0x600096230 "1" becomes a pointer to 0x96230)
the difference comes about because without the prototype, gcc pins an
int as the return type of tgoto(). But being a pointer, char *, on
64-bit the size mismatch (8 byte pointers, vs 4 byte int) means that
the pointer passed into strcmp() (as return from tgoto()) has 4 random
bytes copied in, and points to a random location.

Does that sound plausible? I am not 100% sure, because considering this
I thought that a 64-bit Linux should be afflicted in the same way.

However despite gcc complaining as well over missing prototypes,
strcmp() is being passed the correct (char *) pointer from tgoto(). Is
this down to the difference in gcc (4.8 on cygwin, 4.7 on debian)? Or
just the difference in architecture?

In any case, I've tested the patch below, and it solves the immediate
problem with screen. It probably needs to go upstream too... I'd put
my hand up, but I'm unsure where upstream is exactly.

-- 
Regards,
Shaddy

[-- Attachment #2: screen-terminfo-autoconf.diff --]
[-- Type: text/x-patch, Size: 348 bytes --]

--- origsrc/screen/src/configure.in	2013-06-17 20:48:45.000000000 +1000
+++ src/screen/src/configure.in	2014-05-15 21:42:36.949278900 +1000
@@ -680,6 +680,9 @@
 AC_MSG_ERROR(!!! no tgetent - no screen)))))))
 
 AC_TRY_RUN([
+#include <term.h>
+#include <string.h>
+#include <stdlib.h>
 main()
 {
  exit(strcmp(tgoto("%p1%d", 0, 1), "1") ? 0 : 1);


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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

Re: screen on 64-bit mangles mintty/buffer

[Andrew Schulman]

> In any case, I've tested the patch below, and it solves the immediate
> problem with screen. It probably needs to go upstream too... I'd put
> my hand up, but I'm unsure where upstream is exactly.

I've uploaded a new test release of screen that incorporates this patch. So
we'll see if it fixes the problem.  I can't reproduce the problem on my
current machine (not sure why), so I can't test it here, but I'll test it
later from home.


--
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

Re: screen on 64-bit mangles mintty/buffer

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]



Nice detective work, really.  The goldstar is well deservered :)

On May 15 04:00, Shaddy Baddah wrote:
> I quickly worked out that the code has a bug for "%i". At some point
> the code was changed to push and pop the parameters being passed (0 and
> 39 in my eg.). However, the "%i" select/case block was incrementing the
> arguments in a no longer used array for parameters:
> 
> 
> 	    case 'i':
> 		if (p_is_s[0] == 0)
> 		    param[0]++;
> 		if (p_is_s[1] == 0)
> 		    param[1]++;
> 		break;

Unfortunately there's no newer upstream release and this bug is present
in the ncurses 5.9 version in Fedora 20 as well.  From what I gather from the
surrounding code, I *assume* something like this could fix it

            case 'i':
                y = npop();
                x = npop();
                if (p_is_s[0] == 0)
                    y++;
                if (p_is_s[1] == 0)
                    x++;
                npush(x);
                npush(y);
                break;

I'm not sure the relation between x, y, and the p_is_s indices is
correct, though.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: screen on 64-bit mangles mintty/buffer

[Shaddy Baddah]

Hi Corinna,


On 2014-05-15 17:17+1000, Corinna Vinschen wrote:
>
>
> Nice detective work, really.  The goldstar is well deservered :)
>
> On May 15 04:00, Shaddy Baddah wrote:
>> I quickly worked out that the code has a bug for "%i". At some point
>> the code was changed to push and pop the parameters being passed (0 and
>> 39 in my eg.). However, the "%i" select/case block was incrementing the
>> arguments in a no longer used array for parameters:
>>
>>
>> 	    case 'i':
>> 		if (p_is_s[0] == 0)
>> 		    param[0]++;
>> 		if (p_is_s[1] == 0)
>> 		    param[1]++;
>> 		break;
>
> Unfortunately there's no newer upstream release and this bug is present
> in the ncurses 5.9 version in Fedora 20 as well.  From what I gather from the
> surrounding code, I *assume* something like this could fix it
>
>              case 'i':
>                  y = npop();
>                  x = npop();
>                  if (p_is_s[0] == 0)
>                      y++;
>                  if (p_is_s[1] == 0)
>                      x++;
>                  npush(x);
>                  npush(y);
>                  break;
>
> I'm not sure the relation between x, y, and the p_is_s indices is
> correct, though.

Yes, that's the code that I thought of as well, and same, I'd have to
get my head around the exact order of p_is_s (unfortunate name), etc.

When you say the bug is present in ncurses 5.9, is there any application
that is directly affected? I ask as screen being affected was sort of a
fluke. It's configure script should have detected terminfo notation was
available for use, and used the equivalent entry for "cs".

So I'm wondering if there are many applications still out there that are
trying to use the older, more terse termcap form? And also linking in
with ncurses?

Seems unlikely, as I would have expected that if there were, and any
were using a cap entry with "%i" that there would have been obvious
presentation problems.

-- 
Regards.
Shaddy


--
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

Re: screen on 64-bit mangles mintty/buffer

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

On May 15 22:54, Shaddy Baddah wrote:
> Hi Corinna,
> 
> 
> On 2014-05-15 17:17+1000, Corinna Vinschen wrote:
> >
> >
> >Nice detective work, really.  The goldstar is well deservered :)
> >
> >On May 15 04:00, Shaddy Baddah wrote:
> >>I quickly worked out that the code has a bug for "%i". At some point
> >>the code was changed to push and pop the parameters being passed (0 and
> >>39 in my eg.). However, the "%i" select/case block was incrementing the
> >>arguments in a no longer used array for parameters:
> >>
> >>
> >>	    case 'i':
> >>		if (p_is_s[0] == 0)
> >>		    param[0]++;
> >>		if (p_is_s[1] == 0)
> >>		    param[1]++;
> >>		break;
> >
> >Unfortunately there's no newer upstream release and this bug is present
> >in the ncurses 5.9 version in Fedora 20 as well.  From what I gather from the
> >surrounding code, I *assume* something like this could fix it
> >
> >             case 'i':
> >                 y = npop();
> >                 x = npop();
> >                 if (p_is_s[0] == 0)
> >                     y++;
> >                 if (p_is_s[1] == 0)
> >                     x++;
> >                 npush(x);
> >                 npush(y);
> >                 break;
> >
> >I'm not sure the relation between x, y, and the p_is_s indices is
> >correct, though.
> 
> Yes, that's the code that I thought of as well, and same, I'd have to
> get my head around the exact order of p_is_s (unfortunate name), etc.
> 
> When you say the bug is present in ncurses 5.9, is there any application
> that is directly affected? I ask as screen being affected was sort of a
> fluke. It's configure script should have detected terminfo notation was
> available for use, and used the equivalent entry for "cs".

Well, according to Murphy, if there's a bug, it will be hit.

One of them is, for instance, tcsh, which still uses the termcap
functions deliberately for compatibility with old systems, even when
linked against [n]curses[w].  Fortunately tcsh doesn't try to use really
fancy terminal sequences...

There are very likely more projects out there doing that.  And on many
systems the only way to get the termcap functions is to use ncurses.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]