"pr************ *@gmail.com" <pr************ *@gmail.comwrit es:
On Feb 27, 4:02 pm, rober...@ibd.nr c-cnrc.gc.ca (Walter Roberson)
wrote:
>In article <1172608859.551 149.90...@q2g20 00cwa.googlegro ups.com>,
praetor.mich.. .@gmail.com <praetor.mich.. .@gmail.comwrot e:
>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.
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.program mer.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.
--
Keith Thompson (The_Other_Keit h)
ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
