Re: fwrite() failure in libwww
> Hi, Did you ever solve this problem ?
> I am suffering from exactly the same problem.
> I realize that you posted this two months ago, but there was
> no followup to the issue in the libwww archive.
> > My current environment is Windows NT 4.0 Workstation,
> > usng the MS VC++ 4.2 compiler. I have the latest
> > 5.0 library release: 5.0a. It built without (almost)
> > a hitch.
> > After 3/4ths of a day of monkeying around, I have
> > come to the conclusion that the contents of
> > the original file pointer opened up by HTLoadToFile() gets
> > whacked somewhere along the way. Any other function that tries to
> > access that file pointer (such as fwrite() in HTFWriter_write()
> > or fflush() in HTFWriter_flush()) causes the program
> > to crash...although I cannot find where this is happening.
The problem is probably that the library that calls fopen is not the same
library that is doing the module. I have no idea why this is a
restriction, but have proven that it is with a simple case like:
make a DLL project
_export FILE * myFopen(char * path, char * mode)
return (fopen(path, mode);
_export int myFwrite(void * ptr, size_t size, size_t nmemb FILE *
return (fopen(ptr, size, nmemb, stream);
make a new conslole app project that includes the first one
extern FILE * myFopen(char * path, char * mode)
extern int myFwrite(void * ptr, size_t size, size_t nmemb FILE *
FILE * file = myFopen("asdf", "w");
ret = fwrite("asdf\n", 5, 1, file); /* fails */
ret = myFwrite("asdf\n", 5, 1, file); /* succeeds */
We did some reorganization to help this situation some time ago. Ideally,
the FILE will be opened, written, and closed through the same DLL, kind of
a pain though, sometimes. I don't believe I checked the test apps out on
windows, so I'm not surprised that there are problems. Write back with any
inspirations you have for solutions.