Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!labrea!decwrl!hplabs!hpcea!hpsrla!hpsrlc!darrylo
From: darrylo@hpsrlc.HP.COM (Darryl Okahata)
Newsgroups: comp.sys.ibm.pc
Subject: Re: signal() for Turbo C
Message-ID: <3320051@hpsrlc.HP.COM>
Date: Thu, 3-Sep-87 11:13:43 EDT
Article-I.D.: hpsrlc.3320051
Posted: Thu Sep  3 11:13:43 1987
Date-Received: Sat, 5-Sep-87 16:59:22 EDT
References: <1009@bsu-cs.UUCP>
Organization: HP Network Measurements Div - Santa Rosa, CA
Lines: 43

In comp.sys.ibm.pc, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:

> In article <3320049@hpsrlc.HP.COM> darrylo@hpsrlc.HP.COM (Darryl Okahata) 
> writes:
> [about problems caused by Turbo C ctrlbrk() apparently not switching to
> Turbo C's own stack]:
> >If I hit ^C while performing the DOS
> >call (which is intercepted by PCED), main_handler() gets the stack used by
> >PCED; not only is the offset different, but the stack SEGMENT is totally
> >different.  main_handler() may or may not have enough stack room in which
> >to work.  Everything may work fine, or your system may crash.
> >
> >     I think the bug here is in Turbo C -- the library routines should
> >handle messy details like making sure that the stack is correct.
> 
     [ ... ]
> 
> But the description given by Duncan does say that the control-C handler
> can do anything that the rest of the program does.  This does seem to
     [ ... ]
> 
> I wonder if the bug is in MS-DOS?  I heard somebody say somewhere that
     [ ... ]
> 
> On the other hand, could it be that PCED is doing something funny with
> the stack?  It does bypass MS-DOS, so it's hard to guarantee that it
> will coexist with all generic MS-DOS software.
> -- 
> Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
> ----------

     Hmmm.  Come to think of it, the bug could be in PCED.  Originally, I
had set a breakpoint at the entry to main_handler(), and noticed that the
stack given to main_handler() was that of PCED.  I'll look into it more
this weekend.

     -- Darryl Okahata
	{hplabs!hpcea!, hpfcla!} hpsrla!darrylo
	CompuServe: 75206,3074

Disclaimer: the above is the author's personal opinion and is not the
opinion or policy of his employer or of the little green men that
have been following him all day.