Ooops, actually only ComLine has this problem because it doesn't use HTTransportInit() to initialize its transport modules. Instead it does it itself my calling HTTransport_add() with HTANSIReader as the local transport handler. Instead it should check whether it is UNIX or not as in HTTransportInit. -Kim-- BEGIN included message.
-- END included message
- To: email@example.com
- Subject: Bug in local file system access?
- From: "Kim Liu" <KLIU.US.ORACLE.COM>
- Date: 11 Jul 96 15:52:50
- Cc: kliuI think the following is very obvious and I wonder if someone has already spotted it. I am looking at libwww-4.1b1 The applications work fine for "http" access but they don't work at all for "file" access. I turned on the "-vp" tracing and found out HTANSIReader_read() is getting a NULL ANSI C file descriptor. The thing goes like this: HTLoadFile calls HTFileOpen to open a file. HTFileOpen opens it by calling open() and setting net->sockfd to be the UNIX file descriptor. Then HTLoadFile calls HTANSIReader_read() to read the file. But HTANSIReader_read() always reads from a ANSI C file descriptor, not a UNIX file descriptor. But HTFileOpen only set the UNIX file descriptor under UNIX environment. I think it should also call fdopen() to make a ANSI C file descriptor out of the UNIX file descriptor. BTW, the LineMode and Robot applications both didn't have the HTMLPresent converter added to the converter list (they rely on the HTConverterInit() function to add the converters for them but this function doesn't add the HTMLPresent converter). That's why these two apps are totally not operational.