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 *
stream)
{
    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 *
stream);

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,
-eric
Received on Friday, 20 December 1996 08:47:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:27 GMT