Redirecting stderr

[praetor.michael]

I have a DLL written in C that writes to stderr. I have a win32
console application that makes calls to the DLL. In the console app I
redirect stderr to a file using freopen. The problem I'm having is
that none of the messages sent to stderr from the DLL are getting
written to the file but if I write to stderr from the console
application it gets written to the file no problem. Any ideas??

 

[Bill Pursell]

I have a DLL written in C that writes to stderr. I have a win32
console application that makes calls to the DLL. In the console app I
redirect stderr to a file using freopen. The problem I'm having is
that none of the messages sent to stderr from the DLL are getting
written to the file but if I write to stderr from the console
application it gets written to the file no problem. Any ideas??

Several ideas:

1) Ask in an appropriate newsgroup.
2) Library functions should not write to the stderr
stream. You should consider redesigning them.
3) When you follow the advice given in #1, give
more details.

 

[Walter Roberson]

I have a DLL written in C that writes to stderr. I have a win32
console application that makes calls to the DLL. In the console app I
redirect stderr to a file using freopen. The problem I'm having is
that none of the messages sent to stderr from the DLL are getting
written to the file but if I write to stderr from the console
application it gets written to the file no problem. Any ideas??

That sounds like a question more appropriate for a Windows
programming newsgroup. In this newsgroup, comp.lang.c, we can
tell you about how freopen() is supposed to work, but interactions
with system routines such as DLLs are beyond the scope of the C
language itself.

 

[praetor.michael]

That sounds like a question more appropriate for a Windows
programming newsgroup. In this newsgroup, comp.lang.c, we can
tell you about how freopen() is supposed to work, but interactions
with system routines such as DLLs are beyond the scope of the C
language itself.

It actually works the same on either platforms. The code was designed
to work on windows and all unix flavors. Which is why I posted it
here.

As for the library code not writing to stderr where do you suggest an
error message get printed to?? That's the whole point of the sterr
stream.

As for your comment (Bill) on more details, what more do you want??

 

[Ian Collins]

*Please trim signatures!*

It actually works the same on either platforms. The code was designed
to work on windows and all unix flavors. Which is why I posted it
here.

You didn't post any code. As soon as people see 'DLL' their platform
specific auto responders kick in!

Post an example if you can.

 

[Walter Roberson]

It actually works the same on either platforms. The code was designed
to work on windows and all unix flavors. Which is why I posted it
here.

That's bogus. There's no DLL support in the Unix version I use,
and it is one of the few officially certified Unix releases.
If you search opengroup.org (official certifiers of Unix),
you will find that the DLL references are all platform specific.

Whatever it is you are using is *not* part of standard C -- and
if it is called "DLL", it is not even part of standard Unix,
nor POSIX. If the code uses DLLs on Windows and shared libraries
on the POSIX-compatible Unix systems, then it it is using something
platform specific, not part of the C language.



Note, by the way, the official opengroup definition of dlopen()
http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html

The dlopen() function shall make an executable object file
specified by file available to the calling program. The class of
files eligible for this operation and the manner of their
construction are implementation-defined, though typically such
files are executable objects such as shared libraries,
relocatable files, or programs.

Notice the lack of reference to DLL. That is not an accident:
C doesn't have them and POSIX doesn't have them either.

 

[Keith Thompson]

Please don't quote signatures. Trim quoted material to what's
necessary for your followup to make sense to someone who hasn't read
the parent article.

It actually works the same on either platforms. The code was designed
to work on windows and all unix flavors. Which is why I posted it
here.

Windows and Unix are just two out of many platforms. DLLs, I believe,
are specific to Windows; Unix has something similar (shared
libraries). Neither feature is defined by standard C, which is what
we discuss here.

If you post to a Windows-specific group, perhaps
comp.os.ms-windows.programmer.win32 or one of the microsoft.* groups,
they can help you with your DLL issues; whatever solution you get
there may or may not be applicable to Unix (or to any other system).

As for the library code not writing to stderr where do you suggest an
error message get printed to?? That's the whole point of the sterr
stream.

Generally, printing error messages should be up to the program that
uses a library, not the library itself. A library routine, if it's to
be generally useful, should probably return information to the caller
indicating whether there was an error; it's up to the application to
decide what to do with that information.

For example, the standard fopen() function is part of the standard C
library. If it fails, it doesn't print an error message; it returns a
null pointer to let the caller know that it failed. (On some systems,
it may also set errno to provide more information about the failure.)

Imagine a version of fopen() that prints a message on any error, and
imagine a program that wants to open "foo.txt" if it exists, otherwise
"bar.txt":

/* ... */
FILE *f;
f = fopen("foo.txt", "r");
if (f == NULL) {
f = fopen("bar.txt", "r");
}
/* ... */

Failure to open "foo.txt" isn't an error as far as the program is
concerned, and the program knows that no error message is needed.
This hypothetical fopen() would just annoy the user with spurious
error messages.

As for your comment (Bill) on more details, what more do you want??

Complete, compilable sources for the program would be a good start.
Trim the program down to the minimum that exhibits the problem. If
the stripped version of the program is over, say, 100 lines or so,
consider posting a link to the source rather than the source itself.
And since your program depends on features that go beyond standard C,
you'll need to do this in some other newsgroup.

 

[Richard Heathfield]

Keith Thompson said:

DLLs, I believe,
are specific to Windows;

Nah - mainframes had DLLs when Windows was still just a gleam in Bill
Gates's wallet.

 

[Keith Thompson]

Keith Thompson said:


Nah - mainframes had DLLs when Windows was still just a gleam in Bill
Gates's wallet.

