Re: Behaviour of wgetch during Signal Handling (EINTR)

[winter-ncurses]

Hi Thomas,

> I recall this being discussed before, [...]

Maybe this [0]?

> In this case, I believe the comment (probably originally written by Eric
> Raymond) refers to the logic in lib_getch.c which is ifdef'd with HIDE_EINTR. 
> The ifdef itself dates from a rewrite by Alexander Lukyanov in August 1997,
> and appears to have been "off" since it was added.

It seems I missed the HIDE_EINTR section but like you said it was never active.
As it is "off" by default, it might be reasonable to get rid of it?
Of course, someone *could* compile ncurses with HIDE_EINTR but that we don't
know.

> documentation is easier to change :-)

Maybe just removing the empty promise
 "Under the ncurses implementation, handled signals never interrupt getch."
is enough for now? After all, the previous sentences describes what can possibly
happen. Of course an addition to the "Return Value" section about the meaning of
ERR would help as well (+ errno = EINTR).
Due to my limited viewpoint of Linux [1] only I cannot provide an objective
in-depth explaination (suited for a man page) of signal handling behaviour.
However when writing a portable application using ncurses one shall always
account for a scenario described as (b) where the function returns ERR and errno
is EINTR.

It seems people have been implementing work-arounds for EINTR on wgetch for some
time already [2].

Regards,
Leon

[0] https://lists.gnu.org/archive/html/bug-ncurses/2005-07/msg00009.html
[1] Modern Linux that is, as signal handlers and syscalls interplay changed in
    the past
[2] http://www.zsh.org/mla/users/2011/msg00307.html