Mail Archives: djgpp/1999/02/01/14:24:29
> -- Is there a #define that will distinguish DJGPP 2.02 and later
> versions from earlier versions? Not critically important.
__DJGPP_MINOR__ is 2 for 2.02. You should include stdio.h to make
sure you have the correct version - there's a new header that resets
it if you have an older gcc (with 2.01 coded in its specs file), and
this new header (which stdio.h in 2.02 happens to include, just for
this purpose) redefines it.
> -- 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. Like, does it OR with the 'new control word' and
> AND with the 'mask' or what, precisely? The mailing list
> archives did not answer this. This IS important!
If a given bit is set in the mask, that bit of the control word
is changed to match the "new control word". Other bits in the control
word are not changed. I.e.:
new = (old & ~mask) | (new & mask)
> -- 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?
Maybe and no.
> -- Non-GCC DOS and Windows compilers -- How do these manage
> FPU exceptions?
Depends, but most of those do have _control87(). At least, Borland
does. MS may do something incompatible here.
> -- How are FPU exceptions managed under Linux using GCC, or
> using other compilers?
With signals. It's handled in the kernel, not your program. I don't
know what the defaults are or how to change them.
> 2. The signal handling mechanism for setting signal handlers and
> the like is uniform among POSIX-compliant development
> environments right?
Yes, but few implementations are truly POSIX compliant.
> 3. Is there a standard C/C++ library function to launch an external
> app synchronously regardless of whether the OS has multitasking
> support?
system()
> 4. Is there a way to launch a child program and capture stderr
> from it, but not stdout? (I assume yes since the DJ util redir
> must do it.) Is there such a method that is uniform across
> many operating systems?
Not portably. In djgpp, you must dup() your stderr to a new handle
(to save it), dup2() the new stderr to where you want, system() the
program, and dup2() your saved stderr back.
> 5. What happens to a DJGPP app if it launches a child that catches
> a fatal signal, e.g. SIGSEGV? Is there a way to ensure that
> the launching app stays stable and perceives it as the child
> returning errorlevel 255? How does this translate to Linux
> and other protected mode environments?
The parent app gets an error return, but I don't recall exactly how it
is returned. A simple test program would tell you.
On unix-like environments, wait() returns a different status for
failed programs vs crashed programs.
- Raw text -