Redefine fprintf for debugging purposes

[Prayag Narula]

Hi,

I want to redefine fprintf for debugging purposes. That is I want that
all the output that is going to the stdout should be logged in a
file.

I tried something like
#define fprintf (x,y,z) my_fprintf(x,y, z)

and the compiler gave about 100 errors. Can anyone help me with this.
I have even tried using variadic macros but it seems too complicated.
Can anyone just help with such a defination.

Thanks and Regards,
Prayag Narula

[santosh]

Prayag Narula wrote:

Hi,

I want to redefine fprintf for debugging purposes. That is I want that
all the output that is going to the stdout should be logged in a
file.

<snip>

You cannot portably redefine Standard library functions and symbols. fprintf
takes a FILE * argument. Why do you feel that must be stdout. Just pass it
a FILE * set to a file, presumably opened by fopen.

FILE *log;
if((log = fopen("filename ", "a")) == NULL) { deal_with_error (); }
/* ... */
if(fprintf(log, "format string", ...) < 0) { deal_with_error (); }

[Manish Tomar]

On Jul 23, 1:23 pm, Prayag Narula <prayag.nar...@ gmail.comwrote:

#define fprintf (x,y,z) my_fprintf(x,y, z)

If there is space between fprintf & (x,y,z) that could be the reason
for those errors. You need to have it without space "fprintf(x,y,z) ".
Even better would be "#define fprintf my_fprintf" if x y z remain same
which I think is highly unlikely as u would be changing replacing
stdout with your file pointer.

I feel using variadic macros fit better in your scenario as fprintf
has variable arguments. I would to thank you to introduce me this
concept as was looking for something like this for a long time.. :)

[Fred Kleinschmidt]

"Prayag Narula" <pr***********@ gmail.comwrote in message
news:11******** **************@ i38g2000prf.goo glegroups.com.. .

Hi,

I want to redefine fprintf for debugging purposes. That is I want that
all the output that is going to the stdout should be logged in a
file.

I tried something like
#define fprintf (x,y,z) my_fprintf(x,y, z)

and the compiler gave about 100 errors. Can anyone help me with this.
I have even tried using variadic macros but it seems too complicated.
Can anyone just help with such a defination.

If all of your printing to stdout is done with:
fprintf( stdout, ...);
(that is, using fprintf rather than printf)
then it is really easy:

#ifdef DEBUG
#define OUTFILE myfile
#else
#define OUTFILE stdout
#endif

Then all print statements become:
fprintf( OUTFILE, ... );

Make sure you successfully open myfile before
any of the fprintf statements are executed.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Aero Stability and Controls Computing

[Prayag Narula]

>You cannot portably redefine Standard library functions and symbols. fprintf

>takes a FILE * argument. Why do you feel that must be stdout. Just pass it
a FILE * set to a file, presumably opened by fopen.

I do not want to redefine fprintf portably. Just for debugging
purposes. Thats why I need to use macros.Actually I am working on an
embedded device and cannot see the stdout. I want to define a macro
that redirects output from stdout to a file.

>fprintf
takes a FILE * argument. Why do you feel that must be stdout. Just pass it
a FILE * set to a file, presumably opened by fopen.

FILE *log;
if((log = fopen("filename ", "a")) == NULL) { deal_with_error (); }
/* ... */
if(fprintf(log , "format string", ...) < 0) { deal_with_error (); }

I cannot keep changing the function call at every call. Thats why a
macro.

>If there is space between fprintf & (x,y,z) that could be the reason
for those errors. You need to have it without space "fprintf(x,y,z) ".
Even better would be "#define fprintf my_fprintf" if x y z remain same
which I think is highly unlikely as u would be changing replacing
stdout with your file pointer

