Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!snorkelwacker!husc6!encore!pinocchio.encore.com
From: jkenton@pinocchio.encore.com (Jeff Kenton)
Newsgroups: comp.unix.i386
Subject: Re: floating point exception status not inherited by exec
Message-ID: <11453@encore.Encore.COM>
Date: 29 Mar 90 15:18:35 GMT
References: <3089@auspex.auspex.com>
Sender: news@Encore.COM
Lines: 34

From article <3089@auspex.auspex.com>, by guy@auspex.auspex.com (Guy Harris):
>>Hmm, I'm fairly sure that the "sticky bit" ordinarily refers to the bit in
>>the file permissions which causes an executable to hang around in
>>the swap space even when it's not in use.
> 
> I suspect he's referring to some other "sticky bit" (I seem to remember
> that some schemes for doing floating-point arithmetic have something
> called a "sticky bit").

Actually, I think there are 3 different "sticky bits".

	One is in the file protections, as described above.

	Another is used in rounding floating results, and is useful
	only internally to the FP unit during a single operation
	(or during FP exception processing on some machines, e.g., the 88000).

	The third is the accumulated set of FP exception bits which are sticky
	in the sense that they are set by the system hardware (or software)
	but usually not cleared except by the application program.

This last is probably what the original poster had problems with when he said
they were not preserved across exec() calls.  And, most likely, this is what
you should expect the kernel to do -- provide each new process with a clean
set of exception bits.  If you need to preserve these bits across process
creation you should pass them to the newly created process as an argument,
as someone else suggested.




- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      jeff kenton  ---	temporarily at jkenton@pinocchio.encore.com	 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -