Win32 PFile Changes (was Re: PSound updates)

["Peter Burns" <pburns@firstdata.com.au>]

I can't seem to connect to my ISPs web mail page so I'll just send using my work
email which
probably wont make it to the list.



Peter Burns wrote:

>>This problem has to do with constness.
>>DirE->GetName() returns a const char*
>>Dir->Entry->Name is a char*

>Not in my copy (the one that's also in CVS).
>Dir is of type ppfDIR (defined in PenguinFile.h)
>Dir->Entry is of type ppfDirEntry (also defined in PenguinFile.h)
>Dir->Entry->Name is of type const char * here.
>Perhaps you changed that before to work around different constness problems?

I must have changed it. It seems strange to me to delete a const char*.

>>>>* In Win32.cpp: ChdirPlain () always gets a native path as input. That's
>>>>
>>Going through with the debugger reveal that it receives a string like
>>/d/some/path.

>Then that's a bug in the calling code. <looking>
>This is the only code calling ChdirPlain (in FileGlobalData::SetCWD ()):

I think previously the path wasn't converted ToNative before calling ChdirPlain.
It may be that the modifications to ChdirPlain are not necessary anymore.

>>Most of the problems with the code have to do with the drive letter.
>>
>>d:/some/path gets modified to /d/some/path. The initial / gets chopped off
>>and the path becomes d/some/path. The path is then given as a *string* to
>>URLInfo::Init which assumes that it is a relative path.

>That's bad. Where does this happen? I just checked a bit around the typical
>Chdir callchain and didn't see anything like this.

The FileGlobalData construction sequence seems to have a few problems for
win32.

I think it happens in FileGlobalData::SetCWD.

>Ummm, yes. Good.
>To be true I don't have the faintest idea what you're talking about ;+)
>When reading "clan" I thought of either some network session or a family
>meeting...

Electronic music from 8-5  -> http://clananalogue.org

Peter Burns