There is no space between fprintf and (x,y,z). My fault. I did not
copy paste the codes. :(

>I feel using variadic macros fit better in your scenario as fprintf
has variable arguments.

I have been fiddling around with variadic macros too. But the thing
is, the error messages I get are more than just too many or too few
parameters. For example:

undefined identifier 'NULL' in config.c
(this is being returned by fprintf, so something is going on with the
function that I wote)

I am not sure if this would be solved using variadic macros. But I
would try again with a full fledged rewritten fprintf.

>fprintf( stdout, ...);
(that is, using fprintf rather than printf)
then it is really easy:

#ifdef DEBUG
#define OUTFILE myfile
#else
#define OUTFILE stdout
#endif

Then all print statements become:
fprintf( OUTFILE, ... );

I do not want to change the code thats already written. But this
option would be my last resort if nothing else works out.

Looking forward to more comments.

Prayag Narula

[Nick Keighley]

On 24 Jul, 03:48, Prayag Narula <prayag.nar...@ gmail.comwrote:

please leave attributions in

You cannot portably redefine Standard library functions and symbols. fprintf
takes a FILE * argument. Why do you feel that must be stdout. Just pass it
a FILE * set to a file, presumably opened by fopen.

I do not want to redefine fprintf portably.

around here "portably" means "as defined by the C standard". This news
group
discusses standard C. So if you don't want to do it portably you're in
the wrong ng!

Just for debugging
purposes. Thats why I need to use macros.Actually I am working on an
embedded device and cannot see the stdout. I want to define a macro
that redirects output from stdout to a file.

fprintf
takes a FILE * argument. Why do you feel that must be stdout. Just pass it
a FILE * set to a file, presumably opened by fopen.

FILE *log;
if((log = fopen("filename ", "a")) == NULL) { deal_with_error (); }
/* ... */
if(fprintf(log, "format string", ...) < 0) { deal_with_error (); }

I cannot keep changing the function call at every call. Thats why a
macro

why not. With a decent editor that's dead easy. So globally replace
all

fprintf (stdout, ...

with

fprintf (LOG_STREAM, ...

then define LOG_STREAM depending where you are. What are you doing in
non-debug mode? It seems odd to me that your embedded device has files
but not standard out. Oh wait! is your embedded device a Windows
machine?
:-)
<snip>

--
Nick Keighley

[Prayag Narula]

On Jul 24, 5:58 pm, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

>
around here "portably" means "as defined by the C standard". This news
group
discusses standard C. So if you don't want to do it portably you're in
the wrong ng!

Ok ! As they say, "ma bad!" :)

>
why not. With a decent editor that's dead easy. So globally replace
all

fprintf (stdout, ...

with

fprintf (LOG_STREAM, ...

I still do not thing that its such a good idea. I have a feeling it is
bound to create more problems than it would solve.

then define LOG_STREAM depending where you are. What are you doing in
non-debug mode? It seems odd to me that your embedded device has files
but not standard out.

In non-debug mode, fprintf is being called with upto 5 parameters. It
does everything from creating html and js files to printing out error
messages. I am interested in these error messages that go to stdout.

>Oh wait! is your embedded device a Windows
machine?
:-)

:-D Its a Nokia s60 emulator. It has a pseudo terminal but it seems to
crash whenever there is a lot of output to stdout. Thats why I am
trying to log it.

Regards,
Prayag Narula

[Prayag Narula]

So basically, this is what I did.

<debug.h>
#ifndef __DEBUG_H__
#define __DEBUG_H__

#define fprintf(fp,...) my_fprintf(fp, __VA_ARGS__)

#endif

</debug.h>

<debug.c>
#include <stdio.h>
#include<string .h>
#include <stdarg.h>
#include "debug.h"

int my_fprintf(FILE *fo, ...)
{
va_list ap;
va_start(ap,fo) ;
FILE *fp;
char *buffer;
buffer = va_arg(ap,char* );
fp = fopen("log","a" );

//printf("%s %d",buffer,strl en(buffer));

if(fo == stdout || fo == stderr)
{
fp = fopen("log","a" );
if (fp == NULL)
return(-1);
if(fwrite(buffe r,sizeof(char), strlen(buffer), fp)0)
return(strlen(b uffer));
}
else
{
return (-1);
}
}
</debug.c>

Works in gcc but doesn't work in the embedded IDE. I guess, the
embedded compiler does not support variable arguments macro. Though it
definitely supports variable argument functions.

Though I am still testing.

Anyways, another option that I can think of is

#define fprintf(x,y) my_fprintf_1(x, y)
#define fprintf(x,y,z) my_fprintf_2(x, y,z)
....
and so on. A dirty way of doing this. What do you guys think ?

On Jul 24, 10:59 pm, Prayag Narula <prayag.nar...@ gmail.comwrote:

On Jul 24, 5:58 pm, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

around here "portably" means "as defined by the C standard". This news
group
discusses standard C. So if you don't want to do it portably you're in
the wrong ng!

Ok ! As they say, "ma bad!" :)

why not. With a decent editor that's dead easy. So globally replace
all

fprintf (stdout, ...

with

fprintf (LOG_STREAM, ...

I still do not thing that its such a good idea. I have a feeling it is
bound to create more problems than it would solve.

then define LOG_STREAM depending where you are. What are you doing in
non-debug mode? It seems odd to me that your embedded device has files
but not standard out.

In non-debug mode, fprintf is being called with upto 5 parameters. It
does everything from creating html and js files to printing out error
messages. I am interested in these error messages that go to stdout.

Oh wait! is your embedded device a Windows
machine?
:-)

:-D Its a Nokia s60 emulator. It has a pseudo terminal but it seems to
crash whenever there is a lot of output to stdout. Thats why I am
trying to log it.

Regards,
Prayag Narula

[Prayag Narula]

So basically, this is what I did.

<debug.h>
#ifndef __DEBUG_H__
#define __DEBUG_H__

#define fprintf(fp,...) my_fprintf(fp, __VA_ARGS__)

#endif

</debug.h>

<debug.c>
#include <stdio.h>
#include<string .h>
#include <stdarg.h>
#include "debug.h"

int my_fprintf(FILE *fo, ...)
{
va_list ap;
va_start(ap,fo) ;
FILE *fp;
char *buffer;
buffer = va_arg(ap,char* );
fp = fopen("log","a" );

//printf("%s %d",buffer,strl en(buffer));

if(fo == stdout || fo == stderr)
{
fp = fopen("log","a" );
if (fp == NULL)
return(-1);
if(fwrite(buffe r,sizeof(char), strlen(buffer), fp)0)
return(strlen(b uffer));
}
else
{
return (-1);
}
}
</debug.c>

Works in gcc but doesn't work in the embedded IDE. I guess, the
embedded compiler does not support variable arguments macro. Though it
definitely supports variable argument functions.

Though I am still testing.

Anyways, another option that I can think of is

#define fprintf(x,y) my_fprintf_1(x, y)
#define fprintf(x,y,z) my_fprintf_2(x, y,z)
....
and so on. A dirty way of doing this. What do you guys think ?

On Jul 24, 10:59 pm, Prayag Narula <prayag.nar...@ gmail.comwrote:

On Jul 24, 5:58 pm, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

around here "portably" means "as defined by the C standard". This news
group
discusses standard C. So if you don't want to do it portably you're in
the wrong ng!

Ok ! As they say, "ma bad!" :)

why not. With a decent editor that's dead easy. So globally replace
all

fprintf (stdout, ...

with

fprintf (LOG_STREAM, ...

I still do not thing that its such a good idea. I have a feeling it is
bound to create more problems than it would solve.

then define LOG_STREAM depending where you are. What are you doing in
non-debug mode? It seems odd to me that your embedded device has files
but not standard out.

In non-debug mode, fprintf is being called with upto 5 parameters. It
does everything from creating html and js files to printing out error
messages. I am interested in these error messages that go to stdout.

Oh wait! is your embedded device a Windows
machine?
:-)

:-D Its a Nokia s60 emulator. It has a pseudo terminal but it seems to
crash whenever there is a lot of output to stdout. Thats why I am
trying to log it.

Regards,
Prayag Narula

[Mark Bluemel]

Prayag Narula wrote:

On Jul 24, 5:58 pm, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

>>... With a decent editor that's dead easy. So globally replace
all

fprintf (stdout, ...

with

fprintf (LOG_STREAM, ...

[Replace something Prayag snipped

>then define LOG_STREAM depending where you are

I still do not thing that its such a good idea. I have a feeling it is
bound to create more problems than it would solve.

It's a fairly obvious solution to your problem. What problems do you
foresee?