Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!boulder!hao!oddjob!gargoyle!ihnp4!inuxc!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: signal() for Turbo C
Message-ID: <1080@bsu-cs.UUCP>
Date: Wed, 2-Sep-87 01:05:20 EDT
Article-I.D.: bsu-cs.1080
Posted: Wed Sep  2 01:05:20 1987
Date-Received: Fri, 4-Sep-87 00:49:34 EDT
References: <1009@bsu-cs.UUCP> <3320049@hpsrlc.HP.COM>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 36

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.

I looked at Microsoft's official guide to MS-DOS, written by Ray
Duncan.  The description for the control-C trapping system call, which
Turbo C's ctrlbrk() function must be using, says nothing about which
stack is used.  Can anybody check any other documentation about this?

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
imply that the control-C handler is not executing on an interrupt
stack, but is using the original application program's stack.  This
would be consistent with Microsoft attempting (albeit rather weakly) to
provide facilities similar to those provided by UNIX.

I wonder if the bug is in MS-DOS?  I heard somebody say somewhere that
the signal() function provided by one of the C compilers (Lattice's or
Microsoft's) uses some undocumented features of MS-DOS.  Why would it
do so, unless it were necessary?  Why would it be necessary, if MS-DOS
sets up the stack correctly before passing control to the handler?

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