Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!think!ames!aurora!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: <3320049@hpsrlc.HP.COM>
Date: Mon, 31-Aug-87 11:29:38 EDT
Article-I.D.: hpsrlc.3320049
Posted: Mon Aug 31 11:29:38 1987
Date-Received: Sat, 5-Sep-87 01:52:56 EDT
References: <1009@bsu-cs.UUCP>
Organization: Network Measurements Div - Santa Rosa, CA
Lines: 49

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

> In article <2670002@hpsrla.HP.COM> darrylo@hpsrla.HP.COM (Darryl Okahata) 
> writes about my signal() for Turbo C:
> >     Thanks to Rahul Dhesi for writing this!  However, there are little
> >"gotchas" that one has to be careful of:
> >
> >     1. Any routine called through the handler set up by the ctrlbreak()
> >	call uses the stack given to it by DOS.  The handler does not set
> >	up a stack before calling the specified routine.  It *appears* that
> >	the stack used is the one that was being used when the DOS function
> >	that was called was interrupted.
> 
> When I tested the signal() handler code, I did run out of stack space.
> Then I initialized _stklen to a bigger value and the program ran
> correctly.  So any shortage of stack space is occurring simply because
> the Turbo C stack is not big enough.  The default stack, if you don't
> create _stklen, is only 128 bytes, which is peanuts.

     [ ... ]

> To set up the stack (this is not given in the Turbo C manual but was on
> Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
> ----------

     When main_handler() is entered, the stack that the routine uses MAY
NOT be that of the Turbo C program.  With Chris Dunford's PCED (a TSR)
loaded, I'm using a Turbo C routine to read a line from the console via DOS
function 0x09 or 0x0a (I can't remember which -- it is the function to read
a complete line from the console).  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.  I don't
know any easy way around this.  In fact, the only way that I can think of
to get around this is to write a short assembly routine to set up a local
playground (stack) before calling main_handler().  Of course, the problem
with this is that main_handler() will have to eventually return.

     -- 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.