Re: Good News (was Re: Bad news (was Re: Update))

[pcburns@zip.com.au]

Chistian Reiniger wrote:
>Peter Burns wrote:

>>I compiled the pfile_basic test and got an access violation straight away.
>>This came about as a result of an bug in void URLInfo::ToVirt.
>>
>>"c:\" gets converted to "c/" instead of "/c/" and the path gets wrongly
>>attributed as relative instead of absolute.
>>
>>I think you need remove the line "path++; // skip the leading slash"

>Can't be. The leading slash is supposed to be skipped - URLInfo has an
>internal flag for remembering whether the path is absolute or not.
>Hmmm, I can't find a bug in there...

Ok. The internal flag for remembering whether the path is absolute is not being
set.

>>ps: I found this out because of the comment - comments are good.

>*grin*

>>There are still a few more bugs in there.
>>There is some memory being written over or not intialised properly somewhere.

Strdup doesn't seem to work properly : the memory allocated triggers an assert
in VC memory debugging code. What is the reason for using Strdup instead of 
strdup?

>>ppfOpen doesn't work properly. This has to do with compilication caused 
>by "c:\"
>>not being handled correctly.

>You're trying to pass a DOS-style string to ppfOpen? That's wrong. ppfOpen
>works with PFile URLs, i.e. "/c/some/dir/with/a/file.xxx"

You need to convert the url style string into a dos style string when you call
fopen otherwise it wont work.

>>If I set FileGlobalData::cwd_is_valid_for_native to true then ppfOpen works 
and

>Huh? This should be true by default.
><looking>
>Aaaahh. Found it. FileGlobalData calls ChdirPlain () with a PFile URL, but
>ChdirPlain () assumes it gets a DOS-style path (which is correct).
>Fixed.

Peter
Burns

---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/