(not) catching ^C in ghc-built application

[Malcolm Wallace]

> I have a program, written in a mixture of Haskell and C, in which the
> C part is supposed to handle a ^C interrupt, accomplished through the
> usual signal() call.  But when it is compiled by ghc, for some reason
> the ghc RTS appears to trap the interrupt itself, and halts the
> program with the message
>     prog: interrupted
> instead of allowing the newly installed C signal handler to run.

I finally found the cause of this.  The ghc RTS has a global variable
`interrupted', which is set by its interrupt handler, and tested by
various other parts of the scheduler.

Guess what - my C routines also have a global variable called
`interrupted', and my own ^C interrupt handler was also setting
this variable.  D'oh.  If I change the name of my global variable,
then everything works as it ought to.

I know it's a pain for you, but can I file this as a bug report
in ghc?  Stealing simple and obvious global identifiers from the
user's namespace is rather dangerous, and even more so when it is
undocumented.

Regards,
    Malcolm