Hi,
this might just be my misunderstanding of the way this library deals with interrupts, but the current behaviour seems a bit broken.
When one presses Ctrl+C, I would expect bestline to do some cleanup and then re-raise the interrupt for the calling function.
This is not what happens at all.
Currently, when pressing Ctrl+C, the library seemingly does nothing, though it "eats" the next key press (meaning, the next key press seems to be ignored, but after that everything works as expected again). Only when pressing Ctrl+C twice, the interrupt is propagated properly and errno is set to EINTR.
After looking at the source code and seeing that there are signal handlers in place, I tried to track down the issue and I found this in bestline.c:1360:
For some reason, if the program receives an interrupt during this read call, it does not call the interrupt handler or set errno. Instead, read sets c to 3 (ETX). I'm honestly not sure what this means or if it is intended, but I was able to get the expected behaviour by simply calling the interrupt handler manually in this case.
rc = read(fd,&c,1);
if (c == 3){
bestlineOnInt(SIGINT);
}
While this works for me right now, I doubt this is a robust fix.
Am I on the right track here, or is the current behaviour intended?
Thanks in advance.
Hi,
this might just be my misunderstanding of the way this library deals with interrupts, but the current behaviour seems a bit broken.
When one presses
Ctrl+C, I would expectbestlineto do some cleanup and then re-raise the interrupt for the calling function.This is not what happens at all.
Currently, when pressing
Ctrl+C, the library seemingly does nothing, though it "eats" the next key press (meaning, the next key press seems to be ignored, but after that everything works as expected again). Only when pressingCtrl+Ctwice, the interrupt is propagated properly and errno is set toEINTR.After looking at the source code and seeing that there are signal handlers in place, I tried to track down the issue and I found this in
bestline.c:1360:For some reason, if the program receives an interrupt during this
readcall, it does not call the interrupt handler or seterrno. Instead,readsetscto3(ETX). I'm honestly not sure what this means or if it is intended, but I was able to get the expected behaviour by simply calling the interrupt handler manually in this case.While this works for me right now, I doubt this is a robust fix.
Am I on the right track here, or is the current behaviour intended?
Thanks in advance.