(not) catching ^C in ghc-built application

[Seth Kurtzberg]

Neither of you should be using a global variable at all!  Do something like 
this:

struct _myglobals
{
	.
	.
	.
	bool interrupted;
	.
	.
	.
} myglobals;

and then replace "interrupted" with "myglobals.interrupted".

C has enough problems without using unqualified globals!

On Tuesday 13 August 2002 07:36, Malcolm Wallace wrote:
> > 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
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- 
Seth Kurtzberg
MIS
480-661-1849
Pager 888-605-9296 or 6059296@skytel.com
Cell 480-620-1099