NetBSD Problem Report #41894

From mouse@Sparkle.Rodents-Montreal.ORG  Sun Aug 16 03:35:04 2009
Return-Path: <mouse@Sparkle.Rodents-Montreal.ORG>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id A084663C284
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 16 Aug 2009 03:35:04 +0000 (UTC)
Message-Id: <200908160335.XAA15286@Sparkle.Rodents-Montreal.ORG>
Date: Sat, 15 Aug 2009 23:24:34 -0400 (EDT)
From: der Mouse <mouse@Rodents-Montreal.ORG>
Reply-To: mouse@Rodents-Montreal.ORG
To: gnats-bugs@gnats.NetBSD.org
Subject: [dM] printw return value wrong
X-Send-Pr-Version: 3.95

>Number:         41894
>Category:       lib
>Synopsis:       [dM] successful printw's return value is wrong
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    lib-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Sun Aug 16 03:40:01 +0000 2009
>Closed-Date:    Wed Apr 06 08:40:03 +0000 2011
>Last-Modified:  Wed Apr 06 08:50:06 +0000 2011
>Originator:     der Mouse
>Release:        NetBSD 4.0.1
>Organization:
	Dis-
>Environment:
System: NetBSD Laptop-401.Rodents-Montreal.ORG 4.0.1 NetBSD 4.0.1 (GEN401_WD0F) #0: Mon Jul 20 23:52:41 EDT 2009 mouse@Laptop-401.Rodents-Montreal.ORG:/home/mouse/kbuild/GEN401_WD0F i386
Architecture: i386
Machine: i386
>Description:
	printw()'s manpage documents it as

		The printw() function formats and prints its arguments
		on stdscr.  The behaviour is the same as that of
		printf().

	printf()'s manpage says that it "return[s] the number of
	characters printed".  However, printw() does not do so;
	printw("Hello") returns 0 in most of my tests, 1 on 1.4T.

	See how-to-repeat for details.  My tests show this bug present
	on my machines under 1.4T, 3.1, and 4.0.1; it is also present
	on ftp.n.o, where uname -a reports 5.0_STABLE.

	Alternatively, this could be viewed as a doc-bug, with the
	manpage rather than the code being what needs fixing.  The
	manpage cites the X/Open Curses spec, saying it's part of SUS.
	I went looking for this and failed - some of what I found
	implies it's a pay-to-play "standard"; others seemed to think
	they were making it available, but without actually making
	anything available as far as I could tell.  If anyone has a
	copy of it handy, and it clarifies this, whichever part
	disagrees with the spec is presumably what should change.
>How-To-Repeat:
	% cat curses-bug.c
	#include <stdio.h>
	#include <curses.h>

	int main(void);
	int main(void)
	{
	 int n;

	 initscr();
	 clear();
	 move(10,10);
	 n = printw("Hello");
	 move(12,10);
	 printw("%d",n);
	 refresh();
	 endwin();
	 printf("\n");
	 return(0);
	}
	% cc -o curses-bug curses-bug.c -lcurses -ltermcap
	% ./curses-bug

	Note that the number printed by the second printw is not 5.
>Fix:
	Because I think the documented behaviour is more useful and
	less surprising, I've been treating this as a sw-bug.  From
	that perspective:

	vwprintw (vw_printw in some versions), which is the guts of
	most of the printw() family, creates a callback stdio stream
	with funopen, vfprintf()s to it, and then returns either ERR or
	OK, ignoring the return value from vfprintf.

	While I haven't tested it - the program that led me to find
	this has to be portable enough that the only option for it is
	to tolerate this bug - I would expect that saving vfprintf's
	return value and returning it in the success case would be a
	suitable fix.  Perhaps something like (manually constructed)

	 	FILE *f;
	+	int n;

	 	if ((f = funopen(win, NULL, __winwrite, NULL, NULL)) == NULL)
	 		return (ERR);
	-	(void) vfprintf(f, fmt, ap);
	-	return (fclose(f) ? ERR : OK);
	+	n = vfprintf(f, fmt, ap);
	+	return (fclose(f) ? ERR : n);
	 }

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

>Release-Note:

