[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: not bug
From: |
Thomas Dickey |
Subject: |
Re: not bug |
Date: |
Wed, 07 Aug 2013 16:51:00 -0400 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Wed, Aug 07, 2013 at 08:10:29PM +0400, mallachiev wrote:
> To Tomas. I have a question about
> https://bugzilla.redhat.com/show_bug.cgi?id=892674#c3. Is there any
> documented conformation that i should call fflush(stdout) or
google on "mixing printf curses" finds at the moment 940,000 hits...
A lot of those are related. It's been that way for so long, that I
can't recall the first time the question came up. However, standards are
weak on prohibiting things - they leave them unspecified to allow growth
in unexpected areas.
"X/Open Curses, Issues 7" says of newterm's input/output file pointers:
It is unspecified whether Curses modifies the buffering mode of these
file pointers.
It doesn't actually say (again unspecified) what Curses _does_ with the file
pointers,
doesn't specify how output is flushed using the stdio functions. Rather, the
standard
points to specific functions in the Curses interface which flush output
generated by
Curses calls.
There are certain low-level calls which are specified to write to stdout (putp
for instance),
and there are similar calls which write using a caller-supplied function
(tputs).
The standard doesn't say whether the high-level curses functions use these.
The standard is very consistent, pointing to printw as the Curses equivalent of
printf.
It nowhere (that I can find) implies that an application can write to the
screen using
stdio while in curses-mode. It does mention buffering in
As a note in the initscr/newterm description, it says
Applications should perform any required handling of the SIGINT,
SIGQUIT, or SIGTSTP signals before calling initscr.
ncurses of course uses this restriction to provide signal handlers.
So... (as I did, in reviewing the impact of this change, and finding a bug to
fix -
see the change in 20130112 for putp), my advice is to pare down the assumptions
in
the test-suite when it turns out that the standard doesn't require that detail.
> shouldn't mix stdio calls with ncurses calls. How can anybody
> understand it not looking to this bag?
> We develop tests for LSB, and there is a problem with mixing stdio
> calls with ncurses calls; possible solution is call fflush(stdout),
> but should be documented reason for it.
>
> --
> Kurban Mallachiev
> Linux Verification Center, ISPRAS
> web: http://linuxtesting.org
>
> _______________________________________________
> Bug-ncurses mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-ncurses
--
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
- not bug, mallachiev, 2013/08/07
- Re: not bug,
Thomas Dickey <=