[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SV: Phew...
Bjarke Hammersholt Roune wrote:
>> >Btw, is it really nessecary to iterator over *entries* ? Isn't
>> it sufficient
>Yup to what? Yup to that it is nessecary, or yup to that it is sufficient
Yup, it it neccessary.
>> All implemented in src/ppUtils.cpp
>> Did you compile and link that?
>No. You placed it in src/, so I missed it. Shouldn't that be with the global
In the header dir? No. It's part of the library implementation.
>There's a bug in Strndup(), though:
Ok, fixed now.
>> >int __cdecl pp::internal::CopyToPlain(class pp::internal::URLInfo const
>> >&,class pp::internal::URLInfo const &,struct ppfDirEntry &)
>> Now that's weird... I'll look into that.
>Here's the definition of CopyToPlain in Read.h:
>int CopyToPlain (const char *Src, const char *Dest, ppfDirEntry &SrcInfo)
>Here's the implementation in Read.cpp:
>int CopyToPlain (const URLInfo &Src, const URLInfo &Dest, ppfDirEntry
The other way round ;)
>To get the rest of the errors fixed, ppfOpen.cpp needs to be uncommented. It
Ooops. I didn't even see that it's commented out.
>has some errors, but just add ::pp::internal to all PFile calls it makes.
>That done, I get another unresolved external on "int __cdecl
>pp::internal::CloseInVirt(struct ppFILE *)". CloseInVirt() isn't declared
<checking> Right. Due to a typo in Open.cpp
>> >1 of those being for main() (well, actually
>> >_WinMain(), but anyway) )
>> What error exactly?
>Well, there IS no main()/WinMain(), so its an unresolved external.
Ah, ok :)
>Ah, ok. Is there errors and fatal errors on your compiler too? In MS VC++,
>an error will not stop compilation, but a fatal error will.
No. gcc/g++ go on compiling as long as possible, so they usually detect
several errors. And eventually they find an error after which they can't
safely continue, so they abort.
So a "fatal error" is simply the last one g++ reports.
>> Don't expect too much though. I have *very* little time currently.
>Have you implemented the dos-style paths in URLInfo? Otherwise, I'd like to
>have a go at that, mostly because I can't debug anything if that isn't
Right. There's some things required here:
(1) URLInfo::ToPlain () has to be modified to modify the path to a proper
DOS-style one if neccessary. Add a
// the code where the comment says "that's all for Unix"
return ToPlainDos () // new method
// we have a problem...
at the bottom of the method
(2) URLInfo::ToVirt () has to be modified to modify the path from DOS-style
to Unix-style if neccessary. Analog to (1)
(3) The parameter-taking constructor and URLInfo::Init () have to be
modified to take an additional parameter bool IsNativePath (default value
false) indicating that the path is a plainfs path in native format.
URLInfo::ParseBasics also has to be modified to (1) don't try to determine
the fstype from a DOS-style path and (2) recognize whether the path is
absolute or relative.
ProcessPath () is already fine.
>btw, what do you think of using the standrad library method _stat() instead
>of the POSIX-specific stat()? I believe the struct _stat _stat() gives
>contains all the information we need (?).
There is no standard library method _stat (). Otherwise my compiler would
find it and my docs would contain some note about it.
I replaced the _stat () calls with calls to StatPlain () (implemented in
Unix.cpp and Win32.cpp, declared in System.h).
Ok, I applied the fixes and the thing still compiles fine ;)
The modified code is in ftp now.
Drive A: not responding...Formatting C: instead