The issue is whether or not a command dying from SIGINT should cause the shell to act as if it received the SIGINT and break out of the loop.

bash-4.4 will break the loop.

The following reproduces with Bash 4.3, patch 30, in an interactive session.

Suppose we install a SIGINT trap as follows:

    $ func() { echo; echo FUNC; }
    $ trap func SIGINT

Now if we type ^C at the prompt, we get:

    $ ^C
    FUNC

    $

If we interrupt a command like cat, we do not see FUNC: the trap does not run. However, the interrupt is successful.

    $ cat
    ^C
    $

If we interrupt a loop consisting of just built in commands, this happens:

    $ while true ; do : ; done
    ^C
    FUNC

    $

Unlike the cat case, interrupt works, and the trap is also executed.

Now suppose we combine the two and make a loop which calls cat:

    $ while true ; do cat ; done
    ^C
    ^C
    ^C

Oops! We cannot interrupt this because SIGINT is trapped, yet there is no evidence of the execution of the trap. We must use SIGTSTP to get out of the situation:

    ^Z
    [1]+  Stopped                 cat
    $ kill %1
    $
    [1]+  Terminated              cat
    $

I don't know what the expected behavior should be. The possibilities which suggest themselves to me:

1. Trapped means that the handler takes the whole responsibility for the SIGINT, and so overrides interrupting behavior. No command can be interrupted if the trap is in effect: the trap prints its message, and then the command resumes. External commands which receive the SIGINT from the kernel do whatever they want; if they terminate, then the shell handles that. Built in commands such as infinite loops become uninterruptible, but the trap handler's message is reliably seen.

2. Trapped means, in interactive mode at least, that the handler is invoked, and that the command is aborted via a transfer back to the top level interactive loop. We consistently see the message printed by the handler, and are consistently brought back to the interactive command prompt.