Skip to content

Interrupt handling seems broken #22

@Innf107

Description

@Innf107

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:

rc = read(fd,&c,1);

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions