Re: lib/56388: curses addstr test fails for LP64BE platforms

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

The following reply was made to PR lib/56388; it has been noted by GNATS.

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: lib/56388: curses addstr test fails for LP64BE platforms
Date: Tue, 7 Sep 2021 01:07:39 +0900

 Oops, not sent to gnats-bugs@...
 
 -------- Forwarded Message --------
 Subject: Re: lib/56388: curses addstr test fails for LP64BE platforms
 Date: Mon, 6 Sep 2021 21:25:28 +0900
 From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
 Reply-To: gnats-bugs%netbsd.org@localhost
 To: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
 CC: Brett Lymn <blymn%internode.on.net@localhost>
 
 In __newwin() and __resizewin(), hash value for line is calculated
 as if HAVE_WCHAR is disabled.
 
 If this bug is fixed with this patch:
 
 https://gist.github.com/rokuyama/fad462d0b63934e909b83b584dd3cdc6
 
 addstr test becomes to fail on other platforms including amd64, in
 the same manner as on LP64BE machines.
 
 On the other hand, even if this patch is applied, the test case for
 lib/55931 (for which this part of test was introduced) does not fail;
 the overflown text is truncated instead of overwrapped.
 
 Also, I've confirmed that there is no regression in other ATF tests.
 
 So, I think that check_files/addstr2.chk is generated depending on
 ``wrong'' behavior due to the bug, and should be regenerated after
 the bug is fixed.
 
 Thoughts?
 
 Thanks,
 rin