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

[Christian Reiniger <warewolf@mayn.de>]

pcburns@zip.com.au wrote:

>>>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.

It isn't *changed*. The code is in an
if (is_absolute) {}
block - i.e. it is only executed if that flag is already set. And it isn't
unset thereafter.

>>>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?

strdup isn't standard. We can't rely on having it on each system.
Can you investigate on that a bit more? From looking at the code Strdup ()
should work perfectly fine (and it worked for >750 calls when I testes it
here with pfile_pakstress.cpp).
But I had 2 occurrences where a pointer was deleted twice in a completely
unrelated piece of code, causing a segfault in 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.

Doing that. see the "UInfo.ToNative ();" in ppfOpen () before the call to
OpenPlain ().


	Christian
-- 

Why look at the Docs? Nurses are better!