* exceptions.cc (ctrl_c_handler): Send SIGHUP when events occur only if there

is a tty associated with the process.  Send SIGHUP on CTRL_LOGOFF_EVENT.
* fhandler_tty.cc (fhandler_tty_slave::open): Adjust console open handle
counter regardless of whether this is a pty or tty.
(fhandler_tty_slave::open): Ditto.
(fhandler_tty_slave::dup): Ditto.
(fhandler_tty_common::set_close_on_exec): Ditto.
(fhandler_tty_master::init_console): Decrement console open handle counter
after init since it will now be handled by all tty open.
* syscalls.cc (setsid): Rework debugging output slightly.

1 files changed, 11 insertions, 11 deletions

diff --git a/winsup/cygwin/ipc.cc b/winsup/cygwin/ipc.cc
index d37f45947..c89b23e21 100644
--- a/winsup/cygwin/ipc.cc
+++ b/winsup/cygwin/ipc.cc
@@ -35,45 +35,45 @@ ftok (const char *path, int id)
      We will have to alias; leaving open the possibility that the same
      key will be returned for multiple files.  This possibility exists
      also on Linux; the question is, how to minimize this possibility.
-    
+
      How to solve?  Well, based on C. Vinschen's research, the nFileIndex*
      words vary as follows, on a partition with > 110,000 files
      nFileIndexHigh:    564 values between 0x00010000 -- 0xffff0000
      nFileIndexLow : 103812 values between 0x00000000 -- 0x0003ffff
-     R. Collins suggests that these may represent a tree path, 
+     R. Collins suggests that these may represent a tree path,
      and that it would require ~2.9M files to force the tree depth
      to increase and reveal more bit usage.
-    
+
      Implementation details: dev_t is 32bits, but is formed by
-        device(32bits) << 16 | unit(32bits)
+	device(32bits) << 16 | unit(32bits)
      But device is ACTUALLY == status & FH_DEVMASK, where FH_DEVMASK
      is 0x00000fff --> 12 bits
-    
-     As it happens, the maximum number of devices is actually 
+
+     As it happens, the maximum number of devices is actually
      FH_NDEV, not FH_DEVMASK, where FH_NDEV is currently 0x0000001d.
      However, FH_NDEV grows as new device types are added.  So
      currently the device number needs 5 bits, but later?  Let's
      take a cue from Linux, and use the lower 8 bits (instead of the
      lower 12 or 16) for the device (major?) number.
-    
+
      Similarly, while 'units' is an int (32bits), it is unclear
      how many of these are significant. For most devices, it seems that
      'units' is equivalent to 'minor'.  For FH_TAPE, it's obvious that
      only 8 bits are important.  However, for FH_SOCKET...it might be
      as high as 16 significant bits.
-    
+
      Let's assume that we only need 8 bits from device (major) and
      only 8 bits from unit (minor). (On linux, only 8 bits of minor
      are used, and none from major).
      ---> so, we only need 0x00ff00ff (16 bits) of dev_t
-    
+
      ---> we MUST have all 8 bits of id.
-    
+
      ---> So, we only have 64 - 8 - 16 = 40 bits for ino_t.  But, we
      need 0xffff0000 for nFileIndexHigh and 0x0003ffff for nFileIndexLow
      minimum, or 16 + 18 = 34 bits.  Lucky us - we have 6 more bits
      to distribute.
-    
+
      For lack of a better idea, we'll allocate 2 of the extra bits to
      nFileIndexHigh and 4 to nFileIndexLow.  */