Feature request: Our Keil C166 compiler does not make a distinction between standard output or standard error. It would be nice if error/warning messages would be displayed on standard error. This make it easier to redirect output, handle logging in our build environment, etc. Seems like a simple file descriptor adjustment and existing users/tools won't notice the difference.
I'm not sure if the latest version (6.x) supports this already.
Kind rergards, Joost Leeuwesteijn
But surely, as far as the compiler is concerned, compilation messages (warnings, errors, etc) are its standard output - so they should go to stdout?!
If anything should go to stderr, it would be messages about failures of the compiler itself?
Then at least compilation errors are failures of the compiler itself, it can't handle the source file. But I understand what you mean. What kind of failures do you mean exactly?
I believe most UNIX tools send their error messages ("file not found", etc.) to stderr, not just their internal errors or core dumps. I expected the Keil compiler to behave the same way. I redirected the compiler startup messages etc. (stdout) but I expected to still see the warnings/error but that doesn't happen.
Quick test on Windows (cmd.exe):
C:\> dir burp > log.txt File Not Found C:\> _
So "dir" also sends errors to stderr.
What do native UNIX compilers do?
(Thanks Perg for the gcc answer.)
Regards, Joost Leeuwesteijn
My opinion is that compilation errors and warnings are the normal output of a compiler, so they should go to stdout. stderr would be appropriate for internal compiler problems, like running out of RAM.
If you do a huge compilation with houndreds or thousands of source files, you might actually like a compiler that sends warnings and errors to stderr, allowing you to just use redirect to separate the warnings/errors from the normal build noise.
When using c++ with templates, a lot of warnings/errors messages may be several lines long, making it hard to just use grep to pick out interesting warnings.