>Audit-Trail:
From: der Mouse <mouse@Rodents-Montreal.ORG>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/41894: [dM] printw return value wrong
Date: Sun, 16 Aug 2009 00:20:22 -0400 (EDT)

 In off-ticket correspnodence, someone pointed out to me that there's a
 RETURN VALUES section which specifies the existing return values.

 So the manpage contradicts itself, and needs updating whether or not
 anything is done to the code - either the RETURN VALUES section needs
 updating or the description needs to note that the return value is not
 an aspect of printf's interface which is carried over to printw's.

 Naturally, I'd prefer to see the printf-like behaviour, since that's
 the more useful, but, if SUS specifies the less informative behaviour,
 then this really is just ("just", heh) a doc-bug.

 /~\ The ASCII				  Mouse
 \ / Ribbon Campaign
  X  Against HTML		mouse@rodents-montreal.org
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: Brett Lymn <blymn@baesystems.com.au>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
        mouse@Rodents-Montreal.ORG
Subject: Re: lib/41894: [dM] printw return value wrong
Date: Sun, 16 Aug 2009 14:22:22 +0930

 On Sun, Aug 16, 2009 at 04:25:01AM +0000, der Mouse wrote:
 > 
 >  In off-ticket correspnodence, someone pointed out to me that there's a
 >  RETURN VALUES section which specifies the existing return values.
 >  

 According to SUSv2 the return values section is correct.  The only values
 returned by printw() and friends are ERR and OK.

 >  So the manpage contradicts itself, and needs updating whether or not
 >  anything is done to the code - either the RETURN VALUES section needs
 >  updating or the description needs to note that the return value is not
 >  an aspect of printf's interface which is carried over to printw's.
 >  

 This is a doc bug - the phrase "the same as" should be changed to
 "similar to" which is a synonym for the SUSv2 wording of "analogous"

 >  Naturally, I'd prefer to see the printf-like behaviour, since that's
 >  the more useful, but, if SUS specifies the less informative behaviour,
 >  then this really is just ("just", heh) a doc-bug.
 >  

 Much as I agree witht he sentiment of the usefulness of the printf like
 behaviour SUSv2 disagrees..

 -- 
 Brett Lymn
 "Warning:
 The information contained in this email and any attached files is
 confidential to BAE Systems Australia. If you are not the intended
 recipient, any use, disclosure or copying of this email or any
 attachments is expressly prohibited.  If you have received this email
 in error, please notify us immediately. VIRUS: Every care has been
 taken to ensure this email and its attachments are virus free,
 however, any loss or damage incurred in using this email is not the
 sender's responsibility.  It is your responsibility to ensure virus
 checks are completed before installing any data sent in this email to
 your computer."


From: der Mouse <mouse@Rodents-Montreal.ORG>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/41894: [dM] printw return value wrong
Date: Sun, 16 Aug 2009 01:09:06 -0400 (EDT)

 >>  - either the RETURN VALUES section needs updating or the
 >>  description needs to note that the return value is not an aspect of
 >>  printf's interface which is carried over to printw's.
 > This is a doc bug - the phrase "the same as" should be changed to
 > "similar to" which is a synonym for the SUSv2 wording of "analogous"

 I'd actually prefer to see the return value specifically called out as
 different.  "Similar to" wouldn't be enough to have prevented the
 mistake that led me to trip over this; after all, printw's interface
 can't be _totally_ the same as printf's, or it would _be_ printf.  I'd
 still read "printw's interface is similar to printf's" as "in the
 respects that don't have to differ (because it's printing to a curses
 window rather than a stdio stream), printw is identical to printf",
 which it isn't.

 If you want strawman wording, I'll propose

 	The printw() function formats and prints its arguments on
 	stdscr.  The interface is deliberately similar to printf(3)'s
 	(but, notably, the return value differs).

 /~\ The ASCII				  Mouse
 \ / Ribbon Campaign
  X  Against HTML		mouse@rodents-montreal.org
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

State-Changed-From-To: open->closed
State-Changed-By: jruoho@NetBSD.org
State-Changed-When: Wed, 06 Apr 2011 08:40:03 +0000
State-Changed-Why:

Fixed with the "strawman wording" noted in the last comment.           



From: "Jukka Ruohonen" <jruoho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41894 CVS commit: src/lib/libcurses
Date: Wed, 6 Apr 2011 08:38:44 +0000

 Module Name:	src
 Committed By:	jruoho
 Date:		Wed Apr  6 08:38:44 UTC 2011

 Modified Files:
 	src/lib/libcurses: curses_print.3

 Log Message:
 Fix PR # 41894.


 To generate a diff of this commit:
 cvs rdiff -u -r1.6 -r1.7 src/lib/libcurses/curses_print.3

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:
  >Submitter-Id:	net
 	Very similar symptoms seen on 5.0_STABLE, 3.1, and even 1.4T.

Home	PR Database Search