|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27132 ncurses_getch() interrupted by receipt of a handled signal
Submitted: 2004-02-03 09:51 UTC Modified: 2006-04-10 13:01 UTC
From: neuhauser at chello dot cz Assigned: hholzgra (profile)
Status: Not a bug Package: ncurses related
PHP Version: 5CVS, 4CVS (2005-12-22) (cvs) OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
37 + 16 = ?
Subscribe to this entry?

 [2004-02-03 09:51 UTC] neuhauser at chello dot cz
receipt of a signal interrupts ncurses_getch(), which
should never happen


The behavior of getch and friends in the presence
of handled signals is unspecified in the SVr4 and
XSI Curses documentation.  Under historical curses
implementations, it  varied depending on whether
the operating system's implementation of handled
signal receipt interrupts a read(2) call in
progress or not, and also (in some implementations)
depending on whether an input timeout or
non-blocking mode hsd been set.
Programmers concerned about portability should be
prepared  for  either of  two  cases: (a) signal
receipt does not interrupt getch; (b) signal
receipt interrupts getch and causes it to return
ERR with errno set to EINTR.
Under the ncurses implementation, handled signals
never interrupt getch.

(emphasis added)

Reproduce code:
compare the behavior of this PHP snippet


    function sigalrm()
        global $c;
        $s = sprintf("sigalrm: '%d'\n", $c);


    pcntl_signal(SIGALRM, 'sigalrm');
    declare(ticks = 1);

    for (;;) {
        $c = ncurses_getch();
        if ('q' == chr($c)) {


with its C equivalent

#include <unistd.h>
#include <signal.h>
#include <curses.h>

int c;

void sigalrm()
    char s[40];
    sprintf(s, "sigalrm: '%d'\n", c);

int main(int argc, char** argv)

    signal(SIGALRM, sigalrm);

    for (;;) {
        c = getch();
        if ('q' == c) {
            return 0;

    return 0;

Expected result:
I was expecting to see the same output as given by the C version: single

sigalrm: '0'

line until next keypress, then the zero would be replaced with ascii code of the pressed key

Actual result:
endless series of

sigalrm: '-1'

lines, which suggests that receipt of the alarm, although handled, interrupts the getch() call which then returns ERR.

(as a sidenote, says "On error ncurses functions return NCURSES_ERR", but said constant doesn't exist in 4.3.3 or 4.3.4, both cli)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-12-19 09:02 UTC]
Hartmut: If you're not going to do anything about this, please  de-assign it with some comment. And preferrably move the whole extension to PECL the same time..
 [2006-01-05 21:30 UTC]
This will not be fixed in core. And the extension has been moved to PECL now.
 [2006-01-05 23:18 UTC]
this 'bug' was caused by misuse of declare()
 [2006-02-19 19:34 UTC] neuhauser at chello dot cz
I'm happy to read that the problem was my fault. I have re-read the declare() description and the ncurses extension documentation, and see no hints as to what I did wrong. Can you please describe the interactions between declare() and ncurses_getch()?

On a related note: the extension has been experimental for the last three years or so, but is marked stable on What's the real state of the extension, and what can I expect from its documentation?
 [2006-04-10 13:01 UTC]
Report any bugs in this extension in the PECL bugs system.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Mon Apr 19 05:01:23 2021 UTC