[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Good News (was Re: Bad news (was Re: Update))
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
>>ps: I found this out because of the comment - comments are good.
>>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
>>ppfOpen doesn't work properly. This has to do with compilication caused
>>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
>Huh? This should be true by default.
>Aaaahh. Found it. FileGlobalData calls ChdirPlain () with a PFile URL, but
>ChdirPlain () assumes it gets a DOS-style path (which is correct).
This message was sent using Endymion MailMan.