Barry Schwarz <sc******@dqel. comwrites:
On Sat, 19 Jul 2008 20:45:05 -0700 (PDT), Isaac Gouy
<ig****@yahoo.c omwrote:
>>$ ./test_fail
1
Floating point exception
- but this leaves 'somefile' zero size
$ ./test_fail 1>somefile
Floating point exception
- and this leaves 'somefile' zero size
$ ./test_fail 2>somefile
1
Floating point exception
- why doesn't 'Floating point exception' go to stderr?
#include <stdio.h>
int main(){
printf("%d\n",1 );
printf("%d\n",2/0);
return 0;
}
Since there are no floating point objects and no floating point
operations in your code at all, you probably need to ask in a group
that discusses your system to determine why you are getting a floating
point exception.
What is the point of passing a command line argument to a program that
doesn't use it?
<OT>
He's not passing a command line argument to the program.
His command lines are:
./test_fail
which passes no arguments;
./test_fail 1>somefile
which passes no arguments and redirects stdout to "somefile" (the "1"
could have been omitted); and
./test_fail 2>somefile
which passes no arguments and redirects stderr to "somefile".
This is the correct syntax for the Bourne shell and shells derived
from it, such as ksh, bash, and zsh. The numbers 1 and 2 refer to the
file descriptor numbers corresponding to stdout and stderr,
respectively. There's no requirement for whitespace before or after
the ">", and it's common to omit it.
</OT>
So, his question is why the "Floating point exception" message still
appears when he redirects both stdout and stderr to a file.
The answer is system-specific. In this case, I think the message is
not part of the *program's* output; instead, it appears to be
generated by the shell, after the program has terminated. (A quick
experiment on a Linux system shows that the message doesn't appear if
the same program is invoked from a Perl script, implying that it's the
shell that prints the message.)
And yes, it's a bit odd that an integer division results in a
"Floating point exception" message, but since the C standard doesn't
define the behavior of division by zero, this is well within the
bounds of permitted behavior.
One plausible way this might happen is this:
The division caused the program to be killed by a SIGFPE signal.
This information was propagated to the invoking program (the
shell) in the status returned by system() (or whatever the shell
used to invoke the program). The shell responded by printing this
message to *its* stderr, which is not affected by the redirection
of the program's stderr.
--
Keith Thompson (The_Other_Keit h)
ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
