runtime error to stderr or ? (gcc ubuntu bash)

[Isaac Gouy]

$ ./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;
}

 

[Barry Schwarz]

$ ./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?


Remove del for email

 

[rahul]

What is the point of passing a command line argument to a program that
doesn't use it?

Isaac,
He meas to say that ./test_fail 2>somefile does not do the redirection
but passes 2>somefile as an argument. What you needed was ./test_fail
2> somefile. And of course, you should not be getting FPE as there are
no floating points. Further, in C99, 2/0.0 or 2.0/0 or 2.0/0.0 should
be yielding inf.

 

[Chris Torek]

$ ./test_fail 2>somefile
1
Floating point exception
- why doesn't 'Floating point exception' go to stderr?

There is no requirement that any internal diagnostics printed by
the C runtime system go anywhere in particular (perhaps they might
go to a system log, for instance). This is an example of "undefined
behavior": the C Standard imposes no requirements, so any system
can do whatever it wants.

<off-topic>
In this particular case, the reason that the string "Floating point
exception" is not redirected is that it is not produced by the
process that runs ./test_fail or anything that it invokes. Instead,
it is being produced by the command-interpreter itself.

You can see this by telling the command interpreter to
run another command interpreter, redirecting this sub-interpreter's
error output. However, a bit of a trick is required:

$ bash -c './test_fail; true' >out 2>err
$ cat out
$ cat err
bash: line 1: 28106 Floating point exception./test_fail
$

The "; true" is required, at least on my Linux box. (Actually
any command should suffice.)
</off-topic>

 

[Ben Bacarisse]

$ ./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?

For the full story (I don't know it) ask in comp.unix.programmer but
the short one is that that message is not coming from your program.

 

[Isaac Gouy]

Thank you all.

- on my systems, actually this /does/ do redirection

$ ./test_fail 1>somefile

There is no requirement that any internal diagnostics printed by
the C runtime system go anywhere in particular (perhaps they might
go to a system log, for instance). This is an example of "undefined
behavior": the C Standard imposes no requirements, so any system
can do whatever it wants.

That's what I needed to know, thanks.

And of course, you should not be getting FPE as there are
no floating points. Further, in C99, 2/0.0 or 2.0/0 or 2.0/0.0 should
be yielding inf.

In this particular case, the reason that the string "Floating point
exception" is not redirected is that it is not produced by the
process that runs ./test_fail or anything that it invokes. Instead,
it is being produced by the command-interpreter itself.

I suppose we could speculate that the command-interpreter is failing
to handle inf.


Incidentally, I was using test_fail to check that a script was
correctly capturing stderr from another process and just couldn't
figure out what was wrong with the script - when of course there
wasn't anything on stderr for the script to show

 

[Richard Tobin]

In this particular case, the reason that the string "Floating point
exception" is not redirected is that it is not produced by the
process that runs ./test_fail or anything that it invokes. Instead,
it is being produced by the command-interpreter itself.

[/QUOTE]

I suppose we could speculate that the command-interpreter is failing
to handle inf.

The command interpreter doesn't handle the value at all. Dividing by
zero produces undefined behaviour: on your system, the behaviour is
that the program gets a "floating point exception" signal (even though
there is no floating point involved). The command interpreter
recognises that the program exited because of that signal, and prints
out the message.

-- Richard

 

[Barry Schwarz]

Isaac,
He meas to say that ./test_fail 2>somefile does not do the redirection
but passes 2>somefile as an argument. What you needed was ./test_fail
2> somefile. And of course, you should not be getting FPE as there are
no floating points. Further, in C99, 2/0.0 or 2.0/0 or 2.0/0.0 should
be yielding inf.

No, I have no idea if his shell is smart enough to take the > as a
token or not. However, regardless, he is passing a command line
argument (either "2" or "2>somefile") and his program makes no attempt
to process it.


Remove del for email

 

[Ben Bacarisse]

No, I have no idea if his shell is smart enough to take the > as a
token or not. However, regardless, he is passing a command line
argument (either "2" or "2>somefile") and his program makes no attempt
to process it.

There is nothing for the program to process. argc will be 1 in all
the cases shown.

 

[Keith Thompson]

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.

 

[Antoninus Twink]

The "; true" is required, at least on my Linux box. (Actually any
command should suffice.)

I believe : is the conventional shell NOP?