implement my own lib function fprintf --- Segmentation Fault

[eliweiq001]

I am trying to implement my own lib function fprintf, but there's some
problem.
the function is
int fprintf(FILE *fp, char *fmt, ...)
{
........
}



when I call fprintf(fp, "%sabc", "efg"), it is OK.
but when I call fprintf(fp, "abc") there will be Segmentation fault ,
same as fprintf(fp, "%s", "abc").

I am using gcc, the error will occur in both linux and windows.
I think there no problem with my function fprintf.
I've wrote a basic version of fprintf below which will also cause the
same error:







// test for fprintf;

typedef int FILE; // just for testing, so
make FILE as INT
FILE *fp;
//fp = 0;

int fprintf(FILE *fp, char *fmt, ...) // the basic version of
fprintf, for testing
{
return 0;
}

int main(int argc, char *argv[])
{
fprintf(fp, "%sz", "aa"); // It's OK
fprintf(fp, "%s", "aa"); // Segmentation Fault ! Why?
fprintf(fp, "aa"); // Segmentation Fault !
return 0;
}



Will these codes cause Segmentation fault in your environment? (please
let me know your compiler and operating system)

 

[eliweiq001]

I am trying to implement my own lib function fprintf, but there's some
problem.
the function is
int fprintf(FILE *fp, char *fmt, ...)
{
.......

}

when I call fprintf(fp, "%sabc", "efg"), it is OK.
but when I call fprintf(fp, "abc") there will be Segmentation fault ,
same as fprintf(fp, "%s", "abc").

I am using gcc, the error will occur in both linux and windows.
I think there no problem with my function fprintf.
I've wrote a basic version of fprintf below which will also cause the
same error:

// test for fprintf;

typedef int FILE;                              // just for testing, so
make FILE as INT
FILE *fp;
//fp = 0;

int fprintf(FILE *fp, char *fmt, ...)       // the basic version of
fprintf, for testing
{
        return 0;

}

int main(int argc, char *argv[])
{
        fprintf(fp, "%sz", "aa");          // It's OK
        fprintf(fp, "%s", "aa");           // Segmentation Fault ! Why?
        fprintf(fp, "aa");                   // Segmentation Fault !
        return 0;

}

Will these codes cause Segmentation fault in your environment? (please
let me know your compiler and operating system)

in gdb:
Program received signal SIGSEGV, Segmentation fault.
0x0016cd8c in fwrite () from /lib/tls/i686/cmov/libc.so.6

 

[Eric Sosman]

I am trying to implement my own lib function fprintf, but there's some
problem.
the function is
int fprintf(FILE *fp, char *fmt, ...)
{
.......
}



when I call fprintf(fp, "%sabc", "efg"), it is OK.
but when I call fprintf(fp, "abc") there will be Segmentation fault ,
same as fprintf(fp, "%s", "abc").

I am using gcc, the error will occur in both linux and windows.
I think there no problem with my function fprintf.
I've wrote a basic version of fprintf below which will also cause the
same error:







// test for fprintf;

typedef int FILE; // just for testing, so
make FILE as INT
FILE *fp;
//fp = 0;

int fprintf(FILE *fp, char *fmt, ...) // the basic version of
fprintf, for testing
{
return 0;
}

int main(int argc, char *argv[])
{
fprintf(fp, "%sz", "aa"); // It's OK
fprintf(fp, "%s", "aa"); // Segmentation Fault ! Why?
fprintf(fp, "aa"); // Segmentation Fault !
return 0;
}



Will these codes cause Segmentation fault in your environment? (please
let me know your compiler and operating system)

There's no point. As soon as you define an externally-linked
identifier that clashes with an identifier defined in the Standard
library, your program's behavior is undefined. In the case at hand,
it's impossible to tell whether the fprintf() calls in main() are
trying to use your function or the library's function (or indeed,
some completely bizarre unknown function). If they call the Standard
library function, the fact that `fp' is both NULL and of the wrong type
is once again, undefined behavior. There's not much profit in pursuing
the whys and wherefores of a program that's undefined twice over.

If you were to rename `fprintf' as `xprintf' or something, the
situation might change significantly.

 

