W3C home > Mailing lists > Public > www-lib@w3.org > October to December 1996

Re: fwrite() failure in libwww

From: Eric Prud'hommeaux <eric@w3.org>
Date: Fri, 20 Dec 1996 08:47:49 -0500 (EST)
To: Gordon J Lee <GordonL@world.std.com>
cc: demillo@avs.com, www-lib@w3.org
Message-ID: <Pine.SOL.3.94.961220082719.28425A-100000@anansi>
> 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
add lib.c:
#include <stdio.h>

_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
add app.c:
#include <stdio.h>

extern FILE * myFopen(char * path, char * mode)
extern int myFwrite(void * ptr, size_t size, size_t nmemb FILE *

int main(void)
    FILE * file = myFopen("asdf", "w");
    int ret;
    ret = fwrite("asdf\n", 5, 1, file); /* fails */
    ret = myFwrite("asdf\n", 5, 1, file); /* succeeds */
    return ret;

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.

thank you,
Received on Friday, 20 December 1996 08:47:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:47 UTC