Ok, so they're specific to Windows *and* to mainframes. Or something.

(<OT>I *finally* got around to updating my sig.</OT>)

 

[Malcolm McLean]

I have a DLL written in C that writes to stderr. I have a win32
console application that makes calls to the DLL. In the console app I
redirect stderr to a file using freopen. The problem I'm having is
that none of the messages sent to stderr from the DLL are getting
written to the file but if I write to stderr from the console
application it gets written to the file no problem. Any ideas??

The standard input and output streams have been vandalised in MSVC++.
My solution to this problem is to knock up a console and provide the
function Con_Printf(), which allows output for debug prurposes. It can even
be used in production runs in certain circumstances.

I can send you the code on request.

 

[Keith Thompson]

The standard input and output streams have been vandalised in MSVC++.
My solution to this problem is to knock up a console and provide the
function Con_Printf(), which allows output for debug prurposes. It can
even be used in production runs in certain circumstances.

"Vandalised"? How so? (I claim this is at least marginally topical
if it pertains to whether MSVC++ is a conforming hosted C
implementation.)

 

[Richard Heathfield]

Keith Thompson said:

(<OT>I *finally* got around to updating my sig.</OT>)

Oh, well played, sir!

 

[Richard Heathfield]

Keith Thompson said:

[...] whether MSVC++ is a conforming hosted C implementation.)

In console mode, it is a conforming hosted C implementation - modulo
tiny bugs in dark corners of the language, such as have been reported
once or twice in this newsgroup.

In GUI mode, AFAICT it is a conforming *freestanding* implementation.
The freestandingness can be deduced trivially from the fact that the
entry point in GUI mode is WinMain rather than main. IIRC freestanding
implementations are not required to provide a stderr at all.

 

[CBFalconer]

I have a DLL written in C that writes to stderr. I have a win32
console application that makes calls to the DLL. In the console app I
redirect stderr to a file using freopen. The problem I'm having is
that none of the messages sent to stderr from the DLL are getting
written to the file but if I write to stderr from the console
application it gets written to the file no problem. Any ideas??

What is a DLL? What is a "win32 console application"? None of
these are mentioned anywhere in the C standard. I.E. you are off
topic here, and should go to some newsgroup that discusses your
peculiar system. I suspect the group name may include "windows".

 

[Kenneth Brody]

I have a DLL written in C that writes to stderr. I have a win32
console application that makes calls to the DLL. In the console app I
redirect stderr to a file using freopen. The problem I'm having is
that none of the messages sent to stderr from the DLL are getting
written to the file but if I write to stderr from the console
application it gets written to the file no problem. Any ideas??

Windows specificalities aside...

How do you know that the library you are calling actually uses the
stream pointed to by stderr?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Malcolm McLean]

"Vandalised"? How so? (I claim this is at least marginally topical
if it pertains to whether MSVC++ is a conforming hosted C
implementation.)

Put a printf() somewhere into an MSVC program. It ought to compile and link
without complaining. Then you will find that your output simply vanishes. I
presume there is some way of capturing it, but I have never worked out how
to do it.

Vandalism is damage inflicted either pointlessly or for the sake of social
posturing, that falls short of total destruction of the object. I'd say the
treatment of stdio qualifies.

 

[praetor.michael]

Windows specificalities aside...

How do you know that the library you are calling actually uses the
stream pointed to by stderr?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody |www.hvcomputer.com| #include |
| kenbrody/at\spamcop.net |www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

good question... i was under the impression that there was only one
stderr stream... correct me if i'm wrong though...
if there is more than one stderr stream then how would you go about
redirecting it??
would a function inside the library that returned the handle be the
(quick and dirty) solution?

-M

 

[Kenneth Brody]

I have a DLL written in C that writes to stderr. I have a win32

[...]

Windows specificalities aside...

How do you know that the library you are calling actually uses the
stream pointed to by stderr?

good question... i was under the impression that there was only one
stderr stream... correct me if i'm wrong though...

There is only one "stderr", but who says that the library is using
"stderr" as the stream?

However, there are Windows-specific file handles which are not
necessarily the ones pointed to by "stderr". If the library is
using Windows-specific API calls to access Windows-specific file
handles, then you will need a Windows-specific answer from a
Windows-specific newsgroup. (Hint -- if you have access to the
library source, look for calls to GetStdHandle.)

However, unless you have access to the library source, or can get
an answer to the question of "how does the library send its output"
by other means, you can only guess.

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[praetor.michael]

:
I have a DLL written in C that writes to stderr. I have a win32

[...]

Windows specificalities aside...
How do you know that the library you are calling actually uses the
stream pointed to by stderr?

good question... i was under the impression that there was only one
stderr stream... correct me if i'm wrong though...

There is only one "stderr", but who says that the library is using
"stderr" as the stream?

However, there are Windows-specific file handles which are not
necessarily the ones pointed to by "stderr". If the library is
using Windows-specific API calls to access Windows-specific file
handles, then you will need a Windows-specific answer from a
Windows-specific newsgroup. (Hint -- if you have access to the
library source, look for calls to GetStdHandle.)

However, unless you have access to the library source, or can get
an answer to the question of "how does the library send its output"
by other means, you can only guess.

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody |www.hvcomputer.com| #include |
| kenbrody/at\spamcop.net |www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

I wrote the library and I have the source and I know that it prints to
stderr because the messages are being sent in the following line of
code:

fprintf( stderr, "Error...) );

So since that is the case and there is only one stderr stream then why
aren't the messages from the library being sent to the file when I
redirect the stderr stream to a file using the following line of code:

freopen( "stderr.txt", "w", stderr );

That clear up things abit??