NetBSD Problem Report #57865

From www@netbsd.org  Thu Jan 18 12:54:31 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id AB6F31A9238
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 18 Jan 2024 12:54:31 +0000 (UTC)
Message-Id: <20240118125400.95E4B1A9239@mollari.NetBSD.org>
Date: Thu, 18 Jan 2024 12:54:00 +0000 (UTC)
From: achowe@snert.com
Reply-To: achowe@snert.com
To: gnats-bugs@NetBSD.org
Subject: Curses addch() family does not handle tab correctly.
X-Send-Pr-Version: www-1.0

>Number:         57865
>Category:       lib
>Synopsis:       Curses addch() family does not handle tab correctly.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 18 12:55:00 +0000 2024
>Last-Modified:  Fri Jan 19 21:40:01 +0000 2024
>Originator:     Anthony Howe
>Release:        9.3
>Organization:
>Environment:
NetBSD elf.snert.com 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug  4 15:30:37 UTC 2022  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

>Description:
Displaying a string with tabs using addstr() advances the cursor to the next tab stop, a multiple of 8, just fine.

Displaying a string with tabs via repeated calls to addch(), incorrectly handlings tabs.
>How-To-Repeat:
This short program demonstrates the problem:
```
#include <curses.h>
#include <unistd.h>


void
ruler(void)
{
	standout();
	addstr("123456789.123456789.123456789.123456789.\n");
	standend();
}

void
test_addch_tab(const char *s)
{
	for ( ; *s != '\0'; s++) {
		/* Historical Curses handling of TAB would advance to
		 * the next tabstop (a multiple of 8, eg. 0, 8, 16, ...).
		 * See SUS Curses Issue 7 section 3.4.3.
		 */
		addch(*s);
	}
}

int
main(int argc, char **argv)
{
	const char t1[] = "\t9.123\t78\n";
	const char t2[] = "1234\t9.123\t\t567\n";
	const char t3[] = "Append tab string:";

	if (initscr() == NULL) {
		return 1;
	}

	addstr("\nTab behaviour with addstr() normal.\n");
	ruler();
	addstr(t1);
	addstr(t2);
	addstr(t3); addstr(t1);

	addstr("\nTab behaviour with addch() broken.\n");
	ruler();
	test_addch_tab(t1);
	test_addch_tab(t2);
	test_addch_tab(t3); test_addch_tab(t1);

	refresh();
	sleep(10);
	endwin();

	return 0;
}
```
>Fix:

>Audit-Trail:
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/57865: Curses addch() family does not handle tab
 correctly.
Date: Thu, 18 Jan 2024 13:56:20 +0000 (UTC)

 On Thu, 18 Jan 2024, achowe@snert.com wrote:

 >> Description:
 > Displaying a string with tabs using addstr() advances the cursor to the next tab stop, a multiple of 8, just fine.
 >
 > Displaying a string with tabs via repeated calls to addch(), incorrectly handlings tabs.
 >

 Looks like this has been fixed in the 10.x curses. Don't know if all the
 changes there will be merged into the older branches.

 -RVP

From: Brett Lymn <blymn@internode.on.net>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
        achowe@snert.com
Subject: Re: lib/57865: Curses addch() family does not handle tab correctly.
Date: Sat, 20 Jan 2024 08:06:31 +1030

 On Thu, Jan 18, 2024 at 02:00:02PM +0000, RVP wrote:
 >  
 >  Looks like this has been fixed in the 10.x curses. Don't know if all the
 >  changes there will be merged into the older branches.
 >  

 There was a very significant rototill of curses in 10.x that corrected a lot of positioning
 and colour handling bugs. This may make it difficult to backport a single function.
 Fortunately it would be possible to just backport the whole changeset as curses is fairly
 independent, it would be a matter of identifying the commits and requesting a pullup to 9.x
 and 8.x

 -- 
 Brett Lymn
 --
 Sent from my NetBSD device.

 "We are were wolves",
 "You mean werewolves?",
 "No we were wolves, now we are something else entirely",
 "Oh"

Home	PR Database Search