[Seebs]

I am trying to implement my own lib function fprintf, but there's some
problem.
the function is
int fprintf(FILE *fp, char *fmt, ...)
{
.......
}

First off. Don't give yours the same name as the library one. That's
unsafe and possibly prone to catastrophic failures.

I think there no problem with my function fprintf.

This is vanishingly unlikely.

Will these codes cause Segmentation fault in your environment? (please
let me know your compiler and operating system)

No clue. I'm not interested in wasting time testing it when there's a
name clash between your code and the library, either. Make one
called myfprintf() and see whether that works.

-s

 

[eliweiq001]

I am trying to implement my own lib function fprintf, but there's some
problem.
the function is
int fprintf(FILE *fp, char *fmt, ...)
{
.......
}

when I call fprintf(fp, "%sabc", "efg"), it is OK.
but when I call fprintf(fp, "abc") there will be Segmentation fault ,
same as fprintf(fp, "%s", "abc").

I am using gcc, the error will occur in both linux and windows.
I think there no problem with my function fprintf.
I've wrote a basic version of fprintf below which will also cause the
same error:

// test for fprintf;

typedef int FILE;                              // just for testing, so
make FILE as INT
FILE *fp;
//fp = 0;

int fprintf(FILE *fp, char *fmt, ...)       // the basic version of
fprintf, for testing
{
   return 0;
}

int main(int argc, char *argv[])
{
   fprintf(fp, "%sz", "aa");          // It's OK
   fprintf(fp, "%s", "aa");           // Segmentation Fault ! Why?
   fprintf(fp, "aa");                   // Segmentation Fault !
   return 0;
}

Will these codes cause Segmentation fault in your environment? (please
let me know your compiler and operating system)

     There's no point.  As soon as you define an externally-linked
identifier that clashes with an identifier defined in the Standard
library, your program's behavior is undefined.  In the case at hand,
it's impossible to tell whether the fprintf() calls in main() are
trying to use your function or the library's function (or indeed,
some completely bizarre unknown function).  If they call the Standard
library function, the fact that `fp' is both NULL and of the wrong type
is once again, undefined behavior.  There's not much profit in pursuing
the whys and wherefores of a program that's undefined twice over.

     If you were to rename `fprintf' as `xprintf' or something, the
situation might change significantly.

Yes , if 'fprintf' is renamed as 'xprintf', there won't be such error.
also if firstly make a pointer to fprintf ( int (*fcn)(FILE *, char
*, ...); fcn = fprintf , there won't be such error neither.

your program's behavior is undefined. In the case at hand,
it's impossible to tell whether the fprintf() calls in main() are
trying to use your function or the library's function

Is there any way to disable the library's functions?
And can I choose the function which wanted to run?

 

[eliweiq001]

I am trying to implement my own lib function fprintf, but there's some
problem.
the function is
int fprintf(FILE *fp, char *fmt, ...)
{
.......
}

when I call fprintf(fp, "%sabc", "efg"), it is OK.
but when I call fprintf(fp, "abc") there will be Segmentation fault ,
same as fprintf(fp, "%s", "abc").

I am using gcc, the error will occur in both linux and windows.
I think there no problem with my function fprintf.
I've wrote a basic version of fprintf below which will also cause the
same error:

// test for fprintf;

typedef int FILE;                              // just for testing, so
make FILE as INT
FILE *fp;
//fp = 0;

int fprintf(FILE *fp, char *fmt, ...)       // the basic version of
fprintf, for testing
{
   return 0;
}

int main(int argc, char *argv[])
{
   fprintf(fp, "%sz", "aa");          // It's OK
   fprintf(fp, "%s", "aa");           // Segmentation Fault ! Why?
   fprintf(fp, "aa");                   // Segmentation Fault !
   return 0;
}

Will these codes cause Segmentation fault in your environment? (please
let me know your compiler and operating system)

     There's no point.  As soon as you define an externally-linked
identifier that clashes with an identifier defined in the Standard
library, your program's behavior is undefined.  In the case at hand,
it's impossible to tell whether the fprintf() calls in main() are
trying to use your function or the library's function (or indeed,
some completely bizarre unknown function).  If they call the Standard
library function, the fact that `fp' is both NULL and of the wrong type
is once again, undefined behavior.  There's not much profit in pursuing
the whys and wherefores of a program that's undefined twice over.

     If you were to rename `fprintf' as `xprintf' or something, the
