(not) catching ^C in ghc-built application

[Simon Marlow]

> > I have a program, written in a mixture of Haskell and C, in=20
> which the
> > C part is supposed to handle a ^C interrupt, accomplished=20
> through the
> > usual signal() call.  But when it is compiled by ghc, for=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.

These global "common" variables are a pain in the neck.  There are 44 of
these in GHC's RTS - we should really at the least initialise them so
that you'll get a conflict if you define a global with the same name in
your own code.

Thanks for the report.

Cheers,
	Simon