[Prev][Next][Index][Thread]

Fwd: Bug in local file system access?

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. 

I 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.
-- END included message