Accessing program's own stdout/stderr

[wysota]

If you write to your own stdout (as I assume the application does), you can't read it back in. You have to substitute stdout and stderr with some mechanisms that will redirect the data elsewhere. Otherwise you have to modify all calls to printf() and fprintf() in the original code to send the data to some other place. You should be able to simply undef printf and define a new function or macro with this name and then rebuild the application.

[TemporalBeing]

Thanks for the tip on stderr/stdout. Never came across that before, but I haven't tried to port legacy code this way before either.

Well, for various reasons I can't get it to work on Linux well enough to even compile (legacy code issues).

I did try replacing stderr, stdout but that didn't work either. (And I've done that in the past and had it work too, but not under Qt.)

So I finally broke down and replaced all the printf/fprintf(stderr) calls with a new function that converts the stuff to QString, and then calls qDebug(), which is then captured via a handler to be redirected to the GUI location I want it to go.

Problem is that the _vsnprintf() in VS2008/Qt4.5.1 seems to be borked - it never prints the text to the buffer, despite having a 32k buffer and data that is no where near 32k in size (likely 80 characters in size at most). It does set the buffer to all spaces, with proper termination; but no data.

I originally pulled some code I had written to add 'printf()' style formatting to the std::string class that managed some dynamic memory to do the conversion with _vsnprintf(), but it just kept allocating memory and never actually writing anything. (And I know the function worked when I wrote and tested it!)

So needless to say, I have to go on to other things for now, but I really want to resolve this issue - and I'm just plain out of ideas right now.

[wysota]

Can't you undef _vsnprintf() and replace it with your own routine? At worst just reassign the function pointer to something else, it should be doable.

[TemporalBeing]

And that would require writing something to interpret the whole printf format strings, which I'd rather not do - not to mention, I don't have time for it. vsnprintf/_vsnprintf are great functions, and there's no reason they should be failing like this. Not sure what I'm going to do about it though...