Mail Archives: djgpp/1999/02/01/02:31:40
On Mon, 1 Feb 1999, Paul Derbyshire wrote:
> I have several questions regarding signals. A search of the faq, info
> files, website, and archive only partially answered these.
You should have asked more specific questions, based on what the
available docs *does* cover. It is very hard to supply the specific
information you found missing when you don't say what it is, and it is
impossible to explain it all here.
It is also best to not lump several broad questions into a single
message.
> -- Is there a #define that will distinguish DJGPP 2.02 and later
> versions from earlier versions?
__DJGPP_MINOR__ is set to the minor version number of DJGPP (2 for v2.02,
1 for v2.01). See FAQ section 8.6.
> -- In pre-2.02, FPU exceptions are masked using _control87.
> The info files show _control87 accepting two unsigned ints, one
> called a 'new control word' the other a 'mask'. It isn't
> made clear, however, how the _control87 combines these with the
> FPU state.
Here's what the docs says:
`_control87' uses the value of NEWCW and MASK variables together to
determine which bits of the FPU's control word should be set, and to
what values. For each bit in MASK that is set (equals to 1), the
corresponding bit in NEWCW specifies the new value of the same bit in
the FPU's control word, which `_control87' should set. Bits which
correspond to reset (zero) bits in MASK are not changed in the FPU's
control word.
Now, what exactly is unclear here? I think that, short of showing the
exact C lines from the source of `_control87' (which, btw, is free to be
examined), this describes *exactly* how the mask and the new control word
are combined to produce the word that's loaded into the FPU.
> -- Do other Intel arch GCC development environments (Cygnus,
> etc.) behave consistently about the FPU? Do all support
> a _control87 in float.h with the exact same syntax and
> semantics?
`_control87' is compatible with Borland. I don't know whether other
environments provide it, but I don't suggest to count on that.
As for behaving ``consistently about the FPU'', please explain what
aspects did you have in mind.
> -- Non-GCC DOS and Windows compilers -- How do these manage
> FPU exceptions?
> -- How are FPU exceptions managed under Linux using GCC, or
> using other compilers?
> -- How do other CPU architectures manage FPU exceptions?
I don't know how to begin answering these questions; they are too broad.
In general, floating-point behavior differs quite a lot between different
environments. ANSI requires that library functions don't cause the
program to crash, but even that requirement doesn't always hold.
> 2. The signal handling mechanism for setting signal handlers and
> the like is uniform among POSIX-compliant development
> environments right?
Of course, it isn't! The overall framework is the same, and as long as
you stick to what ANSI allows you to do inside a signal handler (which is
very little), you are relatively safe, but other than that--you are on
your own.
Usually, the signal-handling code in any portable program, even if it's
portable to Unix platforms only, is one of the most infested by #ifdef's
and such likes.
> 3. Is there a standard C/C++ library function to launch an external
> app synchronously regardless of whether the OS has multitasking
> support?
If you don't mind that function to fail where async subprocesses aren't
supported, then that function is called `fork'. ;-)
Seriously, though, what do you expect such a function to do when the
underlying OS doesn't support multiprogramming?
> 4. Is there a way to launch a child program and capture stderr
> from it, but not stdout?
You have to redirect the stream. Use `dup' and `dup2' functions to do
that.
> (I assume yes since the DJ util redir
> must do it.)
Right, so you could have simply looked at the sources of `redir'...
> Is there such a method that is uniform across
> many operating systems?
`dup' and `dup2' are Posix functions.
> 5. What happens to a DJGPP app if it launches a child that catches
> a fatal signal, e.g. SIGSEGV?
For SIGSEGV, nothing happens to the parent. SIGINT and SIGQUIT are
delivered to the parent as well, and SIGFPE might be as well, depending
on how badly is the FPU trashed.
> Is there a way to ensure that
> the launching app stays stable and perceives it as the child
> returning errorlevel 255?
A parent program that doesn't want to hear about the child's signals
should set all signal handlers to SIG_IGN, or use the `sigprocmask'
function to mask them temporarily, depending on the application's needs.
Then when the child returns, the original signal handlers should be
restored.
DJGPP's default signal handlers make sure the program returns -1 (i.e.
255) exit status, but if the child program installed its own signal
handler that returns anything else, you have no means to force it to
return 255.
> How does this translate to Linux
> and other protected mode environments?
On Unix, signals are generally delivered to the parent. Originally, it
was planned to do the same for DJGPP v2.x, but it never got implemented,
so we are left with the situation where only some signals are passed to
the parent(s).
- Raw text -