[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
lib/41894: [dM] printw return value wrong
>Synopsis: [dM] successful printw's return value is wrong
>Arrival-Date: Sun Aug 16 03:40:01 +0000 2009
>Originator: der Mouse
>Release: NetBSD 4.0.1
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
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()'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.
% cat curses-bug.c
n = printw("Hello");
% cc -o curses-bug curses-bug.c -lcurses -ltermcap
Note that the number printed by the second printw is not 5.
Because I think the documented behaviour is more useful and
less surprising, I've been treating this as a sw-bug. From
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)
+ int n;
if ((f = funopen(win, NULL, __winwrite, NULL, NULL)) == NULL)
- (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@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Very similar symptoms seen on 5.0_STABLE, 3.1, and even 1.4T.
Main Index |
Thread Index |