situation might change significantly.

Yes , if 'fprintf' is renamed as 'xprintf', there won't be such error.
also if firstly make a pointer to fprintf ( int (*fcn)(FILE *, char
*, ...); fcn = fprintf , there won't be such error neither.

your program's behavior is undefined. In the case at hand,
it's impossible to tell whether the fprintf() calls in main() are
trying to use your function or the library's function

Is there any way to disable the library's functions?
How to choose the function which wanted to run?

 

[Ian Collins]

Is there any way to disable the library's functions?
And can I choose the function which wanted to run?

The answer to that is platform specific.

On a typical Unix or Unix like system using dynamic linking, a
statically linked function with the exact signature of a library
function will take precedence over the function in the library.

But this is something you should only do if you know what your doing.

 

[Ben Bacarisse]

Is there any way to disable the library's functions?
And can I choose the function which wanted to run?

Probably the simplest and most portable way is to use a macro:

#undef fprintf
#define fprintf my_fprintf

You'd put this in the header file that contains your function's
prototype and after you include stdio.h.

It's not perfect, but it will most likely do what you want. If you can
assume C99 __VA_ARGS__ you can make fprintf into a function-like macro
instead.

 

[Eric Sosman]

The answer to that is platform specific.

On a typical Unix or Unix like system using dynamic linking, a
statically linked function with the exact signature of a library
function will take precedence over the function in the library.

But this is something you should only do if you know what your doing.

Also, since the implementations of the library functions may
interact behind the scenes in unadvertised ways, it's by no means
certain that a "successful" replacement of one library function
will actually "succeed." For example, providing your very own
version of malloc() will almost certainly not work unless you also
replace free() and calloc() and realloc() and __internal_allocator()
and __memory_shortage_callback_hook() and ...

 

[Ian Collins]

Also, since the implementations of the library functions may
interact behind the scenes in unadvertised ways, it's by no means
certain that a "successful" replacement of one library function
will actually "succeed." For example, providing your very own
version of malloc() will almost certainly not work unless you also
replace free() and calloc() and realloc() and __internal_allocator()
and __memory_shortage_callback_hook() and ...

Very true. The only time I do this is for mocking standard library
functions in unit tests, where "success" can be defined as the function
being called.

 

[Ben Bacarisse]

I don't think so.

#undef won't do anything there, unless fprintf is a macro.

That's the point. If fprintf is a macro you can't define it unless you
undef it first. If it is not a macro, the undef is harmless.

 

[Ben Bacarisse]

When fprintf is not a macro, what is

#define fprintf my_fprintf

supposed to be doing?

Presumably we've ended up with different ideas of the OPs goal. I'm
suggesting using a macro so that code that has calls to fprintf can be
compiled so that these calls are in fact calls to my_fprintf -- the OP's
rewritten version.

 

[Keith Thompson]

When fprintf is not a macro, what is

#define fprintf my_fprintf

supposed to be doing?

Defining a new macro named "fprintf" that expands to "my_fprintf".

<stdio.h> may or may not implement fprintf as a macro in addition to its
declaration as a function. (The fact that it's variadic may complicate
things slightly, but I think C99's variadic macros can handle it;
even if that's not the case, it doesn't hurt to allow for the
possibility).

The goal is for any calls that look like fprintf(<params>) should
actually call the my_fprintf function (and, I suppose, for anything that
refers to the name "fprintf" to resolve to the address of the my_fprintf
function). Defining fprintf as a new macro that expands to the
identifier my_fprintf accomplishes this *if* fprintf isn't already
defined as a macro. The "#undef fprintf" ensures that it will work
whether fprintf is already defined as a macro or not.

Before: ``fprintf'' may or may not be a macro, depending on the
whim of the authors of <stdio.h>.
After: ``fprintf'' definitely is a macro, and it expands to
``my_fprintf''.