ID: 27132 User updated by: neuhauser at chello dot cz Reported By: neuhauser at chello dot cz -Status: Bogus +Status: Open Bug Type: ncurses related Operating System: * PHP Version: 5CVS, 4CVS (2005-12-22) (cvs) Assigned To: hholzgra New Comment:
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 pecl.php.net. What's the real state of the extension, and what can I expect from its documentation? Previous Comments: ------------------------------------------------------------------------ [2006-01-05 23:18:35] [EMAIL PROTECTED] this 'bug' was caused by misuse of declare() ------------------------------------------------------------------------ [2006-01-05 21:30:02] [EMAIL PROTECTED] This will not be fixed in core. And the extension has been moved to PECL now. ------------------------------------------------------------------------ [2005-12-19 09:02:21] [EMAIL PROTECTED] 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.. ------------------------------------------------------------------------ [2004-02-03 09:51:52] neuhauser at chello dot cz Description: ------------ receipt of a signal interrupts ncurses_getch(), which should never happen curs_getch(3X): 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 <?php function sigalrm() { global $c; $s = sprintf("sigalrm: '%d'\n", $c); ncurses_addstr($s); ncurses_refresh(); } ncurses_init(); ncurses_cbreak(); ncurses_nl(); ncurses_noecho(); pcntl_signal(SIGALRM, 'sigalrm'); declare(ticks = 1); for (;;) { pcntl_alarm(1); $c = ncurses_getch(); if ('q' == chr($c)) { exit(0); } } ncurses_end(); exit(0); 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); addstr(s); refresh(); } int main(int argc, char** argv) { initscr(); cbreak(); nl(); noecho(); signal(SIGALRM, sigalrm); for (;;) { alarm(1); c = getch(); if ('q' == c) { return 0; } } endwin(); 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, http://www.php.net/manual/en/ref.ncurses.php says "On error ncurses functions return NCURSES_ERR", but said constant doesn't exist in 4.3.3 or 4.3.4, both cli) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=27132&edit=1