Re: Redirecting stderr



"praetor.michael@xxxxxxxxx" <praetor.michael@xxxxxxxxx> writes:
On Feb 27, 4:02 pm, rober...@xxxxxxxxxxxxxxxxxx (Walter Roberson)
wrote:
In article <1172608859.551149.90...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
praetor.mich...@xxxxxxxxx <praetor.mich...@xxxxxxxxx> wrote:
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.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.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <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"
.



Relevant Pages

  • Re: Side-by-side installation on Windows 98SE and Windows 2000
    ... I was surprised to find that this is also supported on Windows 98 ... VB6 cannot create them. ... DLL Search algorithm explores at runtime. ... program (and it's libraries in the app folder) leaves behind a broken COM ...
    (microsoft.public.vb.general.discussion)
  • Re: Side-by-side installation on Windows 98SE and Windows 2000
    ... I was surprised to find that this is also supported on Windows 98 ... I think what it basically comes down to is that DLL/COM Redirection should only be used with COM component libraries that were designed to use it, and VB6 cannot create them. ... However assuming that is true would imply that by registering with a relative path means linkage will occur by using the paths that the Windows DLL Search algorithm explores at runtime. ...
    (microsoft.public.vb.general.discussion)
  • Re: How to get a .lib from .dll
    ... Using the Borland tools, you should first run "IMPDEF" on the DLL file ... information in it to create ".LIB" import libraries with;)... ... from Windows version to Windows version...so, ...
    (comp.lang.asm.x86)
  • Re: How to get a .lib from .dll
    ... Using the Borland tools, you should first run "IMPDEF" on the DLL file ... information in it to create ".LIB" import libraries with;)... ... from Windows version to Windows version...so, ...
    (alt.lang.asm)
  • Re: difference between a .dll and .ocx????
    ... Windows), then it must be a COM library since, that's the architecture ... it's a function that is called when the DLL ... class definitions or just function libraries is actually besides the ... about the .dll or .exe adhering to the COM standard. ...
    (microsoft.public.dotnet.framework)